1. Lecture slides prepared for “Business Data Communications”, 7/e, by William Stallings and Tom Case, Chapter 11 “Internet Operation”.

2. Chapter 11 Internet Operation
This chapter looks at some of the details “under the hood” of the Internet. We begin
by examining the rather complicated issue of addressing in such a far-flung, massive,
and dynamic configuration. Next, we provide an overview of routing protocols, by
which routers cooperate to design routes, or paths, through the Internet from source
to destination. Then, we introduce the issue of quality of service. Next, we look at
the most important approach to providing quality of service on the Internet, known
as differentiated services. Finally, we introduce the topics of service level agreements
and IP performance metrics.
Internet Operation

3. The host number is assigned by the authority that manages the network
Internet Addressing
To identify a host on the Internet each host is assigned a unique IP address
Consists of two logical components:
A network component which identifies a network on the Internet
A host component which identifies a host connected to a particular network
The form of the IP address is:
IP address = <network number> <host number>
The network number is administered by one of five Regional Internet Registries
The host number is assigned by the authority that manages the network
The IP address is obtained either by looking it up in a configuration file or dynamically via the Dynamic Host Configuration Protocol (DHCP)
To identify a host on the Internet, each host is assigned a unique IP address, which
consists of two logical components: a network component, which identifies a network
on the Internet, and a host component, which identifies a host connected to a
particular network. The host portion of the address need only be unique within its
designated network. Thus, the IP address is of the form
IP address = <network number> < host number>
The network number portion of the IP address is administered by one of five
Regional Internet Registries. The host portion is assigned by the authority that
manages the network, which is typically the organization that owns the network.
The IP address is assigned to a network interface on a host (there may be
multiple network interfaces) when the OS boots up. As discussed in Chapter 7, the
IP address is obtained either by looking it up in a configuration file or dynamically,
via the Dynamic Host Configuration Protocol (DHCP).

4. IPv4 Addressing IPv4 uses 32-bit address field
Addresses are usually written in dotted decimal notation
A decimal number represents each of the octets of the 32-bit address
IP address is written
IPv4 uses 32-bit address field. IP addresses are usually written in what is called dotted
decimal notation , with a decimal number representing each of the octets of the 32-bit
address. For example, the IP address is written as

5. Class-Based IP Addresses
Rightmost bits of the 32-bit IP address designate a host
The leftmost bits of the 32-bit address designate a network
Class-based, or classful, IP addressing was adopted to allow for a variable allocation of bits to specify network and host
The first few leftmost bits specify how the rest of the address should be separated into network and host fields
This provides flexibility in assigning addresses to hosts and allows a mix of network sizes on an internet
In general terms, the rightmost, or least significant,
bits of the 32-bit IP address designate a host, and the leftmost, or most significant,
bits designate a network. A fixed allocation of bits, such as 16 bits for network
number and 16 bits for host, was deemed inadequate to handle the global Internet,
where some organizations might have a few networks, each with many hosts and
some organizations might have many networks, each with a few hosts. Therefore, a
scheme known as class-based , or classful , IP addressing was adopted.
Class-based IP addresses allow for a variable allocation of bits to specify
network and host. For this scheme, the first few leftmost bits specify how the rest
of the address should be separated into network and host fields. This encoding provides
flexibility in assigning addresses to hosts and allows a mix of network sizes on
an internet.

6. Address Classes Class A
Best suited to a configuration with few networks, each with many hosts
All addresses begin with binary 0
Class B
Best suited to a configuration with a medium number of networks, each with a medium number of hosts
All addresses begin with binary 10
Class C
Best suited to a configuration with many networks, each with a few hosts
All addresses begin with binary 111
Class A addresses are best suited to a configuration with few networks,
each with many hosts.
The Class A address has the following format:
0 network (7 bits) host (24 bits)
Class B addresses are best suited to a configuration with a medium number
of networks, each with a medium number of hosts, and have the following format:
1 0 network (14 bits) host (16 bits)
Class C addresses are best suited to a configuration with many networks, each
with a few hosts, and have the following format:
1 1 1 network (21 bits) host (8 bits)
An organization would be assigned one or more blocks from these classes.

7. Subnets and Subnet Masks
Allows for subdivision of internets within an organization
Each LAN can have a subnet number, allowing routing among networks
Host portion is partitioned into subnet and host numbers
The concept of subnet was introduced to address
the following requirement. Consider an internet that includes one or more WANs
and a number of sites, each of which has a number of LANs. We would like to allow
arbitrary complexity of interconnected LAN structures within an organization
while insulating the overall internet against explosive growth in network numbers
and routing complexity. One approach to this problem is to assign a single
network number to all of the LANs at a site. From the point of view of the rest
of the internet, there is a single network at that site, which simplifies addressing
and routing. To allow the routers within the site to function properly, each LAN
is assigned a subnet number. The host portion of the internet address is partitioned
into a subnet number and a host number to accommodate this new level
of addressing.
Within the subnetted network, the local routers must route on the basis of
an extended network number consisting of the network portion of the IP address
and the subnet number. The address mask indicates the bit positions containing this
extended network number. The use of the address mask allows the host to determine
whether an outgoing datagram is destined for a host on the same LAN (send
directly) or another LAN (send datagram to router). It is assumed that some other
means (e.g., manual configuration) are used to create address masks and make them
known to the local routers.

8. Table 11.1 IP Addresses and Subnet Masks
Table 11.1a shows the calculations involved in the use of a subnet mask. Note that
the effect of the subnet mask is to erase the portion of the host field that refers to an
actual host on a subnet. What remain are the network number and the subnet number.
The default subnet mask for a given class of addresses is a null mask (Table 11.1b),
which yields the same network and host number as the non-subnetted address.

9. Example of Subnetworking
Figure 11.1 shows an example of the use of subnetting. The figure
shows a local complex consisting of three LANs and two routers. To the rest of the
internet, this complex is a single network with a Class C address of the form
x , where the leftmost three octets are the network number and the rightmost
octet contains a host number x . Both routers R1 and R2 are configured with
a subnet mask with the value (see Table 11.1a). For example, if a
datagram with the destination address arrives at R1 either from the
rest of the internet or from LAN Y, R1 applies the subnet mask to determine that
this address refers to subnet 1, which is LAN X, and so forwards the datagram to
LAN X. Similarly, if a datagram with that destination address arrives at R2 from
LAN Z, R2 applies the mask and then determines from its forwarding database
that datagrams destined for subnet 1 should be forwarded to R1. Hosts must also
employ a subnet mask to make routing decisions.

10. Classless Inter-Domain Routing (CIDR)
Makes more efficient use of the 32-bit IP address than the class-based method
Does away with the class designation and with the use of leading bits to identify a class
Each 32-bit address consists of a leftmost network part and a rightmost host part, with all 32 bits used for addressing
Associated with each IP address is a prefix value that indicates the length of the network portion of the address
A CIDR IP address is written as a.b.c.d/p
a is the value of the first byte of the address
b the value of the second byte
c the value of the third byte
d the value of the fourth byte
p is in the range of 1 through 32 and indicates the length of the network portion of the address
By the mid-1990s, it became evident to
Internet designers and administrators that the 32-bit class-based addressing scheme
was woefully inadequate for the growing demand for IP addresses. The long-term
solution to this problem, as described in Chapter 8, was the development of IPv6,
which includes 128-bit address fields. The use of 128-bit addresses increases the number
of possible unique addresses by a factor of almost compared to the use of
32-bit addresses.
However, the deployment of IPv6 would take many years so, as an interim
measure, CIDR was adopted. CIDR makes more efficient use of the 32-bit IP
address than the class-based method primarily because it makes more efficient
use of the address space. With class-based addressing, an organization can request
a block of addresses that provides 8, 16, or 24 bits for host addresses. Because
Internet addresses were typically only assigned as blocks of a certain class, there
were a lot of wasted addresses.
CIDR does away with the class designation and with the use of leading bits
to identify a class. Instead, each 32-bit address consists of a leftmost network part
and a rightmost host part, with all 32 bits used for addressing. Associated with each
IP address is a prefix value that indicates the length of the network portion of the
address. A CIDR IP address is written as a .b .c .d /p , where a is the value of the first
byte of the address, b the value of the second byte, c the value of the third byte, and
d the value of the fourth byte. Each of these values is in the range of 0 to 255. The
prefix value p is in the range of 1 through 32 and indicates the length of the network
portion of the address.
In CIDR notation, a prefix is shown as a 4-octet quantity, just like a traditional
IPv4 address or network number, followed by the “/” (slash) character, followed
by a decimal value from 0 through 32. For example, the legacy “Class B” network
, with an implied network mask of , is defined as the prefix
/16, the “/16” indicating that the mask to extract the network portion of the
prefix is a 32-bit value where the most significant 16 bits are ones and the least significant
16 bits are zeros. Similarly, the legacy “Class C” network number
is defined as the prefix /24; the most significant 24 bits are ones and the
least significant 8 bits are zeros.
Note that each 32-bit address still has (and must have) a unique interpretation.
That is, each IP address must have associated with it a prefix value p for proper routing
to the correct network and delivery to the correct host. However, the IP address field
only provides space for the 32-bit IP address and not for the prefix value. Accordingly,
each CIDR routing table entry in each Internet router contains a 32-bit IP address and
a 32-bit network mask, which together give the length of the IP prefix. Clearly, it would
be impractical to have an entry for each of the 232 possible IP addresses together with
a mask at each router. Instead, multiple IP addresses referring to a block of CIDR
addresses can be identified with a single mask, a process known as supernetting.

11. IPv6 Addresses
IPv6 addresses are 128 bits in length. Addresses are assigned to individual interfaces
on nodes, not to the nodes themselves. A single interface may have multiple
unique unicast addresses. Any of the unicast addresses associated with a node’s
interface may be used to uniquely identify that node. As with IPv4, IPv6 addresses
use CIDR rather than address classes.
The combination of long addresses and multiple addresses per interface
enables improved routing efficiency over IPv4. Longer internet addresses allow
for aggregating addresses by hierarchies of network, access provider, geography,
corporation, and so on. Such aggregation should make for smaller routing tables
and faster table lookups. The allowance for multiple addresses per interface would
allow a subscriber that uses multiple access providers across the same interface to
have separate addresses aggregated under each provider’s address space.
IPv6 allows three types of addresses (Figure 11.2):
• Unicast: An identifier for a single interface. A packet sent to a unicast address
is delivered to the interface identified by that address.
• Anycast: An identifier for a set of interfaces (typically belonging to different
nodes). A packet sent to an anycast address is delivered to one of the interfaces
identified by that address (the “nearest” one, according to the routing
protocols’ measure of distance).
• Multicast: An identifier for a set of interfaces (typically belonging to different
nodes). A packet sent to a multicast address is delivered to all interfaces
identified by that address.
The notation for an IPv6 address uses eight hexadecimal number to represent
the eight 16-bit blocks in the 128-bit address, with the numbers divided by colons.
For example:
FE80:0000:0000:0000:0001:0800:23E7:F5DB
To make the notation more compact, leading zeroes in any hexadecimal number are
omitted. For the preceding example, the result is:
FE80:0:0:0:1:800:23E7:F5DB
To further compress the representation, a zero or any contiguous sequence of zeroes
is replaced by a double colon. For our example, the result is:
FE80::1:800:23E7:F5DB

12. Internet Routing Protocols
Responsible for receiving and forwarding packets between interconnected networks
Make routing decisions based on the knowledge of the topology and traffic/delay conditions of the Internet
Must dynamically adapt to changing network conditions
In considering the routing function, it is important to distinguish two concepts:
Routing information
Information about the topology and delays of the internet
Routing algorithm
The algorithm used to make a routing decision for a particular datagram, based on current routing information
The routers in an internet are responsible for receiving and forwarding packets
through the interconnected set of networks. Each router makes routing decisions
based on knowledge of the topology and traffic/delay conditions of the internet.
In a simple internet, a fixed routing scheme is possible, in which a single,
permanent route is configured for each source–destination pair of nodes in the
network. The routes are fixed, or at most only change when there is a change in
the topology of the network. Thus, the link costs used in designing routes cannot
be based on any dynamic variable such as traffic. They could, however, be based
on estimated traffic volumes between various source–destination pairs or the
capacity of each link.
In more complex internets, a degree of dynamic cooperation is needed among
routers. In particular, routers must avoid portions of the network that have failed
and should avoid portions of the network that are congested. To make such dynamic
routing decisions, routers exchange routing information using a special routing
protocol for that purpose. Information is needed about which networks can be
reached by which routes, and the delay characteristics of various routes.
In considering the routing function, it is important to distinguish two concepts:
• Routing information: Information about the topology and delays of the
internet
• Routing algorithm: The algorithm used to make a routing decision for a particular
datagram, based on current routing information

13. Autonomous Systems
A set of routers and networks managed by a single organization
Consists of a group of routers exchanging information via a common routing protocol
Except in times of failure, there is a path between any pair of nodes
Interior Router Protocol (IRP) passes information between routers within an AS
The protocol used within the AS does not need to be implemented outside of the system
This flexibility allows IRPs to be custom tailored to specific applications and requirements
To proceed with our discussion of routing protocols, we need to introduce the concept
of an autonomous system (AS) . An AS exhibits the following characteristics:
1. An AS is a set of routers and networks managed by a single organization.
2. An AS consists of a group of routers exchanging information via a common
routing protocol.
3. Except in times of failure, an AS is connected (in a graph-theoretic sense);
that is, there is a path between any pair of nodes.
A shared routing protocol, which we shall refer to as an interior router
protocol (IRP) , passes routing information between routers within an AS. The
protocol used within the AS does not need to be implemented outside of the
system. This flexibility allows IRPs to be custom tailored to specific applications
and requirements.

14. Application of Exterior and Interior Routing Protocols
It may happen, however, that an internet will be constructed of more than
one AS. For example, all of the LANs at a site, such as an office complex or campus,
could be linked by routers to form an AS. This system might be linked through
a wide area network to other ASs. The situation is illustrated in Figure In
this case, the routing algorithms and information in routing tables used by routers
in different ASs may differ. Nevertheless, the routers in one AS need at least a
minimal level of information concerning networks outside the system that can
be reached. We refer to the protocol used to pass routing information between
routers in different ASs as an exterior router protocol (ERP) .
In general terms, IRPs and ERPs have a somewhat different flavor. An IRP
needs to build up a rather detailed model of the interconnection of routers within
an AS in order to calculate the least-cost path from a given router to any network
within the AS. An ERP supports the exchange of summary reachability information
between separately administered ASs. Typically, this use of summary information
means that an ERP is simpler and uses less detailed information than an IRP.
In the remainder of this section, we look at what are perhaps the most important
examples of these two types of routing protocols: BGP and OSPF.

15. Border Gateway Protocol (BGP)
Developed for use in conjunction with internets that employ the TCP/IP suite
Has become the preferred ERP for the Internet
Was designed to allow routers in different ASs to cooperate in the exchange of routing information
Operates in terms of messages, which are sent over TCP connections
BGP-4 is the current version
Three functional procedures:
Neighbor acquisition
Neighbor reachability
Network reachability
The Border Gateway Protocol (BGP) was developed for use in conjunction with
internets that employ the TCP/IP suite, although the concepts are applicable to any
internet. BGP has become the preferred exterior router protocol for the Internet.
BGP was designed to allow routers, called gateways in the standard, in different
ASs to cooperate in the exchange of routing information. The protocol operates
in terms of messages, which are sent over TCP connections. The current version of
BGP is known as BGP-4.

16. BGP Functional Procedures
Neighbor acquisition
The term neighbor refers to two routers that share the same network
Acquisition occurs when two neighboring routers in different autonomous systems agree to exchange routing information regularly
Neighbor reachability
Used to maintain a neighbor relationship
Network reachability
Each router maintains a database of the networks that it can reach and the preferred route for reaching each network
Whenever a change is made to this database the router issues an Update message that is broadcast to all other routers for which it has a neighbor relationship
Three functional procedures are involved in BGP:
• Neighbor acquisition
• Neighbor reachability
• Network reachability
Two routers are considered to be neighbors if they are attached to the same
network. If the two routers are in different autonomous systems, they may wish
to exchange routing information. For this purpose, it is necessary first to perform
neighbor acquisition . The term neighbor refers to two routers that share the same
network. In essence, neighbor acquisition occurs when two neighboring routers in
different autonomous systems agree to exchange routing information regularly.
A formal acquisition procedure is needed because one of the routers may not
wish to participate. For example, the router may be overburdened and may not
want to be responsible for traffic coming in from outside the AS. In the neighbor
acquisition process, one router sends a request message to the other, which may
either accept or refuse the offer. The protocol does not address the issue of how
one router knows the address or even the existence of another router, nor how it
decides that it needs to exchange routing information with that particular router.
These issues must be dealt with at configuration time or by active intervention of
a network manager.
To perform neighbor acquisition, one router sends an Open message to
another. If the target router accepts the request, it returns a Keepalive message in
response.
Once a neighbor relationship is established, the neighbor reachability
procedure is used to maintain the relationship. Each partner needs to be assured
that the other partner still exists and is still engaged in the neighbor relationship.
For this purpose, the two routers periodically issue Keepalive messages to
each other.
The final procedure specified by BGP is network reachability . Each router
maintains a database of the networks that it can reach and the preferred route for
reaching each network. Whenever a change is made to this database, the router
issues an Update message that is broadcast to all other routers for which it has a
neighbor relationship. Because the Update message is broadcast, all BGP routers
can build up and maintain their routing information.

17. Open Shortest Path First (OSPF) Protocol
Widely used as an IRP in TCP/IP networks
Uses a link state routing algorithm
Computes a route through the internet that incurs the least cost base on a user-configurable metric of cost
Each router maintains a database that reflects the known topology of the AS of which it is a part
The topology is expressed as a directed graph consisting of:
Vertices, or nodes of two types:
Router
Network, which is in turn of two types:
Transit
Stub
Edges, of two types:
A graph edge that connects two router vertices when the corresponding routers are connected to each other by a direct point-to-point link
A graph edge that connects a router vertex to a network vertex when the router is directly connected to the network
The OSPF protocol is widely used as an interior router protocol in TCP/IP
networks. OSPF uses what is known as a link state routing algorithm. Each router
maintains descriptions of the state of its local links to networks, and from time to
time transmits updated state information to all of the routers of which it is aware.
Every router receiving an update packet must acknowledge it to the sender. Such
updates produce a minimum of routing traffic because the link descriptions are
small and rarely need to be sent.
OSPF computes a route through the internet that incurs the least cost based
on a user-configurable metric of cost. The user can configure the cost to express a
function of delay, data rate, dollar cost, or other factors. OSPF is able to equalize
loads over multiple equal-cost paths.
Each router maintains a database that reflects the known topology of the
autonomous system of which it is a part. The topology is expressed as a directed graph.
The graph consists of the following:
• Vertices, or nodes, of two types:
—Router
—Network, which is in turn of two types:
• Transit, if it can carry data that neither originates nor terminates on an
end system attached to this network
• Stub, if it is not a transit network
• Edges, of two types:
— A graph edge that connects two router vertices when the corresponding
routers are connected to each other by a direct point-to-point link
— A graph edge that connects a router vertex to a network vertex when the
router is directly connected to the network

18. A Sample Autonomous System
Figure 11.4 shows an example of an autonomous system (only one host is
shown). A link cost is associated with a transmission from each router along each
of its interfaces to a network or directly to a host. If a router is connected to other
autonomous systems, then the path cost to each network in the other system must
be obtained by some exterior routing protocol (ERP).

19. Multicasting
Sending a packet from a source to the members of a multicast group
Multicast addresses
Addresses that refer to a group of hosts on one or more networks
Practical applications include:
Multimedia
Teleconferencing
Database
Distributed computation
Real-time workgroup
Typically, an IP address refers to an individual host on a particular network. IP also
accommodates addresses that refer to a group of hosts on one or more networks.
Such addresses are referred to as multicast addresses , and the act of sending a packet
from a source to the members of a multicast group is referred to as multicasting .
Multicasting has a number of practical applications. For example,
• Multimedia: A number of users “tune in” to a video or audio transmission
from a multimedia source station.
• Teleconferencing: A group of workstations form a multicast group such that a
transmission from any member is received by all other group members.
• Database: All copies of a replicated file or database are updated at the same
time.
• Distributed computation: Intermediate results are sent to all participants.
• Real-time workgroup: Files, graphics, and messages are exchanged among
active group members in real time.
Multicasting done within the scope of a single LAN segment is straightforward.
IEEE 802 and other LAN protocols include provision for MAC-level
multicast addresses. A packet with a multicast address is transmitted on a LAN
segment. Those stations that are members of the corresponding multicast group
recognize the multicast address and accept the packet. In this case, only a single
copy of the packet is ever transmitted. This technique works because of the broadcast
nature of a LAN: a transmission from any one station is received by all other
stations on the LAN.

20. Illustration of Multicasting
In an internet environment, multicasting is a far more difficult undertaking. To
see this, consider the configuration of Figure 11.5, in which a number of LANs are
interconnected by routers. Routers connect to each other either over high-speed
links or across a wide area network (network N4). A cost is associated with each
link or network in each direction, indicated by the value shown leaving the router
for that link or network. Suppose that the multicast server on network N1 is transmitting
packets to a multicast address that represents the workstations indicated
on networks N3, N5, and N6. Suppose that the server does not know the location
of the members of the multicast group. Then one way to assure that the packet
is received by all members of the group is to broadcast a copy of each packet to
each network in the configuration, over the least-cost route for each network. For
example, one packet would be addressed to N3 and would traverse N1, link L3, and
N3. Router B is responsible for translating the IP-level multicast address to a MAClevel
multicast address before transmitting the MAC frame onto N3.

21. Traffic Generated by Various Multicasting Strategies
Table 11.2
summarizes the number of packets generated on the various links and networks in
order to transmit one packet to a multicast group by this method. In this table, the
source is the multicast server on network N1 in Figure 11.5; the multicast address
includes the group members on N3, N5, and N6. Each column in the table refers to
the path taken from the source host to a destination router attached to a particular
destination network. Each row of the table refers to a network or link in the configuration
of Figure Each entry in the table gives the number of packets that
traverse a given network or link for a given path. A total of 13 copies of the packet
are required for the broadcast technique.
Now suppose the source system knows the location of each member of the
multicast group. That is, the source has a table that maps a multicast address into
a list of networks that contain members of that multicast group. In that case, the
source need only send packets to those networks that contain members of the group.
We could refer to this as the multiple unicast strategy. Table 11.2 shows that in this
case, 11 packets are required.
Both the broadcast and multiple unicast strategies are inefficient because they
generate unnecessary copies of the source packet. In a true multicast strategy, the
following method is used:
1. The least-cost path from the source to each network that includes members of
the multicast group is determined. This results in a spanning tree of the configuration.
The spanning tree is a set of all the networks that include multicast
members, plus sufficient links between networks to establish a route from a
source to all multicast members.
2. The source transmits a single packet along the spanning tree.
3. The packet is replicated by routers only at branch points of the spanning tree.

22. Multicast Routing Protocols
At the local level, individual hosts need a method of joining or leaving a multicast group
Internet Group Management Protocol (IGMP)
Used between hosts and routers on a broadcast network such as Ethernet or a wireless LAN to exchange multicast group membership information
Supports two principal operations:
Hosts send messages to routers to subscribe to and unsubscribe from a multicast group defined by a given multicast address
Routers periodically check which multicast groups are of interest to which hosts
For multicasting to work, the source of a multicast packet, together with Internet
routers, must identify networks that include hosts with the given multicast address
and determine a route that will reach all hosts in the group. For this purpose, a
number of address discovery and routing protocols are used at different levels of the
Internet architecture.
At the local level, individual hosts need a method of
joining or leaving a multicast group. The host needs to be able to alert a router
on its local network of its membership status in a multicast group. On a broadcast
network, such as Ethernet or a wireless LAN, the Internet Group Management
Protocol (IGMP) is used between hosts and routers to exchange multicast
group membership information. IGMP takes advantage of the broadcast
nature of a LAN to provide an efficient technique for the exchange of information
among multiple hosts and routers. In general, IGMP supports two principal
operations:
1. Hosts send messages to routers to subscribe to and unsubscribe from a multicast
group defined by a given multicast address.
2. Routers periodically check which multicast groups are of interest to which
hosts.

23. Interior Routing Protocols
Routers must cooperate across an organization’s internet or across the Internet to route and deliver multicast IP packets
Routers need to know which networks include members of a given multicast group
Routers need sufficient information to calculate the shortest path to each network containing group members
Multicast Extensions to OSPF (MOSPF)
Enhancement to OSPF for the exchange of multicast routing information
Protocol Independent Multicast (PIM)
Designed to extract needed routing information from any unicast routing protocol and may support routing protocols that operate across multiple ASs with a number of different unicast routing protocols
IGMP enables a router to know of hosts on an
attached network that are using a particular multicast IP address. Next, routers
must cooperate across an organization’s internet or across the Internet to route
and deliver multicast IP packets. Routers must exchange two sorts of information.
First, routers need to know which networks include members of a given multicast
group. Second, routers need sufficient information to calculate the shortest path to
each network containing group members. These requirements imply the need for a
multicast routing protocol.
Within an AS, a number of alternative multicast routing protocols have
been developed. We mention two here. Multicast Extensions to OSPF (MOSPF)
is an enhancement to OSPF for the exchange of multicast routing information.
Periodically, each router floods information about local group membership to all
other routers in its AS. The result is that all routers in an AS are able to build up
a complete picture of the location of all group members for each multicast group.
Each router constructs the shortest-path spanning tree from a source network to
all networks containing members of a multicast group.
Protocol Independent Multicast (PIM) provides a more general solution to
multicast routing than MOSPF. As the name suggests, PIM is a separate routing
protocol, independent of any existing unicast routing protocol. PIM is designed
to extract needed routing information from any unicast routing protocol and may
support routing protocols that operate across multiple ASs with a number of
different unicast routing protocols.

24. Emergence of High-Speed LANs
In recent years two significant trends altered the role of the personal computer and therefore the requirements on the LAN:
The more powerful platforms of personal computers support graphics-intensive applications and ever more elaborate graphical user interfaces to the operating system
Information technology (IT) organizations have recognized the LAN as a viable and essential computer platform, resulting in the focus on network computing
Traditionally, office LANs provided basic connectivity services—connecting
personal computers and terminals to mainframes and midrange systems that ran corporate
applications and providing workgroup connectivity at the departmental or
divisional level. In both cases, traffic patterns were relatively light, with an emphasis
on file transfer and electronic mail. The LANs that were available for this type of
workload, primarily Ethernet and token ring, were well suited to this environment.
In recent years, two significant trends altered the role of the personal computer
and therefore the requirements on the LAN:
1. The speed and computing power of personal computers continued to enjoy
explosive growth. These more powerful platforms support graphics-intensive
applications and ever more elaborate graphical user interfaces to the operating
system.
2. IT (information technology) organizations have recognized the LAN as a
viable and essential computing platform, resulting in the focus on network
computing. This trend began with client/server computing, which has become a
dominant architecture in the business environment and the more recent Web-focused
intranet trend. Both of these approaches involve the frequent transfer
of potentially large volumes of data in a transaction-oriented environment.
The effect of these trends has been to increase the volume of data to be handled
over LANs and, because applications are more interactive, to reduce the acceptable
delay on data transfers. The earlier generation of 10-Mbps Ethernets and 16-Mbps
token rings is simply not up to the job of supporting these requirements.

25. Corporate WAN Needs Greater dispersal of employee base
Growing use of telecommuting
Changing application structures
Increased client/server and intranet
More reliance on personal computers, workstations, and servers
GUIs enables the end user to exploit graphic applications, multimedia, and other data-intensive applications
Dependence on Internet access
More data must be transported off premises and onto WANs
As recently as the early 1990s, there was an emphasis in many organizations on a
centralized data processing model. In a typical environment, there might be significant
computing facilities at a few regional offices, consisting of mainframes or well equipped
midrange systems. These centralized facilities could handle most corporate
applications, including basic finance, accounting, and personnel programs, as well
as many of the business-specific applications. Smaller, outlying offices (e.g., a bank
branch) could be equipped with terminals or basic personal computers linked to one
of the regional centers in a transaction-oriented environment.
This model began to change in the early 1990s, and the change accelerated
through the mid-1990s. Many organizations have dispersed their employees into
multiple smaller offices. There is a growing use of telecommuting. Most significant,
the nature of the application structure has changed. First client/server computing
and, more recently, intranet computing have fundamentally restructured the
organizational data processing environment. There is now much more reliance on
personal computers, workstations, and servers and much less use of centralized
mainframe and midrange systems. Furthermore, the virtually universal deployment
of graphical user interfaces to the desktop enables the end user to exploit graphic
applications, multimedia, and other data-intensive applications. In addition, most
organizations require access to the Internet. Because a few clicks of the mouse can
trigger huge volumes of data, traffic patterns have become more unpredictable while
the average load has risen.
All of these trends mean that more data must be transported off premises and
onto WANs. It has long been accepted that in the typical business environment,
about 80, of the traffic remains local and about 20, traverses wide area links. But
this rule no longer applies to most companies, with a greater percentage of the traffic
going into the WAN environment. This traffic flow shift places a greater burden
on LAN backbones and, of course, on the WAN facilities used by a corporation.
Thus, just as for LANs, changes in corporate data traffic patterns are driving the
creation of high-speed WANs.

26. Internet Traffic Elastic Traffic Inelastic Traffic
Can adjust, over wide ranges, to changes in delay and throughput across an internet and still meet the needs of its applications
Type of traffic for which internets were designed
Applications include file transfer, electronic mail, remote logon, network management, and Web access
Inelastic Traffic
Does not adapt well, if at all, to changes in delay and throughput across an internet
Examples include real-time traffic, such as voice and video
Traffic on a network or internet can be divided into two broad categories: elastic
and inelastic. A consideration of their differing requirements clarifies the need for
an enhanced internet architecture.
Elastic traffic can adjust, over wide ranges, to changes in delay and throughput
across an internet and still meet the needs of its applications. This is the traditional
type of traffic supported on TCP/IP-based internets and is the type of traffic for
which internets were designed. With TCP, traffic on individual connections adjusts
to congestion by reducing the rate at which data are presented to the network.
Elastic applications include common Internet-based applications, such as file
transfer, electronic mail, remote logon, network management, and Web access. But
there are differences among the requirements of these applications. For example,
• is generally insensitive to changes in delay.
• When file transfer is done interactively, as it frequently is, the user expects
the delay to be proportional to the file size and so is sensitive to changes in
throughput.
• With network management, delay is generally not a serious concern. However,
if failures in an internet are the cause of congestion, then the need for network
management messages to get through with minimum delay increases with
increased congestion.
• Interactive applications, such as remote logon and Web access, are sensitive to
delay.
So, even if we confine our attention to elastic traffic, a QoS-based internet
service could be of benefit. Without such a service, routers are dealing evenhandedly
with arriving IP packets, with no concern for the type of application and whether
this packet is part of a large transfer or a small one. Under such circumstances, and
if congestion develops, it is unlikely that resources will be allocated in such a way
as to meet the needs of all applications fairly. When inelastic traffic is added to the
mix, matters are even more unsatisfactory.
Inelastic traffic does not easily adapt, if at all, to changes in delay and throughput
across an internet. The prime example is real-time traffic, such as voice and
video.

27. Requirements of Inelastic Traffic
A minimum value may be required
Throughput
Services like stock trading are delay-sensitive
Delay
Because of delays imposed by the Internet, the interarrival times between packets are not maintained at a fixed interval at the destination
Incoming packets are buffered, delayed, and then released at a constant rate to the software that is expecting a steady real-time stream
Real-time interactive applications, such as teleconferencing, may require a reasonable upper bound on jitter
Delay variation (jitter)
Real-time applications vary in the amount of packet loss, if any, that they can sustain
Packet loss
The requirements for inelastic traffic may include the following:
• Throughput: A minimum throughput value may be required. Unlike most
elastic traffic, which can continue to deliver data with perhaps degraded
service, many inelastic applications require a firm minimum throughput.
• Delay: An example of a delay-sensitive application is stock trading; someone
who consistently receives later service will consistently act later, and with
greater disadvantage.
• Jitter: The magnitude of delay variation, called jitter , is a critical factor in real-time
applications. Because of the variable delay imposed by the Internet, the
interarrival times between packets are not maintained at a fixed interval at the
destination. To compensate for this, the incoming packets are buffered, delayed
sufficiently to compensate for the jitter, and then released at a constant rate to
the software that is expecting a steady real-time stream. The larger the allowable
delay variation, the longer the real delay in delivering the data and the
greater the size of the delay buffer required at receivers. Real-time interactive
applications, such as teleconferencing, may require a reasonable upper bound
on jitter.
• Packet loss: Real-time applications vary in the amount of packet loss, if any,
that they can sustain.
These requirements are difficult to meet in an environment with variable
queuing delays and congestion losses. Accordingly, inelastic traffic introduces two
new requirements into the internet architecture. First, some means is needed to
give preferential treatment to applications with more demanding requirements.
Applications need to be able to state their requirements, either ahead of time in
some sort of service request function, or on the fly, by means of fields in the IP
packet header.
A second requirement in supporting inelastic traffic in an internet architecture
is that elastic traffic must still be supported. Inelastic applications typically do not
back off and reduce demand in the face of congestion, in contrast to TCP-based
applications. Therefore, unless some control is imposed, in times of congestion
inelastic traffic will continue to supply a high load and elastic traffic will be crowded
off the internet.
Several mechanisms for providing QoS services on the Internet have been
proposed. The one that has received the broadest acceptance is known as differentiated
services. We turn to this topic next.

28. Differentiated Services (DS)
Key characteristics:
No change is required to IP
Existing applications need not be modified to use DS
Provides a built-in aggregation mechanism – all traffic with the same DS octet is treated the same by the network service
Routers deal with each packet individually and do not have to save state information on packet flows
Provide QoS on the basis of the needs of different groups of users
Most widely accepted QoS mechanism in enterprise networks
As the burden on the Internet grows, and as the variety of applications grows, there
is an immediate need to provide differing levels of QoS to different users. The
differentiated services (DS) architecture is designed to provide a simple, easy-to-implement,
low-overhead tool to support a range of network services that are differentiated
on the basis of performance. In essence, differentiated services do not
provide QoS on the basis of flows but rather on the basis of the needs of different
groups of users. This means that all the traffic on the Internet is split into groups
with different QoS requirements and that routers recognize different groups on the
basis of a label in the IP header.
Several key characteristics of DS contribute to its efficiency and ease of
deployment:
• IP packets are labeled for differing QoS treatment using the 6-bit DS field in
the IPv4 and IPv6 headers (Figure 8.7). No change is required to IP.
• A service level agreement (SLA) is established between the service provider
(internet domain) and the customer prior to the use of DS. This avoids the
need to incorporate DS mechanisms in applications. Thus, existing applications
need not be modified to use DS.
• DS provides a built-in aggregation mechanism. All traffic with the same DS
octet is treated the same by the network service. For example, multiple voice
connections are not handled individually but in the aggregate. This provides
for good scaling to larger networks and traffic loads.
• DS is implemented in individual routers by queuing and forwarding packets
based on the DS octet. Routers deal with each packet individually and do not
have to save state information on packet flows.
Today, DS is the most widely accepted QoS mechanism in enterprise networks.

29. Services
A DS framework document lists all the following detailed performance parameters that might be included in an SLA
Service performance parameters, such as expected throughput, drop probability, and latency
Constraints on the ingress and egress points at which the service is provided, indicating the scope of the service
Traffic profiles that must be adhered to for the requested service to be provided
Disposition of traffic submitted in excess of the specified profile
The DS type of service is provided within a DS domain, which is defined as a
contiguous portion of the Internet over which a consistent set of DS policies are
administered. Typically, a DS domain would be under the control of one administrative
entity. The services provided across a DS domain are defined in a service level
agreement, which is a service contract between a customer and the service provider
that specifies the forwarding service that the customer should receive for various
classes of packets. A customer may be a user organization or another DS domain.
Once the SLA is established, the customer submits packets with the DS octet marked
to indicate the packet class. The service provider must assure that the customer gets
at least the agreed QoS for each packet class. To provide that QoS, the service provider
must configure the appropriate forwarding policies at each router (based on
DS octet value) and must measure the performance being provided to each class on
an ongoing basis.
If a customer submits packets intended for destinations within the DS domain,
then the DS domain is expected to provide the agreed service. If the destination is
beyond the customer’s DS domain, then the DS domain will attempt to forward the
packets through other domains, requesting the most appropriate service to match
the requested service.
A DS framework document lists the following detailed performance parameters
that might be included in an SLA:
• Service performance parameters, such as expected throughput, drop probability,
and latency
• Constraints on the ingress and egress points at which the service is provided,
indicating the scope of the service
• Traffic profiles that must be adhered to for the requested service to be provided
• Disposition of traffic submitted in excess of the specified profile

30. DS Services Provided
Traffic offered at service level A will be delivered with low latency
Traffic offered at service level B will be delivered with low loss
90% of in-profile traffic delivered at service level C will experience no more than 50 ms latency
95% of in-profile traffic delivered at service level D will be delivered
Traffic offered at service level E will be allotted twice the bandwidth of traffic delivered at service level F
Traffic with drop precedence X has a higher probability of delivery than traffic with drop precedence Y
The framework document also gives some examples of services that might be
provided:
1. Traffic offered at service level A will be delivered with low latency.
2. Traffic offered at service level B will be delivered with low loss.
3. Ninety percent of in-profile traffic delivered at service level C will experience
no more than 50 ms latency.
4. Ninety-five percent of in-profile traffic delivered at service level D will be
delivered.
5. Traffic offered at service level E will be allotted twice the bandwidth of traffic
delivered at service level F.
6. Traffic with drop precedence X has a higher probability of delivery than traffic
with drop precedence Y.
The first two examples are qualitative and are valid only in comparison to other
traffic, such as default traffic that gets a best-effort service. The next two examples
are quantitative and provide a specific guarantee that can be verified by measurement
on the actual service without comparison to any other services offered at the
same time. The final two examples are a mixture of quantitative and qualitative.

31. Value of field is “codepoint”
Packets are labeled for handling in 6-bit DS field in the IPv4 header, or the IPv6 header
Value of field is “codepoint”
6-bits allows 64 codepoints in 3 pools
Form xxxxx0 - reserved for assignment as standards
Form xxxx11 - reserved for experimental or local use
Form xxxx01 - also reserved for experimental or local use, but may be allocated for future standards action as needed
Precedence subfield indicates urgency
Route selection, Network service, Queuing discipline
RFC 1812 provides two categories of recommendations for queuing discipline
Queue Service
Congestion Control
DS Field
Packets are labeled for service handling by means of the 6-bit DS field in the IPv4
header or the IPv6 header (Figure 8.7). The value of the DS field, referred to as the
DS codepoint , is the label used to classify packets for differentiated services.
With a 6-bit codepoint, there are, in principle, 64 different classes of traffic
that could be defined. These 64 codepoints are allocated across three pools of
codepoints, as follows:
• Codepoints of the form xxxxx0, where x is either 0 or 1, are reserved for
assignment as standards.
• Codepoints of the form xxxx11 are reserved for experimental or local use.
• Codepoints of the form xxxx01 are also reserved for experimental or local use
but may be allocated for future standards action as needed.

32. DS Domains
Figure 11.6 illustrates the type of configuration envisioned in the DS documents. A
DS domain consists of a set of contiguous routers; that is, it is possible to get from
any router in the domain to any other router in the domain by a path that does
not include routers outside the domain. Within a domain, the interpretation of DS
codepoints is uniform, so that a uniform, consistent service is provided.

33. DS Configuration and Operation
Interior Nodes
Boundary Nodes
Implement simple mechanisms for handling packets based on their DS codepoint values
Includes:
A queuing discipline to give preferential treatment depending on codepoint value
Packet-dropping rules to dictate which packets should be dropped first in the event of buffer saturation
Forwarding treatment is per-hop behavior (PHB)
Must be available at all routers
Is the only part of DS implemented in interior routers
Includes PHB mechanisms as well as more sophisticated traffic conditioning mechanisms required to provide the desired service
Can also be provided by a host system attached to the domain on behalf of the applications at that host system
Routers in a DS domain are either boundary nodes or interior nodes. Typically,
the interior nodes implement simple mechanisms for handling packets based on their
DS codepoint values. This includes a queuing discipline to give preferential treatment
depending on codepoint value, and packet-dropping rules to dictate which
packets should be dropped first in the event of buffer saturation. The DS specifications
refer to the forwarding treatment provided at a router as per-hop behavior
(PHB). This PHB must be available at all routers, and typically PHB is the only part
of DS implemented in interior routers.
The boundary nodes not only include PHB mechanisms but also more sophisticated
traffic conditioning mechanisms required to provide the desired service. Thus,
interior routers have minimal functionality and minimal overhead in providing the
DS service, while most of the complexity is in the boundary nodes. The boundary
node function can also be provided by a host system attached to the domain, on
behalf of the applications at that host system.

34. Traffic Conditioning Function Elements:
Classifier
Separates submitted packets into different classes
Meter
Measures submitted traffic for conformance to a profile
Marker
Re-marks packets with a different codepoint as needed
Shaper
Delays packets as necessary so that the packet stream in a given class does not exceed the traffic rate specified in the profile for that class
Dropper
Drops packets when the rate of packets of a given class exceeds that specified in the profile for that class
The traffic conditioning function consists of five elements:
• Classifier: Separates submitted packets into different classes. This is the
foundation of providing differentiated services. A classifier may separate
traffic only on the basis of the DS codepoint (behavior aggregate classifier)
or based on multiple fields within the packet header or even the packet
payload (multifield classifier).
• Meter: Measures submitted traffic for conformance to a profile. The meter
determines whether a given packet stream class is within or exceeds the
service level guaranteed for that class.
• Marker: Re-marks packets with a different codepoint as needed. This may be
done for packets that exceed the profile; for example, if a given throughput is
guaranteed for a particular service class, any packets in that class that exceed
the throughput in some defined time interval may be re-marked for best-effort
handling. Also, re-marking may be required at the boundary between two DS
domains. For example, if a given traffic class is to receive the highest supported
priority, and this is a value of 3 in one domain and 7 in the next domain,
then packets with a priority 3 value traversing the first domain are re-marked
as priority 7 when entering the second domain.
• Shaper: Delays packets as necessary so that the packet stream in a given class
does not exceed the traffic rate specified in the profile for that class.
• Dropper: Drops packets when the rate of packets of a given class exceeds that
specified in the profile for that class.

35. Traffic Conditioning Diagram
Figure 11.7 illustrates the relationship between the elements of traffic
conditioning. After a flow is classified, its resource consumption must be measured.
The metering function measures the volume of packets over a particular time
interval to determine a flow’s compliance with the traffic agreement.
If a traffic flow exceeds some profile, several approaches can be taken.
Individual packets in excess of the profile may be re-marked for lower-quality
handling and allowed to pass into the DS domain. A traffic shaper may absorb
a burst of packets in a buffer and pace the packets over a longer period of time.
A dropper may drop packets if the buffer used for pacing becomes saturated.

36. Service Level Agreements (SLA)
Contract between the network provider and a customer that defines specific aspects of the service to be provided
Typically includes:
A description of the nature of service to be provided
Expected performance level of the service
Process for monitoring and reporting the service level
A service level agreement (SLA) is a contract between a network provider and a
customer that defines specific aspects of the service that is to be provided. The definition
is formal and typically defines quantitative thresholds that must be met. An
SLA typically includes the following information:
• A description of the nature of service to be provided: A basic service would
be IP-based network connectivity of enterprise locations plus access to the
Internet. The service may include additional functions such as Web hosting,
maintenance of domain name servers, and operation and maintenance tasks.
• The expected performance level of the service: The SLA defines a number of
metrics, such as delay, reliability, and availability, with numerical thresholds.
• The process for monitoring and reporting the service level: This describes how
performance levels are measured and reported.

37. Typical Framework for SLA
Figure 11.8 shows a typical configuration that lends itself to an SLA. In this
case, a network service provider maintains an IP-based network. A customer has a
number of private networks (e.g., LANs) at various sites. Customer networks are
connected to the provider via access routers at the access points. The SLA dictates
service and performance levels for traffic between access routers across the provider
network. In addition, the provider network links to the Internet and thus provides
Internet access for the enterprise.
An SLA can be defined for the overall network service. In addition, SLAs can
be defined for specific end-to-end services available across the carrier’s network,
such as a virtual private network, or differentiated services.

38. IP Performance Metrics Working Group (IPPM)
Chartered by IETF to develop standard metrics that relate to the quality, performance, and reliability of Internet data delivery
Trends dictating need:
The Internet has grown and continues to grow at a dramatic rate
The Internet serves a large and growing number of commercial and personal users across an expanding spectrum of applications
The IP Performance Metrics Working Group (IPPM) is chartered by IETF to
develop standard metrics that relate to the quality, performance, and reliability
of Internet data delivery. Two trends dictate the need for such a standardized
measurement scheme:
1. The Internet has grown and continues to grow at a dramatic rate. Its topology
is increasingly complex. As its capacity has grown, the load on the Internet
has grown at an even faster rate. Similarly, private internets, such as corporate
intranets and extranets, have exhibited similar growth in complexity, capacity,
and load. The sheer scale of these networks makes it difficult to determine
quality, performance, and reliability characteristics.
2. The Internet serves a large and growing number of commercial and personal
users across an expanding spectrum of applications. Similarly, private networks
are growing in terms of user base and range of applications. Some of
these applications are sensitive to particular QoS parameters, leading users to
require accurate and understandable performance metrics.
A standardized and effective set of metrics enables users and service providers
to have an accurate common understanding of the performance of the Internet and
private internets. Measurement data is useful for a variety of purposes, including
• Supporting capacity planning and troubleshooting of large complex internets
• Encouraging competition by providing uniform comparison metrics across
service providers
• Supporting Internet research in such areas as protocol design, congestion
control, and quality of service
• Verification of service level agreements

39. Table 11.3 (a) Sampled Metrics
Table 11.3 lists the metrics that have been defined in RFCs at the time of this
writing. Table 11.3a lists those metrics which result in a value estimated based on a
sampling technique. The metrics are defined in three stages:
• Singleton metric: The most elementary, or atomic, quantity that can be measured
for a given performance metric. For example, for a delay metric, a
singleton metric is the delay experienced by a single packet.
• Sample metric: A collection of singleton measurements taken during a given
time period. For example, for a delay metric, a sample metric is the set of
delay values for all of the measurements taken during a one-hour period.
• Statistical metric: A value derived from a given sample metric by computing
some statistic of the values defined by the singleton metric on the sample.
For example, the mean of all the one-way delay values on a sample might be
defined as a statistical metric.
Src = IP address of a host
Dst = IP address of a host

40. Table 11.3 (b) Other Metrics
The measurement technique can be either active or passive. Active techniques
require injecting packets into the network for the sole purpose of measurement.
There are several drawbacks to this approach. The load on the network is increased.
This in turn can affect the desired result. For example, on a heavily loaded network,
the injection of measurement packets can increase network delay, so that the measured
delay is greater than it would be without the measurement traffic. In addition,
an active measurement policy can be abused for denial-of-service attacks disguised
as legitimate measurement activity. Passive techniques observe and extract metrics
from existing traffic. This approach can expose the contents of Internet traffic to
unintended recipients, creating security and privacy concerns. So far, the metrics
defined by the IPPM working group are all active.
Table 11.3b lists two metrics that are not defined statistically. Connectivity
deals with the issue of whether a transport-level connection is maintained by the
network. The current specification (RFC 2678) does not detail specific sample
and statistical metrics but provides a framework within which such metrics could
be defined. Connectivity is determined by the ability to deliver a packet across a
connection within a specified time limit. The other metric, bulk transfer capacity,
is similarly specified (RFC 3148) without sample and statistical metrics but begins
to address the issue of measuring the transfer capacity of a network service with
the implementation of various congestion control mechanisms.

41. Model for Defining Packet Delay Variation
Figure 11.9 illustrates the packet delay variation metric. This metric is used
to measure jitter, or variability, in the delay of packets traversing the network. The
singleton metric is defined by selecting two packet measurements and measuring
the difference in the two delays. The statistical measures make use of the absolute
values of the delays.

42. Summary Chapter 11: Internet Operation Quality of service
Emergence of high-speed LANs
Corporate WAN needs
Internet traffic
Differentiated services
DS field
DS configuration and operation
SLAs
IP performance metrics
Internet addressing
IPv4 addressing
IPv6 addressing
Internet routing protocols
Autonomous systems
Border gateway protocol
OSPF protocol
Multicasting
Multicast transmission
Multicast routing protocols
Chapter 11 summary.
Chapter 11: Internet Operation