Vous êtes sur la page 1sur 17

ITC542-201460 Assessment II

Rashif Rahman, Charles Sturt University


Student ID: 11556946, Due: September 8, 2014

1
1.1

Switching
Packet Switching

The concept of packet switching began with the ideas of independent researchers (Kurose
& Ross, 2012, p. 60). When computers were becoming important for science in the middle
of the 20th century, it also became apparent that there was a need to interconnect systems
regardless of distance. The then-existing communication technique of circuit switching
used for telephony proved to be incompatible with the very nature of computing (Leiner
et al., 2009; Roberts, 1978). Ideas were put into practice in the 1970s with the invention
of what is now known as the TCP/IP protocol suite (Forouzan, 2009, p. 3). The new
switching technique uses packets rather than circuits, in that messages are divided
into small pieces of data and moved across a physical medium (Forouzan, 2009, p. 97;
Tanenbaum & Wetherall, 2010, pp. 162164). Being based on digital technology meant
that the switching could be independent of the physical medium.
The purpose of this new switching technique was twofold: networking and internetworking
or, allowing devices to talk to each other, and allowing networks of devices to talk to each
other (a network of networks), efficiently (Leiner et al., 2009; Roberts, 1978). The key
here is efficiency. Traditional circuit switching reserves the path when a connection is
established, so no two connections can use the same path. In packet switching paths can
be used by multiple connections. Any link in the path can contain packets belonging to
different connections. In this way, packets of one connection are all independent and may
take different routes to a destination. This is a best-effort delivery, and is compatible with
the bursty networking pattern of computers, where any link can be idle for a long time
with sudden bursts of traffic occasionally. In this idle time, other connections can use the
link.

1.2

Circuit Switching

Switching allows interconnecting multiple devices without having to set up expensive


point-to-point infrastructure (Forouzan, 2006, 8). Circuit switching was the natural
evolution of telecommunications technology from the telegraph (Holzmann & Pehrson,
1994), necessitated by the proliferation of telephony and made possible by 20th century
engineering (AT&T, n.d.; COMNEWS, 1984). Although the technical details can be
1

complex, the conceptlike many scientific breakthroughsis simple in hindsight. There


are three phases to a circuit-switched connection: a physical electrical circuit is established
between two ends, communication ensues, and the circuit is freed once the communication
is over (Forouzan, 2006, 8.1; Kurose & Ross, 2012, 1.3.2; Tanenbaum & Wetherall, 2010,
2.6.5). Switches in the path between the two end points determine which links must be
connected in order to close the circuit (Forouzan, 2006, p. 217, 2009, p. 132).
A circuit-switched connection is therefore temporary, but dedicated. A different pair of
end points will use a different set of links, but each connection is unique and uses the
same set of links every time. The physical path comprising a set of links and switches is
therefore predetermined for every unique source and destination. At any point in time
the overall circuit is either closed or open; a path is either used or lies dormant. Because
there is no sharing of links for different paths, throughput is guaranteed at all times.
Communication can occur in real-time since resources are reserved during connection
establishment. Traditional public telephone networks (plain old telephone service, or
POTS) are a prime example of circuit switching, although computer networks can also
be circuit-switched, and modern telephone networks today are moving away from this
technique (Forouzan, 2006, 9; Tanenbaum & Wetherall, 2010, p. 68, 164).

1.3

Packets vs. Circuits

Digital information can represent different types of data and activity that can have different
requirements of the underlying communication mechanism. Because packet switching
abstracts away the physical medium, it is an appropriate switching technique for digital
data communications. Even when the physical layer of the communication is circuitswitched, packetized data enables greater link utilization. For example, a circuit-switched
link can be divided up into channels and analogue signals can use one channel while
digital (packetized) data can use another (Forouzan, 2006, 6, 9). Because much digital
activity is bursty in nature, a link is not always busy. Breaking up data into smaller
packets enables a link to accommodate many such packets from different connections. This
maximizes utilization by minimizing idle time. Individual packets follow an optimized
route, taking alternative routes when needed. This provides a layer of redundancy.
Circuit switching may be appropriate for analogue communication where there is only
one class of signal and the network is dependent upon a physical layer of signal routing
logic, or for communication where a direct end-to-end link is required for reasons such as
privacy and quality of service. However, because a circuit-switched link is reserved for
one connection, it is not suitable for communication that is bursty in nature and where
permanent allocation of resources would be wasteful or expensive. It is also not suitable
for short messages due to the overhead of setting up a connection. Circuit switching is
inherently not fault-tolerant, as any problem along the path of a connection will prevent
passage of information and require costly physical repairs. There is no redundancy; if one
link is damaged, there is no alternative. With the advances in technology today, even
privacy and quality of service can be met by packet switching (Ars Technica, 2013).

Subnetting

Available Block: 110.50.0.0/16


No. of Addresses: 65,536 (23216 )
Network Mask: 255.255.0.0 (16-bit prefix)
Address Range: 110.50.0.0 110.50.255.255
Prospective Customers: 2,600
Group 1: 200 businesses 120 addresses
Allocatable Addresses: 200 128 (2dlog2 120e ) = 25, 600
Addresses Unused: 25, 600 (200 120) = 1, 600
Group 2: 400 businesses 20 addresses
Allocatable Addresses: 400 32 (2dlog2 20e ) = 12, 800
Addresses Unused: 12, 800 (400 20) = 4, 800
Group 3: 2000 households 6 addresses
Allocatable Addresses: 2000 8 (2dlog2 6e ) = 16, 000
Addresses Unused: 16, 000 (2000 6) = 4, 000
The ISP has a /16 CIDR block granted to it, so it has a total of 65,536 addresses (prefix
length subtracted from bit length of IPv4 address space, as a power raised from two)
to use for its business. Blocks allocated to each customer must be a power of two.
Mathematically, this is because the number of addresses N needs to provide an integer
value for prefix length n; since N = 232n , solving for n yields n = 32 log2 N . Therefore,
the requested number of blocks are transformed to comply with this requirement. The
next power of two of any number i can be found by calculating the ceiling of the base-2
logarithm of i to get an integer j, and then raising two to the power of j.
Table 1: IP address allocation across three groups

2.1

Group

Businesses

Users

Subnet

Unused

1
2
3

200
400
2000

120
20
6

110.50.0.0/25
110.50.100.0/27
110.50.150.0/29

1600
4800
4000

Group 1

Subnet Address: 110.50.0.0/25


Subnet Range: 110.50.0.0 110.50.99.255
Block Size: 128
Prefix Length: 25 (32 log2 128)
3

Network Mask: 255.255.255.128


11111111.11111111.11111111.10000000 (25-bit prefix)
255.
255.
255.
128 (decimal value)
This group has 200 customers (medium-size businesses) and each customer needs 120
addresses. However, the number of addresses allocated (block size) per customer is 128.
This is because 120 is not a power of two, and 128 is the next power of two after that
number (2dlog2 120e ). Therefore, the total number of addresses allocated for Group 1 is
25,600 (200 128). The prefix length is found by subtracting the base-2 logarithm of
the block size from the bit length of the IPv4 address space. The network mask is the
base-256 decimal equivalent of an address with 25 bits all set to TRUE (1) and the rest
(32 25 = 7) to FALSE (0). Twenty-four bits would cover up to the third byte (octet),
leaving one bit for the next (last) octet. Since this bit is in the 27 place and no other
bit in the byte is set, the octets value is just 128. The network mask can be used to
determine the last address of a block.
2.1.1

First Customer

Allocated Block: 110.50.0.0/25


First Address: 110.50.0.0 (network address)
Last Address: 110.50.0.127 (special address)
00000000 (last octet of first address)
OR
01111111 (NOT of last octet of mask)
-------01111111 = 127
The starting address for the first customer is simply the network address of the parent
block (since it is the first allocation), except with a larger prefix. Since 25 bits are TRUE
(dictated by the mask), the first three octets of the address keep their values. The fourth
octet is not affected because its value is zero. The last address can be found by simply
adding block size - 1 to this address. More precisely, it is also found by applying a
binary OR operation over the network (first) address and binary NOT (complement) of
the network mask. The TRUE octets will always yield the same values in this operation,
so a short-cut is to only apply it to the octet that is partially TRUE (less than eight bits
TRUE). In this operation, any remaining right-most octets will simply be TRUE.
2.1.2

nth Customer

Allocated Block: 110.50.x.y/25


110.50.0.0256 + base-256(n 1 block size), e.g. when n = 200, first solve for the
right-hand expression:
4

(200 1) 128 = 25472


25472 mod 256 = 128
b25472 256c = 99
Then, carry out the base-256 addition:
110. 50. 0. 0
+ 0. 0. 99.128
--------------110. 50. 99.128
:: x = 99, y = 128
First Address: 110.50.99.128 (network address)
Last Address: 110.50.99.255 (special address)
10000000 (last octet of first address)
OR
01111111 (NOT of last octet of mask)
-------11111111 = 255
The address block of the nth customer can be found by simply multiplying the block
size by n 1. The result will be a base-10 decimal number, which can be converted to
base-256 and added to the first address of the group to yield the starting address of the
block. All other operations remain the same as with the first block. Only the third and
fourth octets change because 16 bits are available for the ISP to use across all groups of
customers. Here the results are for the last customer in this group, so the next allocation
can continue from the next available block 110.50.100.0.

2.2

Group 2

Subnet Address: 110.50.100.0/27


Subnet Range: 110.50.100.0 110.50.149.255
Block Size: 32
Prefix Length: 27 (32 log2 32)
Network Mask: 255.255.255.224
11111111.11111111.11111111.11100000 (27-bit prefix)
255.
255.
255.
224 (decimal value)
The total number of addresses allocated for Group 2 is 12,800 (400 32). The network
mask is the base-256 decimal equivalent of an address with 27 bits all set to TRUE (1)
and the rest (32 27 = 5) to FALSE (0). Twenty-four bits would cover up to the third
byte (octet), leaving three bits for the next (last) octet. Since these bits are in the 27 , 26
and 25 place, the octets value is 224.
5

2.2.1

First Customer

Allocated Block: 110.50.100.0/27


First Address: 110.50.100.0 (network address)
Last Address: 110.50.100.31 (special address)
00000000 (last octet of first address)
OR
00011111 (NOT of last octet of mask)
-------00011111 = 31
The starting address for the first customer is simply the subnet address of the group (since
it is the first allocation in this group). Since 27 bits are TRUE, the first three octets of the
address keep their values. The fourth octet is not affected because its value is zero.
2.2.2

nth Customer

Allocated Block: 110.50.x.y/27


110.50.100.0256 + base-256(n 1 block size), e.g. when n = 400, first solve for the
right-hand expression:
(400 1) 32 = 12768
12768 mod 256 = 224
b12768 256c = 49
Then, carry out the base-256 addition:
110. 50.100. 0
+ 0. 0. 49.224
--------------110. 50.149.224
:: x = 149, y = 224
First Address: 110.50.149.224 (network address)
Last Address: 110.50.149.255 (special address)
11100000 (last octet of first address)
OR
00011111 (NOT of last octet of mask)
-------11111111 = 255
Here the results are for the last customer in this group, so the next allocation can continue
from the next available block 110.50.150.0.
6

2.3

Group 3

Subnet Address: 110.50.150.0/29


Subnet Range: 110.50.100.0 110.50.
Block Size: 8
Prefix Length: 29 (32 log2 32)
Network Mask: 255.255.255.248
11111111.11111111.11111111.11111000 (27-bit prefix)
255.
255.
255.
248 (decimal value)
The total number of addresses allocated for Group 3 is 16,000 (2000 8). The network
mask is the base-256 decimal equivalent of an address with 29 bits all set to TRUE (1)
and the rest (32 29 = 3) to FALSE (0). Twenty-four bits would cover up to the third
byte (octet), leaving five bits for the next (last) octet. Since the 20 , 21 and $22 places
are zero, the octets value is 248.
2.3.1

First Customer

Allocated Block: 110.50.150.0/29


First Address: 110.50.150.0 (network address)
Last Address: 110.50.150.7 (special address)
00000000 (last octet of first address)
OR
00000111 (NOT of last octet of mask)
-------00000111 = 7
The starting address for the first customer is simply the subnet address of the group.
Since 29 bits are TRUE the first three octets of the address keep their values. The fourth
octet is not affected because its value is zero.
2.3.2

nth Customer

Allocated Block: 110.50.x.y/29


110.50.150.0256 + base-256(n 1 block size), e.g. when n = 2000, first solve for
the right-hand expression:
(2000 1) 8 = 15992
15992 mod 256 = 120
b15992 256c = 62
Then, carry out the base-256 addition:
7

110. 50.150. 0
+ 0. 0. 62.120
--------------110. 50.212.120
:: x = 212, y = 120
First Address: 110.50.212.120 (network address)
Last Address: 110.50.212.127 (special address)
01111000 (last octet of first address)
OR
00000111 (NOT of last octet of mask)
-------01111111 = 127
The results are for the last customer in this last group, so any new allocations can continue
from the next available block 110.50.212.128.

3
3.1

Forwarding
Router R1

The router first determines the class of the destination address so that it can extract
the network address and search the appropriate routing table for where to forward the
packet next. This is done by bit-shifting the address 28 bits to the right. The address
145.80.23.14 is 10010001 01010000 00010111 00001110 in binary. The result of the
bit-shift is 00000000 00000000 00000000 00001001, or 9, which indicates a Class B
network. The router then extracts the network address by performing a binary AND
operation over the Class B network mask and the destination address.
10010001 01010000 00010111 00001110 (145.80.23.14)
11111111 11111111 00000000 00000000 (255.255.0.0)
================>-----------------10010001 01010000 00000000 00000000 (145.80.0.0)
The result of the masking is 145.80.0.0. The router searches the Class B routing table
and finds it in the first row. The next-hop address is empty, which means the destination
network is connected to the router and a direct delivery can be made. The destination
address and interface number m1 are passed to ARP to retrieve the physical address of
the next hop.

Table 2: Class A table of router R1


Network
Address

Next-hop
Address

Interface

111.0.0.0

m0

Table 3: Class B table of router R1


Network
Address

Next-hop
Address

Interface

145.80.0.0
170.14.0.0

m1
m2

Table 4: Class C table of router R1


Network
Address

Next-hop
Address

Interface

192.16.7.0

111.15.17.32

m0

Default: 111.30.31.18, m0

3.2

Router R2

The router determines the class of the destination address by bit-shifting the address 28
bits to the right. The address 145.80.23.14 is 10101010 00001110 00011000 00001100
in binary. The result of the bit-shift is 00000000 00000000 00000000 00001010, or 10,
which indicates a Class B network. The router then extracts the network address by
performing a binary AND operation over the Class B network mask and the destination
address:
10101010 00001110 00011000 00001100 (170.14.24.12)
11111111 11111111 00000000 00000000 (255.255.0.0)
================>-----------------10010001 01010000 00000000 00000000 (170.14.0.0)
The result of the masking is 170.14.0.0, and the router searches the Class B routing table,
finding the address in the second row. There is next-hop address, which means an indirect
delivery must be made. The address 111.25.19.20 and interface number m1 are passed to
ARP to retrieve the physical address of the next hop.

Table 5: Class A table of router R2


Network
Address

Next-hop
Address

Interface

111.0.0.0

m1

Table 6: Class B table of router R2


Network
Address

Next-hop
Address

Interface

145.80.0.0
170.14.0.0

111.25.19.20
111.25.19.20

m1
m1

Table 7: Class C table of router R2


Network
Address

Next-hop
Address

Interface

192.16.7.0

111.15.17.32

m1

Default: 0.0.0.0, m0

3.3

Router R3

The router determines the class of the destination address by bit-shifting the address 28
bits to the right. The address 135.15.42.18 is 10000111 00001111 00101010 00010010
in binary. The result of the bit-shift is 00000000 00000000 00000000 00001000, or 8,
which indicates a Class B network. The router then extracts the network address by
performing a binary AND operation over the Class B network mask and the destination
address:
10000111 00001111 00101010 00010010 (135.15.42.18)
11111111 11111111 00000000 00000000 (255.255.0.0)
================>-----------------10010001 01010000 00000000 00000000 (135.15.0.0)
The result of the masking is 135.15.0.0, and the router searches the Class B routing table,
but does not find the address. This means that the network is somewhere else in the
Internet and the packet must be forwarded to the default router. The address 111.30.31.28
and interface number m1 are passed to ARP to retrieve the physical address of the next
hop.

10

Table 8: Class A table of router R2


Network
Address

Next-hop
Address

Interface

111.0.0.0

m1

Table 9: Class B table of router R3


Network
Address

Next-hop
Address

Interface

145.80.0.0
170.14.0.0

111.25.19.2
111.25.19.2

0 m1
0 m1

Table 10: Class C table of router R3


Network
Address

Next-hop
Address

Interface

192.16.7.0

m0

Default: 111.30.31.18, m1

ARP

The ARP protocol is simply a helper protocol of the network layer, sitting closer to the
data link layer (Forouzan, 2009, p. 222). Its job is to facilitate node-to-node passing
of data by retrieving the physical (hardware) address that relates to a logical address.
(Forouzan, 2009, 6.2) The word relates is used because the physical address retrieved
may not necessarily be that of the device with that particular logical addressit can be
another device that acts on behalf as a forwarder (e.g. a router among many routers in
a path towards the device). Every time the network layer prepares data to be sent out,
ARP helps it fill in the hardware address that the data link layer will use (Forouzan, 2009,
pp. 4850).
It does this by creating a query message of its own that will be broadcast (Figure 1). The
correct system (it can be a host or a router acting on behalf of the host) will respond with
its logical address mapped to a hardware address. In effect, ARP basically asks everyone
around whether one of them is or has access to a particular logical address. In the reply
(Figure 2), the broadcast address field is replaced with the original senders address (i),
while the addresses in the payload change places (j) and the the new physical address is
inserted into the source address (k). The requester now knows that this address is to be
mapped to the logical address it did not have information about.

11

Figure 1: ARP Request Encapsulation

Figure 2: ARP Reply Encapsulation

12

5
5.1

ICMP
The Protocol

ICMP messages can be categorized as either error-reporting messages or query messages.


Several message types are defined, and within each type there are codes indicating
the reason for the message (RFC792, 1981). Error-reporting messages contain useful
information while query messages can glean useful information. An error-reporting message
includes part of the original datagram for identification purposes and can inform the
sender when a destination is unreachable, when a router has redirected a datagram, or
when a datagram header contains invalid data. It can report when a datagram is stuck in
a loop or when fragments do not arrive on time. It can also warn the sender of congestion,
but the parameter is rarely used and is in fact deprecated (RFC6633, 2012) because such
features are already present at the transport layer (Kurose & Ross, 2012, p. 353). There
are other parameters that are also deprecated (IANA, 2013).
Two types of query messages are prevalent today and can be used to check network
availability and measure round-trip times. ICMP can therefore be used for testing,
debugging and troubleshooting purposes, and is exactly what the popular programs
ping and traceroute (also tracert) rely upon for their functionality. ICMP messages
combined are very powerful and, aside from diagnostics, can even be used for malicious
purposes such as mapping a network topology and probing for vulnerabilities. This is why
some systems either block these messages or do not report correctly (Kurose & Ross, 2012,
p. 355). Like ARP, ICMP is a helper protocol of the network layer. It compensates for
the lack of error control and information reporting in IP, a deficiency which is unavoidable
due to the characteristics of a best-effort delivery service. ICMP is encapsulated within
IP datagrams so that only network-layer devices will act upon it.

5.2

Implementations

The ping program utilizes the ICMP echo-request and echo-reply pair of query messages
to obtain several pieces of information (Forouzan, 2009, p. 254; Kurose & Ross, 2012, p.
353; Muuss, n.d.). It can report the round-trip packet transmission time between a host
and destination, and can indicate whether there is any problem along the path by keeping
a count of packets sent and received. Proper operation of the networking hardware and IP
software is a precondition for the program to work (it is a networking utility), so it can be
used to check network availability and functionality. Since a round-trip time measurement
depends on the response from the receiver, it can also be used to test network reachability.
Because the program exposes IP addresses and can be used for malicious purposes, some
systems block ICMP messages due to privacy and security concerns (Kurose & Ross, 2012,
p. 143, 355).
The traceroute (or tracert) program is also based on ICMP, butrather interestingly
instead of using query messages, relies on the time-exceeded and destination-unreachable
error-reporting messages to trace network hops along the path between a host and
destination (Forouzan, 2009, p. 260; Kurose & Ross, 2012, pp. 353355; RFC1393, 1993;
Tanenbaum & Wetherall, 2010, p. 466). Such a route-recording option is also provided by
ping, but traceroute provides other options that offer more control (Forouzan, 2009, pp.
13

204205). It works by sending out simple UDP datagrams and intentionally triggering
errors incrementally, exploiting the behaviour of routers and end-hosts towards TTL values
and invalid port numbers. Because the program also reveals a lot of information and can
be used to map out out the topology of a network, some systems block such messages and
may not respond (Kurose & Ross, 2012, p. 355).

5.3

Practical

The commands were run from a server located in Nuremburg, Germany. This information
can be retrieved using IP geolocation services such as ipinfo.io. The CSU server location
was also retrieved in this manner since the university and website may not necessarily
be colocated. Knowing the distance between the two servers is important in order to
differentiate delays, and this can be found by measuring by hand using a traditional map
or using an online map service such as Google Maps. The distance between Germany and
Australia is found to be approximately 15,000 km.

Figure 3: Ping from Germany to Australia


The ping command (Figure 3) was run with the options to prevent name-resolving (show
only IP addresses) and send 10 packets in order to reduce the output size to fit this
page. The results indicate that the CSU server is responding to the ICMP messages,
and the latency (round-trip time) between the two servers is a constant 312 ms without
any packet loss. This means that there are no variable delays introduced along the
path, such as congestion or queueing, although there can be fixed delays introduced by
other factors. There is a minimum delay in this time, which is the propagation delay
(distance propagation speed). The propagation speed cannot be faster than the speed
of light, and typically in fiber optics (assuming trans-continental data communication
medium is high-speed undersea fiber-optic cables) it is 2 108 m/s (Kurose & Ross, 2012,
p. 37). Therefore:
Tp =

15000 103
= 0.075 = 75 ms
2 108

However, this is only in one direction, so the actual propagation delay included in the
latency between the two servers is 2 75 = 150 ms, leaving approximately another 150
ms as fixed delay due to unaccountable factors. This also means that the propagation
delay is 50% of the packet delivery time.
14

The traceroute command (Figure 4) was also run with options to suppress names and
to send only one probe packet per hop in order to reduce the size of the image, thereby
recording only one timestamp. The output was also truncated from hop 19 onwards
(up to 30) since they are simply non-response indicators (represented by the asterisk
character). It can be seen that 10th hop does not respond either, and this may be because
ICMP messages have been blocked. The incremental delays seen are likely only due to
geographical distance between the hops (the ping run confirms that there are no variable
delays in the path). The first few hops are closer to Germany and the last few are closer
to Australia. Because the trace does not end before the 30th hop and hops after the 18th
are non-responsive, it can be said that the CSU server does not respond to traces. This
may be for security reasons.

Figure 4: Traceroute from Germany to Australia

15

References
Ars Technica. (2013). The telephone network is obsolete: get ready for the all
IP telco. A technology news and information website. Retrieved September 7, 2014, from http://arstechnica.com/information-technology/2013/01/
the-telephone-network-is-obsolete-get-ready-for-the-all-ip-telco/
AT&T. (n.d.). History of network switching. The official website of AT&T Corp. Retrieved
September 7, 2014, from http://www.corp.att.com/history/nethistory/switching.
html
COMNEWS. (1984). Electronic switching is in. Communications news: enterprise
network solutions, 21 (9), 8232.
Forouzan, B. A. (2006). Data communications and networking (4th ed.). New York,
United States: McGraw-Hill.
Forouzan, B. A. (2009). TCP/IP protocol suite (4th ed.). New York, United States:
McGraw-Hill.
Holzmann, G. J., & Pehrson, B. (1994). The early history of data networks. New York,
United States: Wiley.
IANA. (2013). Internet control message protocol (ICMP) parameters. Official website
of the Internet Assigned Numbers Authority. Retrieved September 7, 2014, from
http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml
Kurose, J. F., & Ross, K. W. (2012). Computer networking: a top-down approach (6th
ed.). New York, United States: Pearson.
Leiner, B. M., Cerf, V. G., Clark, D. D., Kahn, R. E., Kleinrock, L., Lynch, D. C., . . .
Wolff, S. (2009). A brief history of the Internet. ACM SIGCOMM Computer
Communications Review, 39 (5), 2231. Retrieved from http://www.internetsociety.
org/internet/what-internet/history-internet/brief-history-internet
Muuss, M. (n.d.). The story of the PING program. US Army Research Laboratory user
page. Retrieved September 7, 2014, from http://ftp.arl.army.mil/~mike/ping.html
RFC1393. (1993). Traceroute using an IP option. The Internet Engineering Task Force.
Retrieved from http://tools.ietf.org/html/rfc1393
RFC6633. (2012). Deprecation of ICMP source quench messages. The Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc6633
RFC792. (1981). Internet control message protocol. The Internet Engineering Task Force.
Retrieved from http://tools.ietf.org/html/rfc792

16

Roberts, L. G. (1978). The evolution of packet switching. Proceedings of the IEEE, 66 (11),
13071313.
Tanenbaum, A. S., & Wetherall, D. J. (2010). Computer networks (5th ed.). New Jersey,
United States: Prentice Hall.

17

Vous aimerez peut-être aussi