IP Multicasting - Beta Version

Chapter: Preface | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8

A Division of the McGraw-Hill Companies
Copyright © 1998 The McGraw-Hill Companies. All rights reserved. Any use is subject to the Terms of Use; the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers.


IP Multicasting
Marcus Goncalves
$55.00 0-07-913791-1
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Preface

Introduction

Today, the Internet and corporate intranets are being used to communicate the same information to large numbers of people. IP multicasting, a technology for efficiently sending and receiving information from a group of hosts, rather than through the more traditional one-on-one interactions, creates a single stream of data to which users subscribe. This allows a few server streams to serve much larger numbers of users. IP Multicast reduces bandwidth demands by carrying only one instance of the data to multiple destinations.

IP multicast is based on Class D IP addresses where a single address points to multiple users or group members. IP multicasting hands a file off only once to each router, which passes it on to the computers that subscribe to the information. The traditional unicast model sends separate copies of the same data to each user.

IP multicast relies on the existence of an underlying multicast delivery system to forward data from a sender to all the intended receivers. Until all the routers on the Internet are multicast-enabled, multicast through the Internet will be limited to tunneling, services offered by multicast-enabled islands, and some Internet service providers. In the meantime, however, it is possible to deploy IP multicast using a private virtual network based on a network architecture or network service that is multicast-enabled.

The next big advance in IP multicasting technology will probably come in the area of reliable delivery of data. IP multicast protocol does not include any acknowledgment mechanism to determine whether the data sent to recipients have arrived correctly. Much research is underway to address this issue and the IETF has recently formed a working group to sort out the maze of proposed protocols and tools and come up with recommendations.

IP multicast is eminently useful for deploying information from applications based on push technologies where bandwidth consumption is a problem. For example, the IP multicast protocol uses only the bandwidth required to update a single desktop in order to update several hundred desktops requesting the same data.

Multicast technology is being heavily used for experimentation into audio/video conferencing over IP. Some commercial applications are coming into their own. Big organizations such as Toys `R Us, Ford Motor Company, General Motors, The Ohio Company, and the American Stock Exchange are already using multicasting technology to solve software and information distribution problems. Some satellite delivery companies also are using IP multicast over their delivery systems.

For a full-blown implementation of IP multicast to work, both the hardware and software in the data path need to support IP multicast. The good news is that IP multicast is already supported in the newest equipment from networking vendors such as Cisco, and a few ISPs such as MCI and Uunet are beginning to deploy IP multicast services.

Who Should Read This Book

This book is an introduction to IP multicast concepts and features and is intended for users with varying degrees of experience with the IP multicast technologies, decisionmakers wrestling with the problems of corporate communication, system administrators and operators managing their own workstations, and programmers. Finally, this book is intended for communications specialists, field system engineers, and the general audience who wants or needs to know about IP multicasting.

This book can be used by those who design or develop applications that run on the network or work in technical support. It can be used to gain a basic understanding of IP multicasting and as a source for information about IP multicasting. Information about ISPs, suppliers and vendors, current and future IP multicasting applications, implementations, and supporting software is here.

For an engineer interested in evaluating or implementing IP multicast for an organization, product or service, this book will facilitate understanding of how to deploy IP multicast over these network infrastructures.

Organization

The book is organized into 24 chapters and appendices, which are broadly separated into four parts:

PART I TCP/IP and IP Multicasting Fundamentals

This part comprises Chapters 1-10 and is about the technology around IP multicasting. We provide a brief history of the Internet and introduce the different types of network infrastructures upon which IP multicast can run. This part also includes fundamentals about IP multicasting, describes how it works, introduces multicast routing concepts, algorithms, and protocols, presents interoperability, tunneling, and implementation issues, and touches on the challenges facing IP multicasting.

PART II The Mbone and Other Multicast Networks

Part two consists of Chapters 11-15 and is about preparing for and multicasting on different network infrastructures. We discuss Asynchronous Transfer Mode technology and the Mbone, we briefly look at the higher-level protocols used with IP multicast, we investigate writing IP multicast applications, and introduce some standard IP multicast application programming interfaces.

PART III IP Multicasting Applications

This consists of Chapters 16-21 and is about IP multicast applications, equipment, and suppliers. We look at some of the major players, IP multicasting application software for servers and clients, and IP multicasting content providers, management and middleware software products, and IP multicasting network service providers. Lastly we describe available IP multicasting network equipment and software development kits.

PART IV IP Multicasting Resource Center Chapters 22-24 are about techniques used for developing IP multicast-enabled applications and how to deploy IP multicast in a diverse network platform. They also cover the main IP multicast switch equipment, including both companies and their products.

Appendixes provide a comprehensive list of IP Multicast acronyms, a bibliography, and an extensive glossary.

About the Authors

Marcus Goncalves holds an MS in CIS and has several years of internetworking consulting in the IS&T arena. He is a Senior IT Analyst for Automation Research Corporation, advising manufacturers on IT, industry automation and Internetworking security. He has taught several workshops and seminars on IS and Internet security in the U.S. and internationally. He has published several books related to the subject: Firewalls Complete, IPv6 Networks and Voice Over IP Networks, all with McGraw-Hill; and Protecting Your Web Site With Firewalls and Windows NT Server Security Guide, with PTR/Prentice Hall; Internet Privacy Kit, with Que and others. He is also a regular contributor to several magazines, including Compaq Enterprise, BackOffice, Developer's and WEBster. He is a member of the Internet Society, the International Computer Security Association (ICSA), the Association for Information Systems (AIS) and the New York Academy of Sciences. Goncalves is the Chief editor of the Journal for Internet Security (JSec) of Canada.

Kitty Niles (Lincoln, MA) is currently a freelance technical writer. She was formerly a technical writer with Digital Equipment Corporation and more recently with Process Software Corporation.

She has participated in numerous hardware, software, and networking projects as lead writer and online help designer and developer. With over 18 years' experience in the computer industry, she has been documentation leader for numerous software, hardware, and marketing projects.

She has been a contributing author to books on the Web and Internet Security, and IPv6 Networks. She is a member of the HTML Writers Guild and the recipient of numerous local and international Society of Technical Communications documentation awards. She is also the recipient of numerous documentation awards from Digital Equipment Corporation. Among other things, her background includes paleobotany research, medical and environmental research, teaching, and technical illustrating.

Typographic Conventions

Code and data structures examples included in the book are expressed in Courier fonts.

A Note on Trademarks and Standards

Product names mentioned herein may be trademarks and/or registered trademarks of their respective companies.

We have made reference to many RFCs. This is a very fast-moving area and we have attempted to be as accurate as possible. Part of this book probably became out of date as we wrote it, and other parts may have changed as the book was being published. The standards and the code and applications themselves are, as always, the best source of information.

A great many RFCs were used in the preparation of this document and we gratefully acknowledge all the authors. The bibliography at the end of this book lists the RFCs and their respective authors. The following copyright notice applies to all RFCs:

Copyright (C) The Internet Society (1998). All Rights Reserved. –This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

Backward Forward
Chapter: Preface | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.
Beta Books | Beta Bookstores | Computing McGraw-Hill

Professional Publishing Home | Contact Us | Customer Service | For Authors | International Offices | New Book Alert | Search Catalog/Order | Site Map | What's New

A Division of the McGraw-Hill Companies
Copyright © 1998 The McGraw-Hill Companies, Inc. All rights reserved. Any use is subject to the Terms of Use; the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers.


Marcus Goncalves
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Chapter One

The Topology and Internal Structure of a Network

Networks form the backbone of today's business and general communication environment. Networking has become important indeed within business organizations, which rely more and more on their networks to provide everyday business communications such as e-mail, financial management, manufacturing processes, and direct links with their suppliers.

This chapter briefly reviews the history of the Internet and introduces:

• Network basics

• The TCP/IP Protocol Suite

• IP addressing

• The Address Resolution Protocol

• ICMP and IGMP

• Network Components.

Some Basics

Networks can interconnect just about every type of computer in the world even if only for the purposes of receiving and sending mail. Networks provide for information sharing in and between enterprises, government and scientific groups, educational and research institutions, and link thousands upon thousands of home computers.

There are a number of different types of networks including local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), the Internet, virtual private networks (VPN) or extranets and intranets.

Local Area Networks

LANs usually span limited geographical areas such as a single building or a college campus. A LAN is a data communication network made up of a collection of independent computers that communicate with one another over a shared network medium. LANs allow communication between a number of devices such as PCs, minitowers, workstations, terminals, and other equipment and are usually owned by the user, for example, a corporation. Bridges and routers link similar and dissimilar networks together to form an extended LAN. LANs can differ from one another in a number of ways including:

• The topology of the particular network which is the geometric arrangement of computers and other computing devices on the next work. LANs, however, are not necessarily simple in design. It is possible for a LAN to link together hundreds and hundreds of computers that can be used by many thousands of users

• The protocols used by the particular network to regulate the transfer of data between layers and across links to other devices. The protocols also determine whether the network uses peer-to-peer or client/server architecture. Specifically, protocols are the rules and encoding specifications for sending data. Protocols also define the procedures for handling lost or damaged transmissions or packets. The development and refinement of various standards for networking protocols and media have been stimulated by the proliferation of LANs worldwide for business and educational uses

• The media used by the particular network to connect the devices on the network. For example, a Fiber Distributed Data Interface (FDDI) based network connects devices with fiber optic cable. An Ethernet-based network might connect devices with twisted-pair or coaxial cable. Other networks might communicate through infrared (wireless), satellite or radio waves.

Wide Area Networks

WANs are data communication networks that span a large geographical area. They are created by connecting multiple LANs through the use of such services as dedicated leased phone lines, dial-up phone lines (both synchronous and asynchronous), satellite links, and data-packet carrier services. A WAN typically includes a number of routers.

WANs allow communication between devices on a regional, national, or international basis. Creating a WAN can be complex because it generally involves connecting networks that use different protocols. LANs can also be linked to WANs to form an enterprise network.

Metropolitan Area Networks

MANs are data communication networks that span a geographical area larger than a LAN but not as large as a WAN. MANs are created by connecting multiple LANs in a restricted way. MANs usually serve a specific metropolitan purpose, such as financial (interconnecting banks and financial institutions), health (interconnecting hospital, clinics and medical centers), governmental (interconnecting government agencies in a metropolitan area), etc.

MANs allow communication between devices on a small regional base (a district). They are usually interconnected via a FDDI backbone, gigabit Ethernet or ATM.

The Internet

The Internet is a global phenomenon consisting of a worldwide set of interconnected computers. It provides a communication vehicle for the exchange of data, news and opinions, and for research using the World Wide Web. The Internet has experienced phenomenal growth and is frequently referred to as the information highway.

Information available from "The View from Internet Valley" at http://www.internetvalley.com/intval.html indicates that In January 1998 there were on the Internet 29,670,000 hosts, an undisclosed number of users, 2,500,000 domains, and 2,450,000 Web sites. A year earlier there were a total of 194 countries out of a possible 240 connected to the Internet.

Most online services are centrally controlled, though, the Internet is decentralized by design. Each Internet host is independent. The decision about which services to provide locally and which services to provide to the global community rests with the operators of the hosts. While this may seem like anarchy, it works quite well. Commercial Internet Service Providers (ISPs) and online services, such as CompuServe and America Online, offer access to some Internet services.

The Internet is a combination of LANs and WANs that speak the same protocols and are connected through high-speed telephone circuits. It consists of several types of networks as shown in Table 1.1.

Types of Networks Found in the Internet

Type Description

Backbone networks Backbone networks interconnect other networks. The current backbones consists of large commercial backbones, NSFnet in the US, and EBONE in Europe.

Regional networks Regional networks connect such things as universities, colleges, and library systems.

Commercial networks Several types of commercial networks exist including networks that provide subscribers access to the backbones, and corporate networks that also have connections to the Internet.

Local networks Examples of local network include campus-wide university networks and a geographically limited corporate network.

The Internet uses the protocols of the TCP/IP protocol suite.

TCP/IP is a full suite of protocols that gets its name from the Transmission Control Protocol (TCP) and the Internet Protocol (IP). Most of the TCP/IP protocols are based on the TCP, which is in turn based on the IP.

The TCP/IP protocol suite allows machines connected by a variety of network technologies, such as Ethernet, telephone-wires, radio, satellites, and Asynchronous Transfer Mode (ATM) networks to communicate with each other.

The TCP/IP protocol suite is the best-known protocol in use for the Internet. Mark A. Miller in Troubleshooting TCP/IP (2nd ed.) says "the TCP/IP suite has been the glue that holds the Internet together".

A second feature of today's Internet is the advent of graphical browsers that allow users to find information through a set of links in an easy-to-use form. On the World Wide Web, this ease of use has stimulated an exponential growth in the number of Internet users.

Internet Operation

The Internet is self-governing and spans corporate and national boundaries. It is run by committees that usually consist of volunteers. In the past various organizations within the U.S. government, individual states, and universities provided funding and research for the Internet. Later, official organizations such as the International Organization for Standardization (ISO) became involved in the area of interconnecting networks. Today, universities worldwide provide most of the Internet protocol research and the Internet is now available to individual users.

The Early Years

The networks of the late 1960s and 1970s were the result of much research and implemented such diverse technology as collision detection, packet switching, and protocol layering. The last allowed applications to communicate with each other.

Computer manufacturers and researchers proposed and implemented a complete range of architectural models, all of which attempted to define a set of protocols layered on top of one another that could talk to other applications even if those applications were running on different operating systems and using different network technologies.

In the late 1960s the U.S. Department of Defense (DoD) funded the original Internet and named it the Advanced Research Projects Agency Network (ARPANET). One purpose of the ARPANET was to test packet-switching technology. The original ARPANET protocol suite introduced the ideas of layering. The TCP/IP protocol suite grew from these early beginnings. Table 1.2 lists the major events in the development and growth of the Internet.

Major Events in the Development of the Internet

Year Event

1957 Advanced Research Projects Agency (ARPA) was formed within the DoD in response to the USSR is launching of Sputnik with the intent to provide the U.S. with a lead in military science and technology.

1962 Rand Corporation proposed a packet-switched network to the U.S. Air Force as a means to control its missiles and bombers after a nuclear attack.

1968 ARPA awarded a contract to BBN to develop the ARPANET.

1969 ARPA introduced the ARPANET to test packet switching for the government. The network consisted of four nodes: the University of California at Santa Barbara, the University of California at Los Angeles, SRI (in Stanford), and the University of Utah. The ARPANET community consisted of about 100 individual professionals and links.

1972 The first e-mail program came from BBN; ARPA was renamed the Defense Advanced Research Projects Agency (DARPA).

1973 TPC/IP was introduced. The ARPANET connected about 250 sites and 750 computers. TCP/IP allowed diverse computer networks to interconnect and communicate with each other.

1974 The term Internet appeared in a paper on Transmission Control Protocol.

1978 Basic TCP/IP protocol suite assumed its current form.

1979 USENET, a decentralized news group network, was introduced.

1980 DARPA started converting the machines of its ARPANET to use the TCP/IP protocols.

1981 The National Science Foundation (NSF), at the request of universities and industrial research groups, approved funding for the Computer Science Network (CSNET), a cooperative network of computer science researchers.

1983 The Computer Systems Research Group of the University of California at Berkeley released the Berkeley System Distribution (4.2BSD) with their UNIX operating system, including the TCP/IP protocols for the first time.

DARPA completed the transition to TCP/IP and demanded that computers connecting to the ARPANET use TCP/IP.

1984 DARPA divided the ARPANET into the MILNET to carry unclassified military traffic and the ARPANET to carry non-military traffic and research.

The NSF created the Office of Advanced Scientific Computing (OASC) to aid the development and access to supercomputers.

1986 The new Internet Engineering Task Force (IETF) served as a forum for technical coordination between contractors working for the government and the Internet core gateway system.

An association of European networking organizations—Réseaux Associés pour la Recherché Européenne (RARE) supported the development and principles of open system computing

1987 OASC created NSFnet, a three-level network to connect supercomputing centers in the U.S.

1989-90 The Centre Européenne pour la Recherché Nucléaire (CERN) in Switzerland introduced a hypertext system and developed the first World Wide Web servers and clients, thus changing Internet use forever.

Réseaux IP Européenne (RIPE) supported by RARE, coordinated TCP/IP networking for the research community in Europe.

1990 U.S. DoD declared ARPANET obsolete.

1991 The business community formed the Commercial Internet Exchange Association (CIX) to provide public data network service providers a common router and a forum for the development and exchange of technology.

NFS started the National Research and Education Network (NREN) for high-speed network research.

1992 CERN released the World Wide Web.

Government agencies and nonprofit research and educational institutions formed the nonprofit international Internet Society committee (ISOC) to support the technological evolution of the Internet and Internet education.

1994 Commercial transactions started on the Web: Pizza Hut offered pizza ordering and the first cyberbank opened (First Virtual).

1995 A new architecture consisting of the following replaced the NSFnet backbone:

• A high speed backbone network service

• Network Service Providers (NSPs)

• Network Service Access Points (NSAPs)

• A Routing Arbiter (RA).

1996 on The TCP/IP protocol suite evolved to accommodate new technologies and the exploding number of users of the Internet. In January 1998 it was estimated that the Internet was increasing in size by 30% monthly.

RIPE maintains a public DNS database of European IP networks containing DNS domains and their contact people. To access the database use a WHOIS server on host whois.ripe.net or anonymous FTP at ftp.ripe.net.

Contact the RIPE NCC (Network Coordination Center) at

RIPE NCC

Kruislaan 409

NL-1098 SJ Amsterdam

The Netherlands

Phone: +31 20 592 5065

Fax: +31 20 592 5155

E-mail: ncc@ripe.net

Table 1.3 lists the major players found on the Internet.

Major Networks On the Internet

Major Network Description

ARPANET Advanced Research Projects Agency Network, the first packet-switch network

EBONE The Pan-European Multi-Protocol Backbone

CREN The Corporation for Research and Educational Networking, the combination of the Computer and Science Network (CSNET) and the Because It's Time Network (BITNET)

Cypress A leased-line packet switching network for connecting small sites to the Internet

DRI Defense Research Internet used to carry cross-country Internet datagram traffic associated with DARPA-funded projects

EARN European Academic Research Network for non-profit non-commercial traffic; it serves academic and research institutions

RARE Réseaux Associés pour la Recherché Européenne, an association of European networking organizations and users founded 1986 to support the concepts of open system computing

The Japanese Internet Made up of a number of networks including but not limited to N-1net, the Japanese BITNET, the Todai International Science Network (TISN) and Widely Integrated Distributed Environment (WIDE).

Virtual Private Networks or Extranets

Extranets are a new world based on the Internet and the intranet. A derivation of an intranet that is accessible by selected individuals and organizations, extranets lie somewhere between the Internet which is open to many users and an intranet which is open to individuals within an organization.

It is the extranet, not the Intranet, which reaches out to suppliers and customers who are an integral part of an organization's business cycle. Extranets make the lines between an internal LAN and the Internet a bit blurry. An extranet can be viewed either as part of a company's intranet that is made accessible to other companies or as a collaborative Internet connection with other companies.

Extranets are becoming an extremely important portion of any organization's information technology plan. Collaborative computing is playing a major role in the use of intranet and extranet application development and contributing to rapid dissemination. Extranets are substantially enhancing the implementation of efficient collaborative and internetworkable technology.

Examples of extranet applications include:

• Training programs that companies develop and share

• Project management for companies or diverse groups that are part of a common work project.

Sometimes referred to as a Virtual Private Network (VPN), an extranet is usually constructed by using the public Internet along with access security controls assigned only to authorized users, both within and external to a company. Thus, with an extranet in place, a single corporate Web site, a database, or an application can reside on all three networks: the Internet, the intranet, and the extranet, with each access source requiring different levels of security. The network in use depends on who is accessing the network, from where it is being accessed, and what security privileges are being used.

Intranets

The invention of the graphical browser meant that users could find and access information following a point-and-click route rather than using the command line. This ease of use led to the explosion of the World Wide Web and stimulated the idea within corporations of using this technology coupled with files and services available on their own area networks. The marriage of Web technology with corporate networks is called an intranet.

More specifically, an intranet is a Web site or group of Web sites belonging to an organization and located on that organization's network. The intranet is accessible only by the organization's members, employees, or others with authorization. A firewall surrounds it to prevent unauthorized access to the information and resources on the particular intranet. Other than the existence of firewall, the Web sites on an intranet look and act just like any other Web site.

A Basic Network

It is possible to look at a network from several different viewpoints. One approach is to consider the network as the topology of how the computers and assorted networks connect to each other. A second way to look at a network, referred to as the "protocol stack view" is to consider the layering of the protocols and how the layers operate on top of each other.

A network architecture is made up of a combination of layers, each of which performs specific functions and services. Layering sorts the communication functions of the network into logical groups that perform in a peer-to-peer relationship or in a client/server relationship.

Protocol layering is a common technique to simplify networking designs by dividing them into functional layers, and assigning protocols to perform each layer's task. Each layer consists of a set of protocols that regulate how the network computers communicate.

A protocol can exist as in a document that is possible for humans to understand. A protocol can also exist as programming code for computers to understand. Network protocols are standards or sets of rules that define how computers work together, for example, how computers:

• Identify one another on a network

• Send and receive data and regulate the transfer of data between layers and across links to other devices

• Govern activities within a specific layer of the network architecture model

• Process information once it reaches its final destination

• Handle lost or damaged transmissions or packets.

The protocols used within a network also determine whether the network uses a peer-to-peer architecture or client/server architecture.

A Network and its Topology

In a network view the geographically distributed nature of the network parts is more important than the functional structure of protocols within one network. A network view considers the network as the interconnection of networks that provide universal communications services. Each network has its own topology, the physical and geographical arrangement of network components.

Each physical network has its own technology-dependent communication interface. Software running between the physical networks provides the communication services. Routers typically interconnect different physical networks. Multiple networks can appear to the user as one large network. The Internet is a good example of multiple networks appearing as one network. The real architecture of the physical networks is hidden from the user. Networks can form a number of general configurations or topologies including:

• Linear arrangements of network devices connected to a long cable referred to as bus topologies

• Circular arrangements of network devices referred to as ring topologies

• Radiating arrangement of network devices referred to as star topologies.

Each topology defines how nodes connect to one another. Figure 1.1 shows an example of bus and ring network topologies.

Bus and Ring Network Topologies

A bus topology can have many nodes on a segment. However if a break occurs in the cable all the attached devices become inoperable until the problem is corrected. If a break occurs in a ring topology the communication path wraps and isolates the break. If two breaks occur, the ring segments and each piece operates independently.

In a star topology (shown in Figure 1.2) point-to-point segments radiate out from a hub. This type of network is quite reliable. If a break occurs in a star topology only the affected segment becomes inoperable; all others continue to operate as if the broken segment did not exist at all.

Star Topology

There can also be mixed arrangements of bus and star topologies and arrangements where the internal structure of the network is unimportant. In the latter case, a cloud typically indicates that there is a network as shown in Figure 1.3. A cloud can also represent the Internet. A cloud usually represents the physical layer when the protocol view and the network view are combined.

Mixed Network Topologies

A Network and its Protocol Stack

In a protocol-stack view of a network, layers operate independently of each other. Changes in one layer do not affect operations or protocols in neighboring layers. Higher layers can uses the services of the next lower layer to perform specific tasks without needing to know how to use the services provided by even lower layers. The process also works in reverse.

A Hypothetical Model

Figure 1.4 shows a hypothetical protocol stack with three layers. In this example the higher layer three uses the services of layer two to perform some of its tasks. Layer three also passes information to layer two. After converting the information passed to it by layer three, layer two passes that information down to layer one. In our example, layer one of network A converts the information into signals appropriate for the physical media and sends it over the network to its destination at network B. At the destination, the process occurs in reverse and the information passes up the protocol stack to the appropriate layer.

Stacked Model of Protocol Services

Network A and network B speak the same language at both ends of the layer-one interface. Typically the protocols associated with the first layer in a protocol stack provide for the physical transmission of the encoded information over the communication media.

Simon Oosthoek uses the analogy of two people communicating using speech to explain this communication process between geographically separated machines and builds a nice model incorporating Internet Service Provider (ISP) systems. In Figure 1.5 each person represents a node and therefore a number of protocols stacked upon one another.

Communication Example Between Two Talking Nodes

In this example Person 1 and Person 2 use the telephone system to communicate using speech which the brain interprets as English. The language could be called a protocol. The layers communicate on a peer-to-peer basis as shown by the dashed lines even though the layers use the lower layer's services to transport the language across the network.

Protocol Layer Reference Models

The Department of Defense developed a four-layer model in the 1970s for the ARPA project. The DoD adopted the TCP/IP suite of protocols as its choice network communication protocols. The TCP/IP protocol suite is considered to consist of the core Internet protocols and adheres to this layered model. TCP/IP is the most widely implemented protocol suite in use today and assumed its basic form by 1978. This layered representation leads to the term protocol stack. Almost every computer vendor today, and perhaps all computer vendors, provide support for at least part of the Internet protocol suite (protocol stack).

After the initial development of TCP/IP in the 1980s, the ISO developed a layered reference model of network protocols to allow communication between computer systems of different vendors. Named the Open System Interconnection (OSI), this model architecture has seven layers. Each layer has one or more protocols specific to that layer that provide services to the layers above and below.

The four-layered TCP/IP model and the seven-layered OSI reference model are the two most important reference models for describing computer network protocol layers. In both models, one or more entities implement the functions of each layer. The entities within a layer interact directly with the layer immediately below it and provide services for use by the layer above it.

The ISO is a special agency of the United Nations whose membership consists of representatives from international standards organizations throughout the world. One of the responsibilities of the ISO was to develop standards for computer communication.

There are very real differences between the two reference models. Table 1.4 shows some of the models' different approaches.

Some Differences Between the TCP/IP and ISO/OSI Models

Approach to TCP/IP ISO/OSI

Layers Represents a broad function Represent a narrow modular functional group; new functions require new layers

Protocols Other protocols can use a given protocol within a layer* Each protocol has its own layer

Standards Coded and tested before being described in an RFC Standards written before coding and testing

Focuses on implementation and then agreement of protocol standards that can work in heterogeneous environments Focus on the standard itself rather than implementation of the standard

Operating systems Permits the use by each implementation of operating system-dependent features resulting in fewer CPU cycles and enhanced performance Does not allow the use of operating system-dependent features

*In the application layer the File Transfer Protocol (FTP) uses the same representation as TELNET and in the Internet layer ICMP uses IP for sending its datagrams.

Figure 1.6 shows the relative functional position of the OSI and TCP layers. The modern Internet represents a fusion of both models. Protocol layering produces simple protocols, each with a few well-defined tasks. These protocols can then be assembled into a useful whole. Individual protocols can also be removed or replaced as needed for particular applications.

Comparison of the OSI and TCP/IP Models

The original intent was to adopt the OSI protocols as a full co-standard with the DoD protocols; number of RFCs have concerned about the possible transitions and coexistence of these protocols. It is possible to achieve TCP/IP-OSI coexistence by implementing a protocol-based approach or a services-based approach.

Protocol conversion-based approaches include implementing:

• Both protocol stacks on every machine on the network

• Application-layer gateways to convert protocol data units (PDUs) between protocol stacks

• Transport-layer gateways to dynamically translate TCP packets into TP4 packets in environments with the TCP transport protocol on one side and the OSI TP4 protocol on the other.

Services-based approaches include implementing:

• Transport-service bridges between TCP and TP4 environments that copy PDUs rather than translating them

• Network tunnels that operate at the OSI network layer and emulate packet-level services.

RFC 1739, "A Primer On Internet and TCP/IP Tools" can be used as an introductory guide to some of the TCP/IP and Internet tools and utilities. These tools and utilities allow users access to the wide variety of information on the network. This RFC also provides detailed examples of TCP/IP utilities and applications.

Function of the TCP/IP Layers

In both the IOS/OSI and TCP/IP models, each layer provides a function or group of functions. While the functions of the layers in each model may be similar, the protocols are usually incompatible. Because IP multicasting is a function of the TCP/IP protocol suite, the following sections describe the various functions of the TCP/IP layered model. Additionally today's computing environment includes a wide range of LAN and WAN technologies, such as ethernet, token ring, FDDI, ISDN, and ATM. The TCP/IP protocol suite has proved to be the best approach to internetworking this disparate mix of technologies. The modern Internet represents a fusion of both models.

-Network Interface and Network Hardware Layer

This layer corresponds roughly to the physical layer and data-link layer of the OSI model although the literature sometimes erroneously divides this layer into two separate layers. This layer is the interface to the actual network hardware.

TCP/IP does not specify a particular protocol here and can therefore use almost any available network interface; instead it assumes the presence of a device driver for maximum flexibility. This device driver controls the physical interconnection between the hosts and nodes in the network and the procedural characteristics for activating and deactivating the physical connection.

The network-interface layer, sometimes referred to as the network-access layer, is responsible for delivering data over the particular hardware media in use. Different protocols are selected from this layer, depending on the type of physical network.

The network-interface layer accepts IP datagrams and creates network-specific frames for transmission to other parts of the network. This interface may or may not provide reliable delivery and may be packet- or stream-oriented, depending on the protocols implemented at this level. This layer provides an address space on the LAN and some addressing modes such as point-to-point (unicast), point-to-multipoint (multicast) and broadcast.

Figure 1.7 shows the relationship between the TCP/IP layers and some of the TCP/IP protocols associated with the layers of the model.

The ARP and its counterpart the Reverse Address Resolution Protocol (RARP) operate at this level. The "ARP Protocol" section later in this chapter briefly describes the role of these protocols.

In the first volume of his three-volume set on internetworking with TCP/IP, D. E. Comer indicates that ARP is part of the physical network system and belongs with the network-interface layer rather than with the Internet layer.

TCP/IP Layers and Protocols

Internet Layer

The layer is intermittently called the Internet layer, the IP layer, and sometimes the Internetwork layer. No matter what its name, this layer is crucial in the TCP/IP suite. IP is the Internet's most fundamental protocol. The Internet layer shields higher levels from the typical network architecture below it and provides the means to establish, maintain, and terminate connections between end systems.

The Internet layer delivers data across the various physical networks that interconnect a source and destination machine. Routing protocols are closely associated with this layer.

The message unit in the Internet layer is called an IP datagram. The encapsulation of packets and datagrams occurs here as does the addition of datagram headers and routing algorithms. IP routers provide the translation between different connected LANs.

The major protocols are associated with the Internet layer are

• The Internet Protocol (IP)

• The Internet Control Message Protocol (ICMP)

• Internet Group Management Protocol (IGMP).

The IP protocol is the most important protocol in the Internet layer because IP is a connectionless protocol and neither assumes reliability from the lower layers nor provides flow control or error recovery.

IP provides a single 32-bit address space. An address in this space is called an IP address or Internet address as opposed to a physical address off the network interface. IP addresses are globally unique and allow IP networks anywhere in the world to communicate with each other.

The "IP addressing Summary" section later in this chapter briefly describes IP addressing. The "Internet Control Message Protocol (ICMP)" and "Internet Group Management Protocol (IGMP)" sections briefly describe the roles of these protocols.

Transport Layer

The transport layer provides end-to-end data transfer using two additional services on top of the Internet Layer. This layer handles connection rendezvous, flow control, retransmission of lost data, and other generic data-flow management. The mutually exclusive Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) protocols are this layer's most important members. Each technology has its own conventions for transmitting messages between two machines within the same network.

The IP protocol deals only with packets. TCP enables two hosts to establish a connection and exchange streams of data. UDP transmits data from source to destination, but without error checking and delivery verification.

TCP and UDP Port Numbers

This layer provides port numbers through TCP and UDP. TCP provides protocol ports, which act as additional address space, to distinguish multiple programs executing on a single device. TCP is able to accomplish this by including the destination and source port number with each message. This allows the many processes available within a host simultaneously to use the TCP communication facilities. A port number is a 16-bit number that ranges from zero to about 65,000.

UDP provides for multiplexing by port number. The UDP 16-bit port numbers allow multiple processes use UDP services on the same host.

The TCP Protocol

The TCP, documented in RFC 793 is a connection-oriented protocol, requiring the establishment of a channel between the sender and receiver before transmitting any data.

TCP offers reliable first-in-first-out (FIFO) data-stream transmission services and reliable and in-order delivery of datagrams to the application layer. TCP also provides data-flow definitions, data acknowledgments, data retransmission, and multiplexing of multiple connections through a single network connection. For example, TCP breaks the transmission into small pieces. It retransmits any pieces that get lost and reorders any data that get delivered out of order. It also handles the flow control between computers of different speeds.

TCP manages data buffers and coordinates traffic so its buffers will never overflow. Fast senders will be stopped periodically to keep up with slower receivers. Additionally, TCP dynamically learns the delay characteristics of a network and adjusts its operation to maximize throughput without overloading the network.

RFC 1323 and bibliographic references at the end of this book can provide details of TCP/IP networking.

The UDP Protocol

The UDP documented in RFC 768 provides users access to IP-like services and non-guaranteed datagram delivery. Datagram delivery in UDP is unreliable and connectionless. UDP packets can be discarded before reaching their destination. This protocol assumes that IP is used as the underlying protocol. Transaction-oriented networks use this protocol.

UDP provides only two services over IP: multiplexing by port number and the optional checksum of data. This means application programs running over UDP handle end-to-end communication problems such as retransmission and packet assembly and reassembly. A UDP address is the combination of a 32-bit IP address and the 16-bit port number. UDP discards a packet failing checksum and takes no further action. The checksum is configured on or off on a per-host basis.

The simplicity of UDP makes it necessary for applications using UDP services to perform their own checks and recovery solutions in case of errors such as lost packets or out-of-order delivery of packets.

Applications that use sessions are usually TCP-based. Such applications usually require the user to log in or connect before moving any data. TCP-based protocols include: the Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), and Virtual Terminal Protocol (Telnet).

Stateless applications such as NFS and transaction-oriented utilities such as the Simple Network Management Protocol (SNMP) and Trivial File Transfer Protocol (TFTP) are usually UDP-based.

Application Layer

This layer contains protocols that implement user-level functions, such as mail delivery, file transfer and remote login. In this layer the user process cooperates with another process on the same or on a different host. Each application-layer protocol has a specific purpose and adds structure to the data coming from the transport layer. The application-layer protocols are the user-visible protocols in the TCP/IP suite.

All application-layer protocols have a number of common characteristics:

• They use TCP or UDP as their transport mechanism. The reliable connection-oriented TCP protocol is most frequently used as the transport mechanism for application-layer protocols. Using UDP as the transport mechanism can reduce protocol overhead and thus provide better performance

• Application-layer protocols can be standard applications bundled with the TCP/IP stack, or they can be user-written applications developed for specialized purposes

• Most application-layer protocols follow the client/server model of interaction. The server and client parts of an application can run on the same or on different systems

• Established application protocols have well-known port numbers, so a client application can address its server counterpart directly.

A comprehensive "TCP/IP Tutorial and Technical Overview" can be found at the IBM Web site: http://www.rs6000.ibm.com/resource/aix_resource/Pubs/redbooks/htmlbooks/gg243376.04/3376fm.html

IP Addressing Summary

Within its 32-bit address field, IPv4 organizes the networked world into a two-level hierarchy: network numbers, and host numbers within network numbers. Currently the Internet Assigned Numbers Authority (IANA) largely delegates to Internet service providers the job of assigning unique network numbers to organizations that request them. The organization's network administrator then assigns unique host numbers to its attached devices.

General IPv4 Addressing Architecture

A 32-bit IP address is usually represented in dot decimal notation and consists of 4 octets (bytes) separated by a dot; for example 172.16.10.0. In an IPv4 implementation, each physical network and host has its own unique network address. Routers or gateways can have one or more addresses depending on the number of interfaces present.

The IPv4 address space is divided into classes consisting of three kinds of unicast addresses classes and two specialized address classes: class D and class E as shown in Table 1.5. A unicast address identifies a specific network interface addresses. Class A addresses are intended for use by the world's largest organizations while class C addresses are intended for very small network communities. An existing pool of class C addresses supports the current growth in the Internet.

IPv4 Address Classes

Address type Consists of With an address range of

Class A 126 networks, each can have up to (16M-2) nodes 1.0.0.0 - 126.0.0.0

Class B (16K-2 ) networks, each can have up to (64K-2) nodes. 127.0.0.0 - 191.255.0.0

Class C (2M-2) networks, each can have up to 254 nodes. 192.0.0.0 - 223.255.255.0

Class D A multicast address. 224.0.0.0 - 240.0.0.0)

Class E Reserved for future use by the IANA 241.0.0.0 - 248.0.0.0

A class D address is a multicast address. Rather than being assigned to a specific interface, it identifies the members of a logical group of interfaces. For example, a class D address could identify all the interfaces attached to IP network routers. All logical holders of particular class D addresses receive packets sent to that address.

Each class of IPv4 addresses consists of two parts: a network identifier portion and a host or node identifier portion as shown in Figure 1.8.

In this example the binary address 10000000 00000111 00001111 00000001 has the decimal dot notation 128.7.15.1. This is a class B address with the network ID of 128.7. Special forms of Internet addresses include the following:

• 0.0.0.0 indicates this host

• 0.host-number indicates this host on this net

• 255.255.255.255 indicates limited broadcast to the local net

• Net-number.255 indicates directed broadcast for the specified net.

• 127.anything indicates the host's internal loopback. This should never appear on the network.

Five forms of IPv4 Addresses

A comprehensive document titled "Understanding IP Addressing: Everything You Ever Wanted To Know" by Chuck Semeria, October 9, 1997 can be found at the 3Com Web site: http://www.3com.com/nsc/501302.html

IP Subnetting

Subnetting is a technique of assigning addresses that allows a single IP network address to span multiple physical networks.

Subnetting uses some of the bits of the host-ID portion of the IP address as a physical network identifier. The subnet mask determines the bits of the network identifier. With subnetting, the network ID and host ID division change to network ID, subnetwork ID, and host ID. The subnet mask is a 32-bit number with all ones in the network ID and subnetwork ID fields and all zeros in the host ID field. The subnet field takes the space it needs by reducing the host ID field. Individual organizations assign the subnet ID and the host identifiers for the host on each subnet.

For example, to subnet the Class B network 128.10.0.0 use the first 8 bits of the host ID, to span 254 different physical networks. In this case the subnet mask is 255.255.255.0 and the subnetworks are, 128.10.1.0, 128.10.2.0, and on through 128.10.254.0. Each of the subnetworks can have up to 254 different hosts: for example, 128.10.XXX.1, 128.10.XXX.2, and on through 128.10.XXX.254.

To have more hosts in a subnet, use fewer host-ID bits when establishing the subnets. For example, using the subnet mask 255.255.254.0 yields 126 different subnets with up to 510 hosts in each one.

Figure 1.9 shows the division of a Class-B network into two subnetworks. In this example, all gateways except gateway A route as if there were a single physical network. Gateway A is physically interconnected between the networks.

A Class-B Network Divided into two Subnetworks

ARP Protocol

The purpose of RFC 826 "An Ethernet Address Resolution Protocol" is to present a method for converting an IP address to the host's ethernet address, its local network address. RFC 826 has also been adapted for other media, such as FDDI.

The sender broadcasts an ARP packet containing the Internet address of another host to all hosts attached to an ethernet and waits for the other host to send back its ethernet address. The target machine, recognizing that the IP address in the packet matches its own, returns an answer. Each host maintains a cache of address translations to reduce delay and loading. ARP allows the Internet address to be independent of the ethernet address but it only works if all hosts support it.

As defined in RFC 826, a router and host must be attached to the same network segment to accomplish ARP. Another router cannot forward ARP broadcasts to a different network segment. An Internet host must use its routing protocols to select an appropriate router.

Routers can use proxy ARP to handle traffic flowing between hosts that do not use a router. However, proxy ARP should probably only be used as a temporary transition mechanism. For example, using proxy ARP would be appropriate during the process of creating subnets within a larger network. In this case, a host still on the larger network would use the proxy ARP capabilities on a router to broadcast to hosts behind the router and on subnets.

Refer to the ARP RFC and D. E. Comer's Internetworking with TCP/IP for more details about ARP.

Reverse Address Resolution Protocol (RARP)

RFC 903, "A Reverse Address Resolution Protocol" provides the reverse function of ARP. RARP maps a hardware address, also called a media access control (MAC) address, to an IP address. Diskless nodes primarily use RARP when they initialize, to find their Internet address. RARP's function is similar to that of the Bootstrap Protocol (BOOTP).

Internet Control Message Protocol (ICMP)

RFC 792, "Internet Control Message Protocol" is considered part of IP. ICMP handles error and system-level messages. Occasionally a gateway or destination host needs to communicate with a source host to report an error in datagram processing and uses ICMP to do so.

An ICMP message could be sent when a datagram does not reach its destination or when a gateway fails to forward a datagram usually due to insufficient buffering capacity.

Figure 1.10 shows the message format of an ICMP message.

ICMP Message Format

In this example:

• Ver specifies the 4-bit IP version which is always 1

• Type specifies the type of message as shown in Table 1.6.

• Checksum is a 16-bit checksum calculated as for IP.

• Data contains the information for this ICMP message and typically includes part of the original IP message that caused the generation of this ICMP message.

IP datagrams contain ICMP messages. The IP header will always have a protocol number of 1, indicating an ICMP message, and a type of service of zero. The IP data field contains the actual ICMP message.

ICMP Message Types

Value Message Type

0 Echo reply

3 Destination unreachable

4 Source quench

5 Redirect

8 Echo

9 Router advertisement

10 Router solicitation

11 Time exceeded

12 Parameter problem

13 Timestamp request

14 Timestamp reply

15 Information request (obsolete)

16 Information reply (obsolete)

17 Address mask request

18 Address mask reply

Internet Group Management Protocol (IGMP)

RFC 1112, "Host Extensions for IP Multicasting" defines IGMP, which is an extension to ICMP occupying the same place in the TCP/IP protocol stack. Systems participating in IGMP fall into two types: hosts and multicast routers.

IGMP allows IP hosts to report their host group memberships to any immediately-neighboring multicast routers. Multicast routers send host membership query messages to determine which host groups have members on their attached network. Hosts respond with host membership reports listing all the groups to which the host belongs.

Multicast routers listen for these messages and can then exchange group membership information with other multicast routers, allowing distribution trees to be formed to deliver multicast datagrams.

Extensions, known as IGMP version 2, developed and appeared in later releases of the IP multicast distribution and included explicit leave messages for faster pruning and multicast traceroute messages.

Figure 1.11 shows the message format of an IGMP message.

IGMP Message Format

In this example:

• Ver specifies the 4-bit IP version which is always 1

• Type specifies a query or a report. 1 indicates a query sent by a multicast router; 2 indicates a report sent by a host

• Checksum is a 16-bit checksum calculated as for ICMP

• The Class D address is zero (0) for a request and a valid multicast group address for a report.

IP datagrams contain ICMP messages. The IP header will always have a protocol number of 2, indicating an IGMP message, and a type of service of zero. The IP data field contains the 8-byte IGMP message.

Network Components

A network can consist of a number of different physical components ranging from cables and connectors to supercomputers. The most important components of a network are nodes, hosts, routers, and LANs. Hosts and routers connect to LANs and LANs connect with routers.

• A node is generally a generic term used to describe a device that connects to the network at a processing location; a printer and a computer can be nodes. Protocol functions such as TCP/IP are usually associated with a node.

• A router is a node that performs a forwarding function: when two different LANs interconnect, the routing entities translate between them using the Internet Protocol

• A host is a node at the endpoint of a communication. A host can be a computer connected to a TCP/IP network that has its own unique IP address. A host can also be a computer system that a user accesses from a remote location. Hosts do not perform routing functions.

An Internet can be seen as a set of LANs connected to each other using IP routers. The networks comprising the LANs can be based on one or more network topologies and one or more network technologies (such as ethernet and FDDI). When a computer on one network communicates with a computer on a different network, IP routers move packets from a source host to a destination host across the intermediate networks.

There are usually several possible routes between hosts and options and mechanisms in the routing protocols help select the best route. The routers in use may or may not have the ability to use these options. If a router fails, an intermediate router can chose a different route to reach the same destination.

Figure 1.12 shows an architectural view of the protocol functions in an IP host and an IP router.

Architectural View of the Protocol Functions in an IP Host and IP Router

Backward Forward
Chapter: Preface | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.
Beta Books | Beta Bookstores | Computing McGraw-Hill

Professional Publishing Home | Contact Us | Customer Service | For Authors | International Offices | New Book Alert | Search Catalog/Order | Site Map | What's New

A Division of the McGraw-Hill Companies
Copyright © 1998 The McGraw-Hill Companies, Inc. All rights reserved. Any use is subject to the Terms of Use the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers.


Marcus Goncalves
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Chapter Two

Introducing the Network Infrastructure

TCP/IP networks can run over a variety of infrastructures including building and campus backbone LAN and, WAN backbone infrastructures, and Integrated Services Digital Network (ISDN) switched WAN connections.

LAN communication is characterized by high throughput, low delay, and low error rates and uses internetworking devices such as routers to link LAN segments. Building or campus LAN infrastructures can include shared and switched LANs.

WAN communication, characterized by relatively low throughput, high delay, and high error rates, occurs between geographically separated areas. WAN infrastructures include satellite, frame relay, Switched Multimegabit Data Service (SMDS), ATM, and the Internet.

This chapter briefly:

• Presents general information about LANs and WANs

• Introduces transport and switching technologies and techniques

• Examines the technologies generally associated with a backbone LAN infrastructure including Ethernet, token ring, and FDDI networking

• Examines the technologies generally associated with a backbone WAN infrastructure including satellite, SMDS, Frame Relay, and ATM networking

• Describes the role of Integrated Services Digital Networks (ISDNs)

An Overview of Backbone LANs and WANs

The topology of a network can be described as a logical or physical. In logical topologies the network is seen in terms of component access methods or rules of operation. Physical topologies define the arrangement of devices and the layout of the wiring.

Figure 2.1 shows a typical enterprise network using LAN and WAN technologies. Some form of physical media such as twisted pair cable or optical fiber makes the connection between devices, LANs, and WANs.

An Enterprise Network Using LAN and WAN Technologies

The development of various standards for networking protocols and media has made possible the worldwide proliferation of LANs for business and educational applications.

The Electronic Industries Association and Telecommunications Industries Association (EIA/TIA) define standards for building wiring over which LANs (and WANs) run. The EIA/TIA standard for commercial building wiring divides the wiring topology of an enterprise into subsystems. These topologies consist of the campus backbone subsystem and the building backbone. The standards further divide the building backbone subsystem into one or more horizontal (floor) subsystems.

• A campus backbone subsystem links clusters of building together. The buildings could be geographically close or separated. Connecting a campus backbone can usually be done without using the telephone company or another network provider.

• The building backbone subsystem provides the link between the campus backbone and the horizontal or workgroup area subsystem. A star topology is the most usual configuration for workgroups and a building backbone subsystem.

• A WAN backbone subsystem interconnects various LAN segments and requires the use of outside resources such as the phone company or satellite communication facilities. A typical transport medium might use Frame Relay running at 1.5 Mbps, with high-speed WAN connections such as SMDS or ATM.

A LAN usually exhibits high speed or bandwidth and low latency while a WAN exhibits the reverse. Network devices like routers and switches add processing delay. Bandwidth describes the amount of data that can be transmitted over a channel in bits per second. Latency is the minimum amount of time it takes those bits to transverse the network.

The WAN design tutorial at http://www.data.com/Tutorials/WAN_Design.html indicates that a good way to determine the latency of a given network is to measure the round-trip packet transmission time using a tool like the IP ping utility.

The use of WANs is growing in response to new needs for communication and reduced communications costs. The geographic dispersal of offices closer to customers and suppliers, increasing numbers of telecommuters, and the proliferation of users have increased demand for WAN connections to remote sites.

WAN services are becoming increasingly complex. Long distance carriers and cable providers offer a variety of transport technologies to customers and compete to provide local service. Not to be left out, local service providers also offer a variety of transport technologies to customers and compete for long distance service.

These different transport technologies are referred to as network infrastructures and accommodate IP multicast support with differing amounts of ease. IP multicast relies on the existence of an underlying multicast delivery system to forward data from a sender to all the intended receivers.

The following sections review backbone LAN infrastructures, backbone WAN infrastructures, and switched WAN connections.

Transport Technologies

Ethernet, token ring, and FDDI standards describe the basic network types of today's LANs. ATM is also sometimes used in LANs but is more generally found in WANs. Ethernet transport technologies consist of Ethernet, Fast Ethernet, and the newer Gigabit Ethernet.

All of these standards define different logical topologies but all of them can be mapped with physical topological rules such as those defined by the EIA/TIA. All these network types can support many media types but, the specific transmission characteristics of each of the media differ.

How a station gains access to the media depends on the access method specified in the standards. Access methods mediate between stations competing for use of the medium. Ethernet as defined by the IEEE 802.3 standard uses the Carrier Sense Multiple Access with Collision Detection (CSMD/CD) method. Both the token ring IEEE 802.5 and FDDI standards use token passing methods.

A network protocol runs over each technology. This is typically TCP/IP in organizations that use an intranet or the Internet and in organizations that use UNIX systems. Windows-based networks use NetBEUI. Novell and Apple-based networks use Internetwork Packet Exchange and Sequenced Packet Exchange (IPX/SPX) and Apple Talk protocols respectively although Novell networks might use the newer NetWare Link Services Protocol (NLSP).

The NAPs currently provide high-speed services including services based upon ATM, frame relay and FDDI to the NSPs and ISPs.

Companies operating NAPs include:

• Sprint Corporation–New York/New Jersey

• Ameritech–Chicago

• PacBell–San Francisco/Bay area

• MFSdatanet–Washington, DC

Go to the following Web pages for more information on selected NAPs

http://rrdb.merit.edu/napsp3.html and  http://rrdb.merit.edu/pacbell.html

Switching Techniques

As we have stated, routers link LAN segments. Switches connect WAN links. Switches and routers relay information in different ways. Routers understand the network-layer protocols used between the hosts. Switches forward information from host to host without knowing anything about the path between the hosts. Routers understand the Internet layer protocols used between hosts. Switches, on the other hand, know nothing about the hosts' Internet layer protocols.

WAN services are provided through three primary switching technologies: circuit switching, packet switching, or cell switching.

• Circuit-switched networks dedicate each link to a predetermined number of users during a particular period. TDM methods control access to the network. A user receives a predetermined amount of bandwidth and another users cannot use that bandwidth. The telephone system is an example a circuit-switched network.

• Packet-switched networks allow end stations to dynamically share the network medium and the available bandwidth. They use statistical multiplexing techniques to control network access. These networks traditionally use network bandwidth more efficiently than do circuit-switched networks. Ethernet and token ring LANs are examples of packet-switched networks.

• Cell-switched networks move fixed-sized pieces of information called cells. Such a network uses both statistical time division multiplexing (STDM) and TDM-based access. This combination of cell switching and packet switching techniques produces networks with low latency and high throughput. ATM is an example of cell-switched technology.

Figure 2.2 is a pictorial representation of different types of switched networks and latency over a WAN. Table 2.1 adds explanation of each switched network type.

Latency on WANs

WAN Switched Services and Latency

Network Type Transport Latency Comments and Conditions

Packet switched Internet, Frame Relay High Can involve much packet processing and queuing in the network, has reasonable cost, moves variable-sized information units

Cell switched ATM, SMDS Low,

High-speed Used when response time is absolutely critical, is high-cost, moves fixed-sized pieces of information, has slowdowns because propagation delay and congestion are possible

Switched ISDN Low predictable latency There may not be bandwidth for a particular application; has latency similar to that on leased lines

If packets seem to be getting lost, use an analyzer on the network to see if retransmissions are occurring on the WAN. Adding bandwidth to access lines could help correct the situation if packets are being dumped. Routers and frame relay access devices (FRADs) can drop packets if their queues are too small for the load. Packet drops can be caused by physical errors or on a frame relay network belonging to a carrier. Although carriers typically add frame-relay capacity as needed, localized temporary congestion is possible.

Campus and LAN Infrastructures

A campus LAN can use a number of different technologies in addition to the more traditional Ethernet, including token ring and FDDI. Within a building or campus, LAN segments are usually linked through internetworking devices such as routers. Because most LAN technologies are inherently broadcast in nature, they can easily support IP multicast.

Ethernet Technologies

Ethernet, Fast Ethernet, and Gigabit Ethernet comprise the basic Ethernet technologies.

Ethernet

Ethernet, developed by Xerox, is the most widely installed LAN technology and is specified in the IEEE 802.3 standard (see Table 2). Ethernet is popular because it strikes a good balance between speed, cost and ease of installation. The most commonly used Ethernet systems are called 10BASE-T and transmit data at speeds of 10 million bits per second through heavy coax cable, twisted pair, or fiber optic cable. Ethernet has the ability to support virtually all popular network protocols.

Table 2

IEEE Standards

IEEE Standard Defines

802.2 The message format for data on any LAN

802.3 Hardware standards for Ethernet cards and cables

802.5 Hardware standards for token ring cards and cables

Operation

Devices connect to the cable and compete for access using the Carrier Sense Multiple Access with Collision Detection (CSMA/CD) protocol; the channel-access method used by Ethernet. With CSMA/CD, each station waits for an idle channel before transmitting and detects overlapping transmissions by other stations. Up to 1024 stations can share the logical bus.

Ethernet requires a repeater to connect segments. The repeater can convert the Ethernet signal from one type of wire to another. For example, a repeater converts or copies the signals from a telephone line connection at the desktop onto the main Ethernet coax cable. The repeater also copies data from the main cable and sends it down the phone line. Ethernet packets travel the network wire and are propagated through all wire segments until the packet is either picked up by the destination device or discarded.

Frame Formats

Ethernet transmits blocks of data called "frames." The first 12 bytes of every frame contain the 6-byte address of the recipient and a 6-byte address of the sender. Each Ethernet card has a unique address installed at the factory that guarantees a unique identity. System administrators can configure a substitute address through software.

Each frame has a source-address field that contains the sender's unique address. The destination address field can contain a single recipient address or a multicast address representing a group of workstations.

Most Ethernet adapters can be set to receive all frames that appear on the LAN. This is called promiscuous mode. Operating with this mode has the potential of posing a security risk. To avoid this problem, use one of the newer generation of smart hubs, can filter out all frames with private destination addresses belonging to another station.

To allow collision detect, the 10 megabit Ethernet requires a minimum packet size of 64 bytes. Any shorter message must be padded with zeros. The requirement to pad messages is unique to Ethernet.

A great deal of information about Ethernet is available on the Web. Good Web sites for this information include:

• http://wwwhost.ots.utexas.edu/ethernet/ A site maintained by C. Spurgeon at the University of Texas.

• http://pclt.cis.yale.edu/pclt/comm/ether.htm – A paper by H. Gilbert on Ethernet (April 12 1995) provides detailed explanations and background information.

• http://www.cs.bsu.edu/homepages/peb/cs637/ethernet/concepts.htm – This site at Ball State University (September 20 1996) provides basic information Ethernet, CSMA/CD, bandwidth, baseband, and broadband.

Fast Ethernet

Fast Ethernet, referred to as 100BASE-T10, is roughly 10 times faster than traditional Ethernet and yields an actual throughput of 60 to 70 Mbps. Fast Ethernet is specified in IEEE 802.3u standard. This standard:

• Makes only minimal changes to the existing cable structure

• Raises the Ethernet speed limit from 10 Mbps to 100 Mbps

• Defines several cabling schemes for use with 100BASE-T.

A typical application for Fast Ethernet is a LAN backbone system supporting workstations with 10BASE-T adapter cards.

Fast Ethernet can be shared or switched. Use shared Fast Ethernet to eliminate bottlenecks at centralized servers and at the desktop. Switched Fast Ethernet is useful in a number of applications including making direct server connections, interconnecting Ethernet switches and fast Ethernet hubs, and for delivering high bandwidth to the desktop.

Only a small percentage of workstations available today can utilize the full 100 Mbps of bandwidth offered by Fast Ethernet.

There are three types of Fast Ethernet for use with different cabling schemes: 100BASE-TX, 100BASE-T4, and 100BASE-FX. Some Fast Ethernet installations use two pairs of the cable for the LAN and two pairs of the cable for voice or modem applications.

100BASE-TX supports two pairs of high-quality twisted-pair wires for use with Level 5 unshielded twisted pair (UTP) cable. This standard has become the most popular because of its close compatibility with the 10BASE-T Ethernet standard.

100BASE-T4 supports four pairs of normal-quality twisted-pair wires for use with Level 3 UTP cable and Level 4 UTP cable.

100BASE-FX supports the use of fiber optic cables.

Gigabit Ethernet

Gigabit Ethernet is an emerging technology compatible with existing 10/100 Ethernet standards. The development of Gigabit Ethernet extends the scalability of Ethernet. It provides a very high level of backbone support and is specified in the IEEE 802.3z standard. The Gigabit Ethernet Alliance, an industry-wide consortium, is working to bring Gigabit Ethernet to the marketplace as quickly as possible.

Gigabit Ethernet provides a data rate of one billion bits per second. Optical cable is the medium of choice and the technology preserves the 802.3 and Ethernet frame format as well as 802.3 managed object specifications. Gigabit Ethernet employs the same fundamental CSMA/CD access method to resolve contention for the shared media.

Designed to offer higher performance and scalability, Gigabit Ethernet will be implemented in general-purpose LANs of all sizes. Best used at the enterprise backbone, Gigabit Ethernet complements existing solutions like ATM and can be an alternative for switched Fast Ethernet or FDDI backbones.

Existing Ethernet LANs with 10 and 100 Mbps cards can feed into a Gigabit Ethernet backbone. The Gigabit Ethernet backbone could conform to any of cable specifications listed in Table 2.3 and shown in Figure 2.3.

Gigabit Ethernet Cable Specifications

Gigabit Ethernet Type Cable Specification Distance

1000BASE-SX 850nm multimode optical fiber 300m to 550m

1000BASE-LX 1300nm single-mode optical fiber 3km

1000BASE-CX Short-haul copper STP 25m

1000BASE-T Long-haul copper over UTP 100m

The following Web pages contain in-depth Gigabit Ethernet information or pointers to additional information.

• http://www.gigabit-ethernet.org/ – The official page of the Gigabit Ethernet Alliance contains much information on how the system works, interoperability issues, and lists of vendors

• http://www.iol.unh.edu/training/ge.html – A page from the University of New Hampshire InterOperability Lab contains pointers to Gigabit Ethernet tutorial information

• http://www.3com.com/0files/strategy/600220.html – An informative paper, "Gigabit Ethernet on the Horizon" from 3Com, March 7 1997

• http://wwwhost.ots.utexas.edu/ethernet/descript-gigabit-ieee.html – Working documents from the group developing the IEEE 802.3z Gigabit Ethernet standard.

Gigabit Ethernet Technology

Token Ring

In a token ring network, each station connects to the ring through a signal-regenerating circuit. A logical ring connects the stations together and the data always travel in the same direction around the ring. Figure 2.4 illustrates a token ring network.

The token is a special 24-bit long pattern that gives a station the right to transmit a frame. Stations send messages in the following manner:

1) The token continuously circulates around the ring until it reaches a station that wants to transmit data.

2) That station transforms the token into a data frame, usually by changing a token bit from 0 to 1, adds addressing information, appends its data, and forwards the frame around the ring.

3) Each successive workstation examines and forwards the frame to the next station in the ring. If the destination address information matches the station's own address, it copies the frame into its buffer memory, sets a marker indicating that the message has been copied, changes the token bit back to 0, and places the frame in circulation again.

4) When the frame returns to the originator, that station removes it from the ring, removes the message from the frame, and issues a new token onto the ring.

5) The token circulates on the ring ready to be taken by a workstation when it has a message to send, and the cycle repeats itself.

Sample Token-Ring Network

Token ring networks have baseline speeds of 4 Mbps and 16 Mbps. The wiring requirements for token ring networks differ from those of Ethernet.

Workstations connect to central hubs called multistation access units (MAUs). Multiple hubs are connected to create large multistation networks. The hub itself contains a "collapsed ring". Used as a collapsed backbone, token ring switches provide a very high-speed, low-latency connection between multiple ring segments. Using token ring switches this way improves the performance of the whole network; it also means that network services can be centralized.

Token ring networks include a complex set of low-level management features are used to control and monitor enterprise-wide network systems. Every 802.5 token ring adapter has MAC frames built into it that address four basic functions:

• Maintaining the ring

• Locating and isolating cable and hardware faults

• Identifying hard and soft errors

• Providing node status information to management applications.

An IETF proposed standard for a method of transmitting IP multicast datagrams over token ring is described in RFC 1469.

Among the many sites on the Web containing information about token ring technology, the following are good places to start:

• http://www.rdlab.carnet.hr/NetLab/faq/tring.html – Token ring frequently asked questions

• http://www-europe.cisco.com/warp/public/482/index.shtml – Pointers to a series of technical tips for token ring

• http://www.madge.com/techsup/madgeu/cutthrsw.htm – Detailed technical information about the operation of cut-through switching in token ring networks; see also http://www.madge.com

• http://www.astral.org/ – Site for ASTRAL, an alliance of leading token ring technology providers that provides vendor-independent education and information about token ring and new technology developments

• http://www.iol.unh.edu/testsuites/tokenring/tests/station/s10.html – Dedicated token ring station MAC conformance test suite from the University of New Hampshire.

Fiber Distributed Data Interface

FDDI is a set of ANSI/ISO standards that defines a high-bandwidth (100 Mbps) general purpose LAN. FDDI primarily runs over optical fiber but can also run over copper. It is a dual ring technology and can range up to 200 km (124 miles). A single ring can extend the maximum distance; a dual ring can extend 100 km (62 miles).

In additions to being large geographically, an FDDI LAN can support thousands of users. FDDI can interconnect LANs using other protocols. FDDI-II, a version of FDDI, adds circuit-switched services to an FDDI network so that voice signals can also be handled. Plans are under way to connect FDDI networks to SONET, part of broadband ISDN.

The FDDI standards set consists of the IEEE 802.2 Logical Link Control standard, and the FDDI-specific Media Access Control (MAC), Physical Layer Protocol (PHY), Physical Layer Medium Dependent (PMD), and Station Management (SMT) standards.

The FDDI standards divide:

• The physical layer of the OSI model into two sublayers, the PHY and PMD

• The data-link layer of the OSI model into two sublayers, the LLC and MAC.

The SMT encompasses both the data link layer and the physical layer as shown in Figure 2.5.

FDDI Standards–Relationship to Each Other and the OSI Model

FDDI provides synchronous and asynchronous services between computers and peripheral equipment. FDDI uses a time-token passing dual ring configuration. The primary ring has up to 100 Mbps capacity. The secondary ring can be used as backup or can also carry data, extending the capacity to 200 Mbps.

The dual rings operate in opposite directions and provide a self-healing property to the network. If a failure occurs in a single segment, the dual ring arrangement allows the data to be routed through the second ring. This keeps the network operational while repairs are made.

Comparison of Ethernet, Token Ring, and FDDI

Table 2.4 compares the major characteristics of the Ethernet, token ring, and FDDI technologies. Table 2.5 compares characteristics of Ethernet, Fast Ethernet, and Gigabit Ethernet.

Comparison of Ethernet, Token Ring, and FDDI

Ethernet

(IEEE 802.3) Token Ring

(IEEE 802.5) FDDI

Logical topology Bus Single ring Dual ring, dual ring of trees

Physical topology Star, bus, hierarchical star Ring, star, hierarchical star Ring, star, hierarchical star

Media Optical fiber, twisted pair, coaxial cable Twisted pair, optical fiber. Optical fiber

Media access method CSMA/CD Token passing Timed-token passing

Bandwidth 10 Mbps 4 or 16 Mbps 100 Mbps

Maximum number of stations 1024 250 500

Maximum distance between stations 2.8 km (1.7 mi.) 300 m (984 ft) but 100 m (328 ft) is recommended 2 km (1.2 mi.)

Maximum length of network 2.8 km (1.7 mi.) Varies with configuration 100 km (62 mi.)

Comparison of Ethernet, Fast Ethernet, and Gigabit Ethernet

Ethernet

10BASE-T Fast Ethernet

100BASE-T Gigabit Ethernet Goals

Data Rate 10 Mbps 100 Mbps 1 Gbps

Category 5 UTP 100 m (min) 100 m 25ñ100 m

STP/Coax 500 m 100 25 m

Multimode Fiber 2 km 412 m (half duplex)

2 km (full duplex) 500 m

Single-Mode Fiber 25 km 20 km 2 km

Backbone WAN Infrastructure

WAN services can be considered as connectionless or connection-oriented and are typically provided through switching technologies. Backbone WAN infrastructures include satellite network, frame relay, SMDS, ATM and the Internet.

Satellite

The hundreds of satellites currently in operation are used for such diverse purposes as weather forecasting, television broadcast, amateur radio communications, Internet communications, and the Global Positioning System.

Three types of communications satellites exist and are categorized according to the type of orbit they follow.

• A geostationary satellite orbits the earth directly over the equator, approximately 22,000 miles up. A complete rotation around the earth takes 24 hours. Weather satellites are examples of this type.

• A low-earth-orbit (LEO) satellite system uses a number of small satellites. Each satellite assumes a circular orbit at over, or nearly over, the geographic poles. They fly at an altitude of a few hundred miles. Wireless access to the Internet is dependent upon this type of satellite. A LEO system makes it possible to access the Internet using an antenna system as simple as the early television rabbit ears.

• Some satellites revolve around the earth in elliptical orbits moving rapidly at perigee and moving slowly at apogee. They require directional antennas whose orientation must be constantly adjusted to follow the satellite's path across the sky. Amateur radio operators and some commercial and government services use this type of satellite.

Satellite technology for the Internet is basically a WAN technology and satellite network service providers can easily deploy private virtual networks for organizations. Satellite networks can be either bidirectional or unidirectional.

A Very Small Aperture Terminal (VSAT) network is an example of a bidirectional satellite network (see Figure 2.6). This type of network infrastructure is natural for implementing IP multicast services. A broadcast satellite used to send television signals is an example of a unidirectional satellite network.

A VSAT Network

Switched Multimegabit Data Service

Switched Multimegabit Data Service (SMDS) is sometimes called the Connectionless Broadband Data Service (CBDS). It is a public packet-switched datagram service for very high-speed WAN data communications. Defined in a series of specifications by Bellcore, SMDS was initially used for LAN interconnections over long distances, providing flexible, high-bandwidth connections between multiple sites.

SMDS is connectionless and therefore provides bandwidth on demand because there is no need to set up a connection through the network before sending data. SMDS extends the performance and efficiencies of a company's LANs over a wide area on a switched, as-needed basis. Organizations that need to exchange large amounts of data with other organizations on a random basis are likely candidates SMDS.

An SMDS network acts like a high-speed LAN backbone, allowing packets from one LAN to flow to any other LAN. Access to SMDS is usually provided over either T1/E1 or T3/E3 transmission facilities.

SMDS provides:

• Data units containing up to 9188 octets of user information and the source and destination address. Each packet is sent separately from other packets. All packets sent on the network are available for reception by all nodes. This means SMDS appears as a wide-area shared LAN

• Encapsulation of entire IEEE 802.3, IEEE 802.4, IEEE 802.5, and FDDI packets due to its large packet size

• Support for native multicast, easily accomplishing IP multicast as an overlay

• The transfer of data at rates of between 1.544 Mbps and 44.736 Mbps over T1 and T3 circuits

• From one to sixteen unique SMDS addresses, depending on need. An address is a ten-digit number that looks like an ordinary telephone number and consists of a 4-bit code followed by the standard components of a telephone number: country code, area code, and subscriber number

• Mechanisms for broadcasting packets to multiple SMDS addresses; group addressing is similar to LAN multicasting.

The SMDS Interface Protocol (SIP) defines the SMDS data terminal equipment (DTE) and data circuit-terminating equipment (DCE) interface. Similarities between SIP and ATM cell formats make SMDS an excellent stepping stone to ATM.

Figure 2.7 shows a network using SMDS.

A Network Using SMDS

In this example the demarcation point between the carrier's SMDS network and the customer's equipment is referred to as the Subscriber Network Interface (SNI).

Access to the SMDS network is normally accomplished through the SIP, which is based on the Distributed Queue Duel Bus protocol

To use SMDS in the U.S., contact the appropriate regional Bell operating company or MCI, the only U.S. carrier offering nationwide SMDS services.

Distributed Queue Dual Bus and SMDS

The DQDB protocol handles both constant-rate, voice traffic (isochronous traffic) and data traffic over very high-speed optical links using:

• Fiber connections at 35 Mbps and 155 Mbps

• Synchronous Optical Network (SONET) connections starting at 51,840 Mbps.

This protocol is the accepted standard (IEEE 802.6) for Metropolitan Area Networks (MANs) and is the basis for a number of MANs. SMDS is a MAN service.

SMDS and ATM Differences

SMDS provides a datagram service. The packets themselves may or may not be transported within the network on top of a connection-oriented ATM service. SMDS uses ISDN addresses and is connectionless packet-switched service, not a cell-relay service like ATM.

The SMDS Subscriber Network Interface uses IEEE 802.6 DQDB access across the SMDS user-network interface. DQDB itself is a form of cell relay and the lower layers of SMDS fragment the packets into cells with a 5-octet header and 48-octet payload.

SMDS can also be looked at as an ATM application. Having an SMDS server in an ATM network creates a connectionless datagram service over ATM that provides all SMDS service features while utilizing the benefits of ATM.

Frame Relay

Frame relay is a network interface protocol standard for interfacing to a packet network. This includes packet networks conforming to approved Consultative Committee on International Telephone and Telegraph (CCITT) I.233, Q.922, Q.933 and I.370 standards and the approved ANSI T1.606, T1.618, T1.617 and T1.606 standards.

Frame relay is not recommended for carrying isochronous traffic such as voice or video. Voice must be transmitted with no more than a 100 ms delay for acceptable quality.

Frame relay supports variable-sized frames. In telecommunications, a frame is data transmitted between network points as a unit complete with addressing and necessary protocol control information. Usually a header field precedes the data and a trailer field follows the data.

Frame relay service from public carriers is available worldwide. It provides virtual leased lines to the customer. Frame relay usage ranges from applications in WANs to applications in private network environments with leased lines over T-1 lines.

Frame relay was originally conceived for use over ISDN interfaces and is a Layer 2 protocol requiring a dedicated connection during the transmission period. It is a fast-packet technology: the protocol performs no error checking during transmission and the endpoints are responsible for any error checking. Fast-packet switching can use ATM.

A frame relay network is basically a network of frame relay switches, offering a bare-bones link-layer service for fast bulk packet transmission. Frame relay networks transfer the user traffic within the frame without regard to its contents. A customer can lease a Permanent Virtual Circuit (PVC) between two points or can lease multiple PVCs between a sender and multiple receiving sites, thus enabling multicast.

The frame relay protocol does not provide explicit flow control procedures; higher-layer protocols in an internetworking environment provide flow control. The current frame relay standards address PVCs that are administratively configured and managed in a frame relay network. Standards for use of Switched Virtual Circuits (SVCs) with frame relay are still incomplete.

The frame relay network provides a number of virtual circuits that form the basis for connections between stations attached to the same frame relay network. The resulting set of interconnected devices form a private frame relay group which can be either fully interconnected with virtual circuits, or only partially interconnected. In either case, a Data Link Connection Identifier (DLCI) uniquely identifies each virtual circuit at each frame relay interface. In most circumstances, DLCIs have strictly local significance at each frame relay interface.

Frame relay technology uses high-speed bursts to transmit data packets encapsulated in a frame across a network. The address fields of the frame relay packet includes the 10-bit DLCI that is the heart of the frame relay header. Note that end devices at two different ends of a connection can use different DLCIs to refer to that same connection. Static maps are configured to tell routers which connection identifiers to use to find remote routers and their associated higher-layer interface addresses. Figure 2.8 is a simple representation of a frame, based on the frame used in the frame relay access standard.

A Frame

In this figure the header consists of the flag and address fields. The trailer consists of the frame check sequence and second-flag fields. The data in the frame can contain another encapsulated frame used in a higher-level or different protocol, for example:

• Data that have been framed by an earlier protocol program

• A film or video frame containing a single image in the sequence of images that are recorded

• A TDM frame that contains a complete cycle of events within the time division period.

Sites on the Web containing information about frame relay include:

http://www.frforum.com/4000/fratm/fratm.toc.html – This link from the Frame Relay Forum contains information comparing frame relay and ATM, white papers, technical briefs, tutorial information, and market surveys

http://cio.cisco.com/warp/public/537/4.html – This technology brief about packet services from Cisco Systems Inc. contains an informative section about frame relay.

Asynchronous Transfer Mode

ATM supports LANs as a high-speed backbone or WANs as a WAN data service. So far, ATM has been used primarily as a LAN service. ATM sits above the physical layer and can adapt and operate on any physical transport. Switches take the place of routers in ATM networks. ATM is suitable for carrying voice, video and data. IP multicasting can be implemented on top of ATM and frame relay often runs on top it.

ATM is perhaps the most complex ever developed by the networking industry. The deployment of ATM networks requires the overlay of a software-intensive protocol infrastructure according to A. Alles whose white paper describes the important aspects of ATM networking.

This cell-switching and multiplexing technology combines the benefits of circuit switching with those of packet switching. Both telephone companies and computer communication companies are responsible for its development. ATM is a key component of broadband ISDN (BISDN).

ATM does not guarantee data delivery but instead relies on end nodes to provide this function. It is capable of high speed, defined at 155 Mbps and 622 Mbps. T3 and faster carriers sometimes use it as a very high-speed backbone. In general, frame relay is intended for use at T1 speed and below, while ATM is intended for T3 speeds and above.

ATM is based on 53-byte fixed-length cell calls. The 53-byte cell consists of 48 bytes of data and 5 bytes of routing information. This small cell size is an important component in ATM's support for both fixed-bit and variable-bit rate information. Individually, a cell is processed asynchronously relative to other related cells and is queued before being multiplexed over the line.

Figure 2.9 shows a sample ATM network.

An ATM Network

An ATM network consists of one or more sets of ATM switches connected by point-to-point interfaces of two types:

• User network interfaces (UNIs) that connect ATM end systems such as hosts and routers to an ATM switch

• Network-node interfaces (NNIs) that connect two ATM switches and are the physical or logical links across which ATM switches exchange protocol information.

ATM networks are connection oriented. Prior to any data transfer, a connection needs to be set up across the ATM network using either PVCs SVCs. Once a circuit is established, the protocol selects a physical route from source to destination and enters the information in a route table in the switch (see Figure 2.10). All the switches along that pathway make table entries so they can route packets accordingly. All messages for that connection follow the same path to the destination.

ATM Connection Setup Showing a SVC to the Destination Host

ATM supports multicast at the link layer. Vicki Johnson, Marjory Johnson and Ken Miller say "Standards efforts are being directed at enabling a sender of a multicast group to establish a point-to-multipoint switched virtual circuit (SVC) between itself and a set of known receivers, via UNI 3.0/3.1 signaling mechanisms." Such services would enable IP multicast to be run on top of ATM, using point-to-multipoint virtual circuits as the multicast delivery tree.

Comparison of Packet Switching Technologies

Table 2.6 compares characteristics of the frame relay, SMDS, and ATM FDDI technologies.

Comparison of Packet Switching

Feature Frame Relay SMDS ATM

Standard origin CCITT and ANSI, IEEE 802.2 Bellcore CCITT

Speed 56 Kbps -25 Mbps 155 Mbps 155 Mbps with 622 Mbps possible

Data Unit Size Up to 4096 bytes Up to 9188 bytes Fixed at 53 bytes

Service type Packet-switched datagram service Packet-switched datagram service Cell-switched service

Transmission facilities T1 T1 (sometimes T3) T3 and greater

Multicasting support Yes Yes Proposed

Connectionless No Yes No

PVCs Yes N/A Yes

SVCs Proposed N/A Yes

The technology brief "Packet Services" from Cisco Systems providing a comprehensive description and analysis of packet service technologies can be found at: http://cio.cisco.com/warp/public/537/4.html

Integrated Services Digital Network

ISDN, introduced in the mid 1980s, is a set of CCITT/ITU standards for high-speed digital transmission over ordinary telephone copper wire and other media. ISDN is the integration of both analog or voice data with digital data over the same network.

ISDN has had a dramatic effect on todayís communication by stimulating the advent of many new communication applications including telecommuting, videoconferencing and quality audio transmission, teleradiology and remote health care, and interactive publishing. This is only the beginning.

In many locations in the U.S. and Europe, ISDN services are available from the telephone company for home and business users. The service can be either custom national ISDN. Custom ISDN refers to components and service that use procedures proprietary to a specific manufacturer. National ISDN contains components and services that conform to the Bellcore ISDN standards which are not proprietary. In either case users install an ISDN adapter in place of a modem, an adapter must be at both ends of the transmission.

Operation

ISDN has two types of channels: bearer channels (B channels) carry data, voice, and other services while delta channels (D channels) carry control and signaling information. In addition, two types of ISDN service exist, Basic Rate Interface (BRI) and Primary Rate Interface (PRI) service.

BRI service consists of two 64-Kbps B channels and one 16-Kbps D channel. It is intended to meet the needs of individual users and small offices. PRI service consists of 23 64-Kbps B channels and one 64-Kbps D channel for signaling purposes. In Europe PRI consists of 30 B channels plus one 64-Kbps D channel.

ISDN call control procedures use messages encapsulated in packets to initiate, monitor, and release connections. A BRI service call routes these messages through the D channel. A PRI service call routes the message over the 24th channel, which is the D channel in the U.S.

ISDN also has two forms of service: narrowband and broadband.

Narrowband ISDN

Narrowband ISDN has transport speeds of 1.54 Mbps or less and provides support for the services shown in Table 2.7.

Narrowband ISDN Services

Type of Service Supports

Circuit-Switched Voice Functions as a business center over a 4-wire ISDN Digital Subscriber Line (DSL)

Circuit-Switched Data End-to-end digital service passes data or video information over the public network

Low-Speed Packet Monitors the management of ISDN connections through the D channel on a DSL

High-Speed Packet Circuit-switched voice, circuit-switched data, or high-speed packet service through the 64 Kbps B channel

Broadband ISDN Services

Broadband ISDN has transport speeds in excess of 1.54 Mbps and usually ranging from 25 Mbs to the gigabit range. The speeds in the broadband are made possible by the high quality of the digital facilities in place on the network.

Broadband ISDN service can be in the form of:

• Frame relay, supporting variable-size data packets

• SMDS, providing a high-speed digital path for PVCs

• ATM, providing a high-speed cell relay for the delivery of data, voice, and video.

Custom ISDN and National ISDN

Both the custom and national ISDN standards use the OSI reference model. The physical layer of the OSI model, Layer 1, defines the physical properties of an ISDN circuit and also defines the type of connectors used.

The Q.921 recommendation defines Layer 2 for ISDN lines. This layer provides for establishing procedures to maintain communication between two network components. In the case of ISDN the two components are the ISDN terminal and switch. An ISDN terminal is in constant communication with the ISDN switch.

The Q.931 recommendation concerns the Layer 3 specifications for ISDN. These define the network layer and provide procedures to make end-to-end connections on the network. ISDN establishes circuit-switched voice and data connections. Packetized messages initiate, monitor, and release circuit-switched connections. The information part of the Q.921 information frame relays call procedure messages between the ISDN terminal and the ISDN switch.

Connections

There are two types of packet connections: PVC and SVC.

A permanent virtual circuit is a connection that is permanently assigned. The address information for the data sent and the action are always the same. The connection acts as though there were a direct hardware connection between the two terminals, although this is not so.

In a switched virtual circuit the information is delivered based on the address information provided on a session-by-session basis.

For more information on ISDN, consult:

http://www.pacbell.com/products/business/fastrak/networking/isdn/info/isdn-guide/index.html – A Pacific Bell site that provides an introduction to ISDN

http://www.shiva.com/remote/isdn/net/ – A white paper, "ISDN Telecommunications Network" with a comprehensive explanation of ISDN technology written by Walt Mansell of Shiva Corporation.

http://alumni.caltech.edu:80/~dank/isdn/ – One of the best Internet resources ISDN.

Backward Forward
Chapter: Preface | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.
Beta Books | Beta Bookstores | Computing McGraw-Hill

Professional Publishing Home | Contact Us | Customer Service | For Authors | International Offices | New Book Alert | Search Catalog/Order | Site Map | What's New

A Division of the McGraw-Hill Companies
Copyright © 1998 The McGraw-Hill Companies, Inc. All rights reserved. Any use is subject to the Terms of Use the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers.


Marcus Goncalves
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Chapter Three

ATM's Role in Multicasting

This chapter provides more in-depth discussion of ATM technologies and the IP protocols supporting ATM, a topic very important for understanding the features (and limitations) of using IP over ATM, and more specifically, voice over IP (VoIP). It is based on a contribution made by Phillip Emer, Associate Director Advanced Technology Development at North Carolina State University. We thank him for his contribution and deep knowledge on the subject of ATMs and their applications.

For more information on this subject, or to contact Phil the e-mail address is at phil@ncstate.net

Describing ATM Services and Support

The layered approach to describing ATM, shown in Figure 3.1, stresses the interactions between the many layers and sublayers and the passing of service data units up and down the layered stack. This approach explains how ATM software and hardware components come together to form an ATM node.

Describing an ATM

The peer approach to describing ATM addresses the peer-to-peer operations between ATM devices, stressing the functions provided by ATM hardware and software and how these functions interact to support an ATM network. As shown in Figure 3.2, the main characteristics of ATMs relevant to ATM network designers and to the peer approach to ATM in general are:

• ATMs are connection-oriented and point-to-point

• They provide integrated services—voice, video, data

• They support quality of service (QoS)

• They scale to gigabit speeds

• They use 20-byte addressing.

Relevant ATM characteristics

Connection-Oriented Support

Figure 3.3 shows how connection-oriented systems (POTS, ISDN, X.25, TCP, ATM), establish connections between a pair of communicating systems. In the phone system a connection is associated with a physical dedicated link. In ATM, a connection is a virtual link (circuit) characterized by a class of service that it must deliver to the users of the circuit (e.g., a constant bit-rate service for uncompressed voice over ATM).

A Layout of Connection-Oriented ATM Systems

Connection-oriented systems support a set of protocols for transmission of data and another set of protocols for establishing connections (e.g., SS7, Q2931). End systems request that the network establish a connection by sending messages to the network over a predefined control channel (circuit). Once the network has established a data channel (circuit) per the request, data are forwarded over that channel. Connections may be established by a network manager as PVCs or may be dynamically established by system software as SVCs.

Integrated Services Support

Since ATM is the outgrowth of broadband ISDN, integrated services support was a design consideration from the start. However, many technical compromises were necessary to support three very different network traffic categories. The result of these compromises, listed in Figure 3.4, is that ATM supports the combination of voice, video and data optimally—not necessarily the individual services.

ATMs Support Integrated Services

Voice Support

Voice is supported in an ATM network via circuit emulation, via circuit switching, or as data. Circuit emulation is a migration path supporting emulation of T1-style WAN circuits, as shown in Figure 3.3. In general many voice circuits are mapped to a single ATM PVC. Voice compression, network echo cancellation, and silence suppression mechanisms may be added as enhancements for bandwidth efficiency. Optimal support of voice would map traditional 64-kbps voice circuits dynamically to ATM circuits (SVCs).

ATM's Voice Support via Circuit Emulation

Voice is also supported on IP platforms as data. Some of the same coding, compression, and echo cancellation techniques are applied here as they are in circuit emulation.

Video Support

Figure 3.6 shows how video is supported, as real-time, non-real-time, and as data. Real-time video applications include video conferencing and live video broadcasts. Support of real-time video levies strict delay requirements on the ATM network (actually strict delay variation—or jitters—requirements).

ATMs Support Video as Real-time and Non-real-time

Non-real-time video applications such as video-on-demand use application level techniques (buffering) to account for inconsistent delays encountered during transit through the ATM network. Thus, the ATM network need not be responsible for ensuring low delay variation requirements (at least not as strictly responsible as in the real-time case).

Nonetheless, video over ATM is a bit more complicated than voice, since video terminals are actually audio/visual terminals, that is, voice and video are related and must be kept synchronized. Figure 3.7 illustrates a simple representation of a broadband (ATM) video terminal (H.310 in ITU jargon).

A Simple Representation of a Broadband (ATM) Video Terminal

Data Support

Figure 3.8 shows how data can be supported, at various levels: LAN, IP, multi-protocol, and native.

Data Support on ATMs

The idea of supporting data over ATM is that a migration path is required since data applications are tied to platforms, operating systems (OSs), application programming interfaces (APIs), and protocol stacks (e.g., IP, IPX, Appletalk), as shown in Figure 3.9:

1) First, software shims are added around low layer APIs (close to device drivers—the effect to hide ATM from existing applications and protocols (users)

2) Then, low layer and higher layer APIs are enhanced to incorporate software shim function and to expose ATM features to existing stacks

3) Finally, a new stack and new data applications emerge—all ATM-aware.

ATM's Data support requires a migration path since data applications are very tied to platforms..

Quality-of-Service Support

As Figure 3.10 outlines, ATM supports QoS, enabling end-to-end integrated service support and guaranteeing performance to connections and service classes (queues), including:

• Constant bit rate (CBR)

• Variable bit rate (VBR) - real-time and non-real-time

• Unspecified bit rate (UBR)

• Available bit rate (ABR).

ATMs Quality of Service (QoS) Support

ATM technology is also scalable to gigabit speeds (as Figures 3.11 and 3.12 outline). ATMs also use 20-bit addressing, as shown in Figure 3.13:

• Network Service Access Point (NSAP) identifies an ATM network

• End System Identifier (ESI) identifies a device on an ATM network

• Selector (Sel) allows a device with a single ATM interface to have multiple ATM addresses.

ATM Support Scaled to Gigabit Speeds

ATM's QoS Support

ATM Address Format

ATM network addressing is similar to Novell Netware network addressing in that the end system has an address with two distinct pieces, network and local, as shown in Figure 3.14. This is a nice feature especially when analyzing and troubleshooting a network. Since ATM addresses are made up of a network part and a local part, a misbehaving client can be tracked down easily based on its ATM address.

ATM network addressing is similar to Novell Netware network addressing.

The IP addressing scheme is totally distinct from the local (LAN) addressing scheme, so knowing an IP address is not enough to isolate a misbehaving client in this case (the local address of the client must be known).

Figure 3.15 shows that an ATM address can be represented in a naming format much as an IP address. Note that ATM device names will use the same domain name services (DNS) that IP hosts use, with an extension that maps 20-byte local addresses to a name.

A Hierarchical Addressing Structure

As is the case for IP addresses, there is a process in place for network managers to acquire unique network name and address space. In the case of ATM there are several registration authorities from which one can acquire ATM code points (in the US) the National Institute of Standards and Technology (NIST) and the American National Standards Institute (ANSI). Basically, ANSI or NIST assigns a 3-octet organization identifier (ORG) code point. This ORG field follows 4 octets of identification bits, which identify the country and registration authority (e.g., ANSI). Once an organization obtains an ORG value, the 7 most significant octets of the ATM address uniquely identify the ATM network of that organization. The owning organization is then responsible for the encoding of the remaining 6 octets in the ATM network part of the ATM address. Recall that the least significant 7 octets of the ATM address are locally (client) significant and associated with the ATM client device.

Summary

As we see in Figure 3.16, ATM is flexible, providing integrated services; ATM is scalable, enabling SONET transmission and 20-byte addressing and ATM is available.

Summary of Benefits of ATM Technologies

ATM Networking

In deploying ATM networks, there are several models to adopt. Figure 3.17 outlines the main models: End-to-end, desktop, campus, WAN, and carrier.

ATM Networking: the Main Models

The End-to-end ATM Model

Earlier in this chapter we noted that one of the relevant characteristics of ATM is that it supports integrated services. ATM can support voice, video, and data in the campus, in the WAN, in the carrier network, and in residential access networks, as Figure 3.18 and 3.19 show.

The End-to-end ATM Model.

An Outline of the Applications of End-to-end ATM Model

At the moment ATM is implemented in Campus, WAN, and Internet backbones, as depicted in Figure 3.20. Figure 3.21 provides the status of end-to-end ATM at glance. There have been some ATM-based trials in residential access environments (cable modems and ADSL)—commercial services are likely to roll out over the next year mainly for Internet access.

ATM is being implemented in campus, WAN, and Internet backbones.

Status of ATM End-to-end Deployment to Date

The ATM Desktop Model

In the ATM desktop model, as depicted in Figure 3.22, workgroup switches are replacing Ethernet hubs. Category 3/5 cabling is being used for LAN emulation to provide migration path. Old applications are being rewritten to take advantage of QoS, thus enabling high-quality video and voice to join data. Figure 3.23 shows the status of ATM desktop model implementations.

The ATM Desktop Model

Status of Implementations of ATM Desktop Model

The Campus Backbone Model

Campus backbone models are using ATM switching to replace FDDI in the backbone. Video and voice networks are migrating to ATM as the data network is flattened. VLANs obviate the need for routing, as switched virtual circuits dominate. Figure 3.24 provides an outline of these applications and Figure 3.25 shows the status of their implementation.

The ATM Campus Backbone Model

Status of Implementations of ATM Campus Backbone Model

The WAN Model

In the WAN model, as shown in Figure 3.26, the idea is to replace TDM-type multiplexers with ATM edge switches. These edge switches support adaptation of LAN data traffic and PBX voice traffic to ATM.

The ATM WAN model

The idea here is to use the same WAN links to carry voice and data—ATM will allow for running these links at much higher utilization due to the QoS and backbone WAN (BW) management capabilities inherent in ATM. The ATM adaptation for voice in this case comes in two flavors: uncompressed constant bit rate, and compressed (e.g., ADPCM, CELP) variable bit rate.

WAN network managers are accustomed to the "over-subscription" method of BW management. Moving to ATM in this arena requires a departure from this inefficient method of BW management, as depicted in Figure 3.27; like any paradigm shift it will take time.

Status of ATM WAN Deployment

ATM Carrier Model

Figure 3.28 shows how voice in the carrier model means switching voice circuits as ATM circuits, unlike the WAN ATM voice scenario, which may switch many voice circuits over a single ATM circuit.

ATM Carrier Model

Figure 3.29 shows the status of implementations over ATM carrier models. Time Warner implemented an ATM-based, interactive, video-on-demand service, as a trial, in Orlando, FL. In that trial ATM circuits terminated in a set-top box—ATM transported MPEG2 video to the set-top. Time Warner found it better to use ATM switching in the carrier network and use MPEG2 as the transport for video. Another, perhaps more important, finding was that users are not willing to pay enough for interactive television to justify large-scale implementation of such systems. Instead, carriers, telcos, and cable companies are focusing on offering Internet-based interactive services to the home. Much of the work in this area employs ATM switching and in some cases ATM connections to the home. The remote broadband working group in the ATM Forum writes specifications for ATM-based residential networking (e.g., ATM-based cable modems and ADSL).

ATM Carrier Model Implementation Status

Figure 3.30 shows how Ethernet dominates desktop access, IP dominates as data transport, IP transports voice and video as data, ATM switches IP, and Adaptation devices at the edge of ATM networks "adapt" voice, video, and data individually to optimally flow across ATM networks.

Summary of ATM Carrier Model Deployment

IP Over ATM Requirements

Since IP is the dominant network layer data protocol, ATM network designers are clearly interested in the requirements associated with using ATM as a transport for IP data. More specifically, we are interested in how IP uses the services of ATM (or perhaps more correctly, how to hide the characteristics of ATM from IP).

In general, as shown in Figure 3.31, emerging "IP Over ATM" (IPoATM) protocols must address:

• Encapsulation (and multiplexing)

• Emulating point-to-point links (no more shared media)

• Establishing connections (since IP is connectionless)

• Integration with legacy networking

• Internetworking (routing issues).

IP over ATM Requirements

Encapsulation issues include how packets are mapped to cells and how the IPoATM protocol recognizes a stream of ATM encapsulated packets. Emulating a point-to-point link means treating a virtual circuit as a dedicated link. Establishing connections involves resolving IP characteristics into ATM connections in support of unicast and multicast operation. Integration with legacy networking involves bridging and gateway strategies. Finally, internetworking in the IPoATM context involves defining "a network" and providing a mechanism for communications between these networks (i.e., routing).

The IETF and the ATM Forum, are contribution-driven groups dedicated to the promotion of openness and interoperability in the IP and ATM marketplaces, respectively. In Figures 3.32 and 3.33 it is easy to see that both the IETF and the ATM Forum create interoperability specifications, although both groups argue that they do not write standards.

IP over ATM Specifications

Data Protocols

Figure 3.34 provides a layered model to illustrate the similarities and differences between the pot luck of IPoATM protocols.

The ATM Data Model

ATM Network Services

An ATM backbone network must, at minimum, support a signaling service, as shown in Figure 3.53. Such a signaling service allows clients (users) to establish connections across the connection-oriented ATM "cloud". At present there are two signaling services available for campus ATM backbones—the ATM Forum-defined UNI signaling and the IETF (Ipsilon)-defined general switch management protocol. All switches support UNI signaling and many (not all) support GSMP signaling as well.

The ATM network may also support address resolution services, multicast services, routing services, etc.—in general, services necessary to support legacy LAN applications (e.g., IP applications like FTP and Telnet).

ATM Network Services

Figure 3.36 shows how in an ATM environment virtual circuits emulate links. Virtual circuits then act as virtual links, which implies virtual ports and logical networks. At the IP layer the logical view of the network may be quite different from the physical topology.

ATM Routing Functions

As we deploy fast LAN switching at the access point of the network and fast ATM switching at the core of the network, the software-intensive IP functions performed by routers are clearly the bottleneck. Recognizing that IP routing function is required, we try to avoid forwarding packets through routers while benefiting from routing services.

ATM Client/Server Accessibility

Figure 3.37 describes ATM's client/server accessibility. This is not an exhaustive list of client devices. There are other ATM-attached devices that perform adaptation, including the cells in frames attachment device (CIF-AD), which works in concert with Ethernet clients to provide an ATM-over-Ethernet function. An ATM concentrator is an example of an ATM-attached device that performs no adaptation (ATM WG switches are used in place of these devices today).

ATM's Client/Server Accessibility

Other interesting access devices include cable modems, xDSL modems, and inverse multiplexing access devices. When we take a look at the list of interoperability data protocols (Figure 3.38), and pin down RFC 1483, "Multiprotocol Encapsulation", we notice that routers are the only ATM-attached devices in this model, illustrated in Figure 3.39

RFC 1483: Multiprotocol Encapsulation

Diagram of RFC 1483

Also notice in Figure 3.40 that RFC 1483 defines an encapsulation method for supporting multiprotocol encapsulation over ATM AAL3. The RFC provides two methods for supporting this encapsulation. LLC/SNAP encapsulation uses IEEE 802.2 SAP headers for multiplexing, protocols over a single ATM circuit. In the second method distinct virtual circuits are proposed for each protocol.

RFC 1483 Specification

In RFC 1577 (see Figure 3.41), CIP, we notice that the ATM backbone supports several services in addition to signaling, as described in Figure 3.42. CIP relies on an one-armed router for routing services. CIP also requires a router for communication with legacy LAN devices, which makes sense since CIP supports only IP. Thus LAN clients, such as servers and workstations, communicate with CIP clients through a router. Also keep in mind that CIP is a mechanism supporting unicast IP over ATM which requires one-armed router function for communication between CIP subnets.

RFC 1577, Classical IP

Diagram of a Classical IP (CIP)

ATM CIP Services

Classical IP services provide a means of mapping connectionless protocols, namely the IP protocol, into a connection-oriented backbone environment. To this end CIP provides an ATM service for resolving IP addresses into ATM addresses, allowing a CIP client to establish a connection to a destination IP host by using the ATM network's signaling service.

For IP multicast support over ATM, RFC 2022 provides a mechanism for mapping IP multicast addresses to ATM multipoint circuits, as shown in Figure 3.43.

An Overview of ATM CIP Services

A one-armed router provides routing services for the ATM backbone, as described in Figure 3.44. It can also provide routing services between CIP logical IP subnets by (LIS) becoming a member of each LIS. Note that a LIS is defined by a set of hosts registered with the same ARP server.

A one-armed router is so-named because it attaches to the ATM backbone via a single ATM physical link. The router then associates logical ports with the lone ATM interface by joining LISs. There is then a virtual link associated with each logical port.

Classical IP Routing Services

Figure 3.45 shows how legacy IP subnets and hosts communicate with CIP subnets through an ATM-attached router by emulating a point-to-point link using RFC 1483 encapsulation.

Classical IP Clients

Remember that the classification of RFC 1577 given here applies to RFC 1577 alone. By adding functions specified in new RFCs and Internet drafts into RFC 1577 networks, one can build a more complete system—though other protocols, especially MPOA, integrate all of these functions into a single specification.

The Next Hop Resolution Protocol (NHRP)

The ATM backbone supports several services in addition to signaling; NHRD (Figure 3.46) is one of them. NHRP adds cut-through routing as an ATM service and LAN clients communicate with NHRP clients through a router, as diagrammed in Figure 3.47.

ATM backbone supports the NHRP.

NHRP adds cut-through routing as an ATM service.

NHRP enhances CIP function by adding "shortcuts" as outlined in Figure 3.48. The NHRP routing function is provided as a function of the ATM backbone. This routing function allows NHRP clients which are members of different LISs to establish a "shortcut" path through the ATM cloud; recall that with CIP a one-armed router must forward packets between LISs.

ATM's NHRP Services

NHRP can also be deployed in an ATM-based IP backbone, as shown in Figure 3.49. In this situation, NHRP provides a shortcut path from one edge of the IP cloud to the other, avoiding interior routing hops. NHRP requires the same address registration function as CIP, as shown in Figure 3.50, and adds distribution of address resolution across LIS boundaries.

NHRP Routing Services

NHRP Clients

ATM Forum LAN Emulation

The ATM backbone supports several services in addition to signaling. The ATM Forum LAN emulation (Figure 3.51), also known as LANE, is another one. LANE relies on a one-armed router for routing services. It employs a router for communication with the Internet, as described in Figure 3.52. LANE clients can be LAN switches and ATM-attached stations.

LAN Emulation (LANE)

A Typical LANE

ATM LANE services, (Figure 3.53), provide the means of mapping a connectionless, multicast-capable LAN in to a connection-oriented backbone environment. Thus, LANE provides an ATM service for resolving LAN MAC addresses into ATM addresses—allowing LANE clients to establish a connection to a destination LAN station by using the ATM network's signaling service. LANE also provides a mechanism for mapping LAN multicast (address-based) into ATM multicast (tree-based)—the broadcast and unknown server (BUS).

ATM LANE Services

LANE routing service (Figure 3.54), is a one-armed router that provides routing services for the ATM backbone. An one-armed router can provide routing services between LANE emulated LANs (ELANs) by becoming a member of each ELAN. An ELAN is defined as the set of hosts which register their MAC and ATM address-pair with the same LANE server.

LANE Routing Service

LANE was designed as migration protocol for clients, allowing ATM-attached stations to communicate with each other using applications written for connectionless environments (Figure 3.53). LANE was also designed to support bridged communications between legacy stations over an ATM backbone. The intent was that this be a migration technology, employed only to allow a graceful switch over to an ATM desktop solution with LAN applications rewritten to the native ATM API. However, there are still no native ATM applications (other than LANE itself). LANE is now being remarketed (and redesigned) as an ATM-based, bridged VLAN solution.

LANE Clients

ATM Forum Multiprotocol Over ATM (MPOA)

The ATM MPOA (Figure 3.56) is identical to LANE, but has an added cut-through routing service as an ATM network function, as shown in Figure 3.57.

ATM Forum Multiprotocol Over ATM (MPOA)

MPOA Diagram

ATM MPOA services, (Figure 3.58), provide a means of mapping connectionless, multicast-capable LAN environments, and intranets into connection-oriented backbone environments. MPOA provides ATM services for resolving LAN MAC addresses and network addresses into ATM addresses, allowing MPOA clients to establish a connection to a destination station or host by using the ATM network's signaling service. MPOA also provides mechanisms for mapping LAN multicast into ATM multicast (tree-based).

ATM MPOA Services

MPOA adds NHRP to the LANE one-armed router. In addition, there is a mechanism for distributing and caching shortcut (cut-through) addressing information to MPOA clients. MPOA clients can then perform Layer-3 packet forwarding functions and cut through the ATM network, avoiding router hops along the way.

In LANE (Figure 3.59), the one-armed router acts as a traditional router, performing packet forwarding and route processing, but with logical ports instead of physical ports. MPOA adds NHRP function to these one-armed routers. By adding NHRP, the one-armed router sheds the responsibility of steady-state packet forwarding, which is now handled by clients directly, since NHRP allows for the establishment of shortcuts between MPOA clients. Thus, MPOA defines a distributed routing solution, separating routing function from packet forwarding function.

MPOA Routing Services

Just as NHRP enhances or actually replaces CIP with shortcut routing, MPOA is LANE-enhanced with shortcut routing (Figure 3.60).

MPOA Clients

IP Switching and Multiprotocol Label Switching (MPLS)

IP Switching and MPLS (Figure 3.61) require a single signaling service in the ATM backbone, as shown in Figure 3.62. Routers, LAN switches, servers, and workstations may be ATM-attached in this model as well.

IP Switching and Multiprotocol Label Switching

IP Switching and Multiprotocol Label Switching

In classic IP, LANE, and multiprotocol over ATM, MAC and IP addresses are mapped to ATM addresses, so that ATM signaling can be used. ARP services are therefore required to resolve legacy addresses into ATM addresses (Figure 3.63). In IP switching protocols, IP flows or topologies are mapped to ATM virtual circuits directly. This obviates the mapping of legacy addresses to ATM addresses.

ATM IP Switching Services

The purpose of IP switching is to avoiding replication (Figure 3.64). ATM provides new complex mechanisms in support of multicast, routing, and addressing. There are already protocols (and applications) supporting these functions for IP. IP switching marries IP functions with the hardware benefits of ATM switching. The result is that the IP routing function is applied at the edge of the ATM network and ATM switching becomes the high-speed packet-forwarding core.

IP Switching Routing Services

Much as in NHRP and MPOA, the concept of IP switching is to avoid processing packets in routers in the middle of the ATM network; where possible router hops are avoided (Figure 3.65).

IP Switching Client

Summary

In summary, LANE, MPOA and IP switching provide solutions which allow for building a robust backbone network based on an ATM switching core. Figure 3.66 provides an outline of the features offered.

Features and Standards of IP over ATM

What's Next

This chapter discussed the ATM data model, its network services, data protocols and LAN emulation, as well as ATM MPOA services. Chapter 4 investigates digitization methods and packet-based voice applications.

Backward Forward
Chapter: Preface | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.
Beta Books | Beta Bookstores | Computing McGraw-Hill

Professional Publishing Home | Contact Us | Customer Service | For Authors | International Offices | New Book Alert | Search Catalog/Order | Site Map | What's New

A Division of the McGraw-Hill Companies
Copyright © 1998 The McGraw-Hill Companies, Inc. All rights reserved. Any use is subject to the Terms of Use the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers.


Marcus Goncalves
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Chapter Four

Multicasting Overview

In a unicast environment a node only has the ability to send to one other node at a time. In a multicast environment, a node can efficiently send a single packet of information to multiple destination nodes in one operation. A node's operating system and TCP/IP stack must support IP multicasting for the node to participate in multicasting.

A multicast node makes a single call on a transport service that in turn delivers a copy of that message to each destination node of the multicast transmission. The number of destination nodes can be 0, all, or any number in between. Sending unicast (one node) and broadcast (all reachable node) messages are special cases of the multicast method. If the underlying transmission medium, such as Ethernet or SMDS, supports multicast and broadcast, then using an application that involves a single node sending to many recipients is a clear choice. Multicasting can provide a considerable improvement in performance, usually uses no more bandwidth than a single transmission on each network, and allows the construction of truly distributed applications.

The only difference between a multicast IP packet and a unicast IP packet is the presence of a "group address" in the destination address field of the IP header. Instead of a Class A, B, or C IP address, multicasting employs a Class D destination address format (224.0.0.0- 239.255.255.255).

This chapter describes multicasting and some of its advantages:

• Introduces multicasting in workgroups

• Describes multicasting capabilities on hosts and routers

• Introduces multicasting in the Internet Protocol and adding multicast support of the IP layer

• Describes the multicast backbone and evaluates IP multicast usage and implementation

• Presents security issues in IP multicasting.

RFC 966, "Host Groups: A Multicast Extension to the Internet Protocol" by S. Deering and D. Cheriton published in 1985 was the first official step in adding multicasting support for the Internet.

RFC 1112 "Host Extensions for IP Multicasting" by S. Deering, published in August 1989, is an official standard (STD-5) and replaces RFC 966.

Introducing Multicasting

IP multicast is an extension of IP. The IETF recommended standard, RFC 1112, defines extensions to the IP. A relatively new feature of the IP, IP Multicast is a protocol for transmitting IP datagrams from one source to many destinations in a LAN or WAN. Groups of receivers participate in multicast sessions. With IP multicast, applications send one copy of the information to a group address. The information reaches all the recipients who want to receive it. Multicast technology addresses packets to a group of receivers rather than to a single receiver; it depends on the network to forward the packets to only the networks that need to receive them. Multicast-enabled nodes that run the TCP/IP suite of protocols can receive multicast messages.

Multicasting is a push technology in which a server sends data to a client without the client requesting it (see Figure 4.1). The terms push and pull appear frequently in discussion of how information is delivered over the Internet. In pull technology a client requests data from a server or from another computer. E-mail and PointCast are both examples of push technology while the Web is based on pull technology. In this case the client browser requests the delivery of a page.

Multicasting to Multiple hosts Distributed Throughout the Internet

Standards-based IP multicasting supports thousands of users simultaneously without substantially affecting bandwidth requirements. In addition, IP multicast routing protocols provide efficient delivery of datagrams from one source to any number of destinations throughout a large, heterogeneous network such as the Internet. If the network hardware supports multicast, then packet a destined for multiple recipients can be sent as a single packet.

There are three fundamental types of IPv4 addresses: unicast, broadcast, and multicast. A unicast address is designed to transmit a packet to a single destination. A broadcast address is used to send a datagram to an entire subnetwork. A multicast address is designed to enable the delivery of datagrams to a set of hosts configured as members of a multicast group in various scattered subnetworks.

Transmission Types

IPv4 supports three address types, unicast, broadcast, and multicast. The type of address used determines how a source transmits identical data to multiple receivers. The traditional transmission methods unicasting and broadcasting differ markedly from IP multicasting. Mapping IP multicasting to LAN multicasting methods involves three separate operations: multicast address resolution to LAN multicast addresses, copying and forwarding of messages, and group membership registration.

Unicast Transmission

A unicast address is designed to transmit a packet to a single destination. A unicast transmission is inherently point to point (see Figure 4.2).

Basic Unicast Point-to-Point Transmission

If a node wants to send the same information to many destinations, it must send a copy of the same data to each recipient in turn. The same information must be carried over the network multiple times. Unicast avoids sending the data to networks where there are no stations that need it but it does use up network bandwidth and resources. In addition, the node needs to generate separate identical data streams for each recipient. This is extremely inefficient and uses up processing power and memory.

Broadcast Transmission

A broadcast address enables the delivery of a single data stream to every station on an entire subnetwork. In other words, a broadcast allows one station on the network simultaneously to talk to all devices contained in the same broadcast domain, or subnet. Routers and switches forward broadcast but in doing so they use bandwidth and have no way of knowing if any of the nodes on the other network want the broadcast data. Broadcasting does not consume the sender's resources any more than single unicasting does, but it inefficiently consumes network resources.

Some protocols use broadcasting to discover resources from the network. To prevent broadcast messages from flooding the network, a system administrator may configure routers to pass or block broadcast on any particular route. Many data communication networks restrict broadcasting to one physical or logical segment of the network.

Multicast Transmissions

A multicast address enables the delivery of a singe data stream to a set of hosts configured as members of a multicast group in various scattered subnetworks. It is a method to reach several recipients in one transmission (see Figure 4.3). Other nodes filter out multicast packets at the hardware level. Multicasting is the process of sending to a self-selected group of recipients that is often substantially less than the full population of recipients. Each recipient must be defined separately and it must be possible to control which recipients receive data. Multicast dynamic groups of recipients can be created and removed quickly.

Example of a Multicast Transmission

Summary of Multicast Operation

Multicast techniques span many areas of networking, including video and teleconferencing, multimedia presentations, news distribution, and remote live broadcasts such as those from space. IP multicast can run over almost any network infrastructure including Ethernet, ATM, frame relay, SMDS, and satellite. For multicasting to work, multicast-aware TCP/IP stacks installed on all the participating machines.

Multicasting is connectionless, which means that a multicast datagram is neither guaranteed to reach all members of the group nor guaranteed to arrive in the same order as it was sent. The protocol delivers a multicast datagram to the destination group members on a best-effort basis.

This basis can introduce latency and variability of delay in end-to-end paths. However, multicast applications require control over the quality of service (QoS) they receive. The level of security, bandwidth, delay, jitter, error rates, cost, and compression are some of the parameters that differentiate the network services that QoS provides. The Resource Reservation Protocol (RSVP) is a key protocol that makes QoS possible.

The protocols and algorithms used by multicasting applications are diverse and complex. Multicasting can be implemented at several layers of the OSI model, on different media, and with different protocols.

The online Packet Magazine article "Building Consistent Quality of Service into the Network" located at http://www.cisco.com/warp/public/67416.html from Cisco Systems discusses new ways to ensure network resources for integrated services and quality of service issues facing network administrators.

Multicasting in Different Layers

Multicasting can be implemented at both the data-link layer and the network layer. At the data-link layer level Ethernet, FDDI, and token ring support multicast addresses in one fashion or another. Implementing multicasting in the data-link layer (Layer 2) is sufficient if the multicast application is restricted to one LAN.

However, implementing multicasting should occur in the network layer (Layer 3) if the multicasting application is to extend beyond a single LAN or extends to an Internet consisting of different media types and network technologies. Multicasting at this layer happens because of:

• ISO/OSI Layer 3-to-Layer 2 address translation

• Dynamic registration with the router by a computer indicating that it is a member of a particular group. RFC 1112 defines the IGMP. IGMP specifies how the host should inform the network that it is a member of a particular multicast group.

• Multicast-aware routing including router-to-router communications. Several standards are available for routing IP Multicast traffic:

–RFC 1075 defines the Distance Vector Multicast Routing Protocol (DVMRP)

–RFC 1584 defines the Multicast Open Shortest Path First (MOSPF) protocol, an extension to OSPF that allows support of IP Multicast

–RFC 2117 defines the Protocol Independent Multicast-Sparse Mode (PIM-SM) protocol, one of two describing PIM

–Protocol Independent Multicast-Dense Mode (PIM-DM) is currently an Internet standards-track draft.

Chapters 7 and 8 describe multicast routing and routing protocols in more detail.

Address Translation

A multicast address enables the delivery of datagrams to a set of hosts that have been configured as members of a multicast group in various scattered subnetworks. A Class D address is a multicast address and identifies the group of machines or interfaces that represent a multicast group. For example, a Class D address could identify all the interfaces attached to IP network routers. All logical holders of a particular Class D address receive packets sent to that address

The destination address field of the IP header in a multicast IP packet contains a Class D group address instead of a Class A, B, or C IP address. A Class D address is an IP address and has the format 224.0.0.0 - 239.255.255.255.

In Class D addressing the lower 256 entries of the address range are reserved for administrative functions and system-level routing chores. The middle range is for use by multicast end-user applications within groups, intranets, and the Internet. The upper range of the Class D address set is reserved for locally administered or site-specific multicast applications (see Figure 4.4).

Class D Multicast Addressing

When a local router on a subnet receives a Layer 3 multicast packet, it can map the IP multicast address to a Layer 2 multicast address, such as an Ethernet MAC address. The receiving host's LAN interface hardware can efficiently read this Layer 2 address. Layer 2 LAN protocols typically reserve portions of their address space for broadcast and multicast frames, for example, the Ethernet broadcast address FF-FF-FF-FF-FF-FF.

Address translation from the IP (Layer 3) address to the Layer 2 address occurs by directly mapping the IP address into an Ethernet MAC address. This is accomplished by dropping the low-order 23 bits of the IP multicast address into the low-order 23 bits of the Ethernet multicast address.

Multicasting and Routing

Sending the information just once to multiple users can produce large savings in bandwidth. Copies of the message are made only when paths diverge at a router, as when the message is supposed to be passed on to another router as well as to a workstation attached to the current router.

Multicast-enabled routers forward a multicast to a network only if there are multicast receivers on that network. Host machines use the IGMP to inform multicast-aware routers of any multicast sessions in which they want to participate. If all members of a multicast group on a particular network segment leave the group, the router ceases to forward multicast data to that segment.

The only time a router running IP multicast duplicates a packet is at "forks" in the path. Routers send only one copy of each packet over each physical network.

Among a number of competing multicast routing protocols three are: DVMRP, MOSPF, and PIM.

Multicast Groups

Building a multicast group starts with a server running a multicast application such as an audio, video, or financial. Once a server has been brought up, a Class D multicast address is assigned to the application and all its members. Any server involved with the application addresses packets to the group address.

When a receiver wants to join a group, it sends an IGMP message containing the Class D address of the desired group to it local multicast-capable router. From that point on, group messages are directed to receiver's subnet (see Figure 4.5).

Figure 4.5.

IGMP Message

Individual hosts are free to join or leave a multicast group at any time. There can be any number of members in a multicast group and those members can be located anywhere in the Internet. A router uses a group membership protocol to learn about the presence of group members on directly attached subnetworks.

IP Multicasting Uses and Benefits

In today's business environment vast amounts of information products need to be delivered to multiple sites in real time. At the same time business and research need to retrieve large amounts of passive or static data on a daily basis. New data communication networks have created much more capacity. The increased capacity has fostered new possibilities for developing innovative services. These new services have created a need for new transmission methods including the underlying communications infrastructure.

Currently the majority of Internet applications rely on point-to-point transmission that traditionally has been limited to LAN applications. Business is now very frequently a global affair.

IP multicasting forces the network to do packet replication, which conserves bandwidth. IP multicast is a good alternative to unicast transmissions when a company needs to deliver applications to multiple hosts at the same time. It is important to note that the applications for IP multicast are not solely limited to the Internet. Multicast IP can also play an important role in large distributed commercial networks.

Reducing Network Load

Using IP multicast can reduce the load on the network. For example, assume that an application needs periodically to transmit packets to several hundred hosts within the company. Periodic unicast transmission of these packets would require many of the packets to traverse the same links. Multicast transmission of those same packets would require only a single packet transmission by the source. This transmission is then replicated at forks in the multicast delivery tree.

Broadcast transmission is not an effective solution for this type of application since it affects the CPU performance of each end station that sees the packet and it wastes bandwidth.

Uses

Internet multicasting is the only standards-based solution that can support thousands of users simultaneously without affecting bandwidth requirements. In response to business needs some, of today's ISPs support IP multicasting. The following paragraphs describe a few of the many uses for IP multicasting.

In a multicast environment, the local routers, rather than the end server, deal with individual client connections.

Information Distribution

IP multicasting makes possible the distribution of internal corporate data to large numbers of users. For example, a company with a chain of stores could use multicast to deliver pricing information to cash registers company wide. This preserves bandwidth locally and across the network. Multicasting multimedia data across the Internet and intranets to multiple users is an excellent way to preserve bandwidth. For example, providers of live real-time information feeds can use Internet multicasting to deliver their content. Such providers in the United States include CNN, ESPN, and Home Shopping Network.

IT managers use IP multicasting to accomplish an enterprisewide software upgrade.

Data Casting

Since 1992 the IETF has experimented with multicasting live audio and video feeds from IETF meeting sites to destinations around the world. Called datacasting, this technique takes compressed audio and video signals from the source station and transmits them as a sequence of UDP packets to a group address. Applying this technology, commercial and other organizations might be able to eliminate maintaining parallel networks for video, voice, and data.

By using multicast technology, TV and radio stations could multicast programs to users over the Internet. Traditionally such service uses broadcast transmissions that employ excessively large amounts of bandwidth on the Internet.

Video Conferencing

Currently, companies are apt to use expensive ISDN-based video conferencing equipment or services from telecommunication service providers. Interactive video conferencing using multicasting though the Internet, intranet or extranet is economically reasonable. By using IP multicasting:

• Productivity could increase because of decreased travel time

• The company could realize enormous cost benefits from saving in travel expenses

• A large percentage of the employees, rather than just a few, could "stay current" by attending video conferences.

Rather than using expensive ISDN-based equipment or services, companies could use multicast-capable computers connected through the Internet, intranet, or extranet to address their video conferencing needs.

Employee and Distance Learning

IP multicasting can deliver internal education simultaneously to hundreds of workers at a single site or at multiple sites throughout the company. Course materials, updates, and data can be instantly delivered directly to the desktop. Student can participate in real-time demonstrations and exercises even though they may be geographically dispersed worldwide.

Resource Discovery

Discover network multicast can be used instead of broadcast for resource discovery of network services. Service discoveries are usually limited to one logical subnet in a TCP/IP network, though there is no reason for this to be so. The logical area to discover servers can easily be expanded by using multicasting and multicast addresses to contact service managers. In additions, it is possible to use the time-to-live (TTL) field in the IP header to limit the range or scope of a multicast transmission.

In their discussion about resource discovery J. Luoma and M. Tella say "It would certainly be nice if logical subnets did not limit the servers' ability to provide services. This kind of solution would make it possible to connect to networks everywhere and then just use multicast transmission to receive appropriate parameters for networking and server connections. This would enhance current Bootp or DHCP protocols quite a lot."

Corporate Information Sharing

An important part of toady's business computing environment is the sharing of information through databases rather than just traditional e-mail. This is accomplished through groupware applications such Lotus Notes, Microsoft Exchange, and Corel GroupWise. The information can be in databases scattered throughout the company or the world. Keeping the databases synchronized in all locations and updated with the most recent information is vital. All groupware users must have the same information at the same time.

In this instance IP multicasting makes it possible to use one transmission to send changes instantly to all the databases. A corporate user in Brazil, another in Finland, and yet another in the United States could all read the same information at the same time as shown in Figure 4.6. Additionally, each one could make changes to the information and all readers would be aware of the changes.

Sharing Information Though a Groupware Network

IP Multicasting Within Workgroups

Some workgroup end-users are using multicast applications to conserve LAN bandwidth and provide timely updates of information to multiple systems. We are seeing multimedia applications that can also use IP multicast services to facilitate the delivery of CD-ROM or live TV video feeds to multiple systems across the network.

Both switching and routing systems must support IP multicast capabilities for multicast applications to work in the LAN and the LAN switch must have sufficient internetworking intelligence so that it forwards multicast messages only to those workgroup segments that are part of the group.

Multimedia application use within a workgroup is a viable form of business communication when the techniques used to deliver the application reduce bandwidth and increase network manageability. The use of techniques for end-to-end resource reservation and management capabilities for IP multicast applications is particularly important when applications have high bandwidth requirements that can incur notable overhead across a network.

Multicast applications and equipment for the workgroup should support:

• RFC 1112 An IGMP that allows a host to register dynamically for the multicast sessions in which it chooses to participate and to join and quit multicast groups dynamically

• PIM, a draft IETF standard for routing. PIM gives routers the ability to dynamically locate the best path for multicast traffic and to determine which multicast group data need to be forwarded through each interface

• Resource management techniques, such as custom queuing to allow network administrators to manage the bandwidth used by multicast groups

• Security mechanisms to control the interfaces that send or receive multicast packets for multicast groups.

Benefits Check List

IP multicast benefits from a cost-effective software-based upgrade path. IP multicast does not require the use of any specialized hardware. Additional benefits from Internet multicasting include:

• Delivery of real-time information through streaming, thereby eliminating the need for downloads

• Support in current Internet infrastructure devices such as routers, switches, and operating systems

• Support for full-duplex and bidirectional interactivity

• Elimination of the need for excess bandwidth use for each additional user or site

• Conformity to open Internet standards

• Easy implementation, adaptation to multiple vertical applications and scenarios, and scaling to multiple data types such as audio, video, text, and graphics.

Introducing the Multicast Backbone

Even though the specification of IP multicasting was published in 1989, its use has been somewhat limited. A few routers that support multicasting have been available on the Internet, though this is changing slowly. Routers on the Internet tend to be replaced by multicast-capable ones only when a new router is required to replace an old one.

In the meantime, researchers wanted a resource and test bed for testing multicasting protocols and applications. They also wanted a way to enable the deployment of multicast applications without having to wait for multicast-enabled devices to be installed through the Internet. They therefore developed the Internet Multicast Backbone (Mbone). The Mbone supports routing multicast packets without disturbing or altering other Internet traffic and has been in existence for about 6 years.

The Mbone is an experimental, cooperative volunteer effort spanning several continents. It is an interconnected set of subnetworks and routers that support the delivery of IP multicast traffic. The purpose of this virtual network layered on top of the Internet is to bypass multicast-unaware routers on the Internet using tunnels. To this end, the DVMRP described in RFC 1075, has been used to build the Mbone by building tunnels between DVMRP-capable machines. The endpoints of the tunnels are entered manually in routing tables and administrated in the Mbone. Figure 4.7 describes tunneling.

Mbone Tunneling

Simply put, Mbone is constructed with tunnels across networks that do not support multicast routing. The tunnels allow multicast traffic to pass through the non-multicast-capable parts of the Internet. The Mbone usually uses encapsulated tunnels between multicast-capable islands of the Internet to move multicast data. An IP multicast packet traversing an encapsulated tunnel is characterized by its IP source and destination addresses being the IP addresses of the tunnel endpoint multicast routers. Figure 4.8 is a simplified representation of the Mbone showing the concept of multicast-capable islands.

Since the Mbone and the Internet have different topologies, multicast routers execute a separate routing protocol to decide how to forward multicast packets. Most of the Mbone routers currently use DVMRP. Some portions of the Mbone execute either MOSPF or the PIM routing protocols.

DVMRP is a protocol for routing multicast datagrams through an Internet; it implements its own unicast routing protocol in order to determine which interface leads back to the source of the data stream. This unicast routing protocol is based purely on hop counts and therefore the path the multicast traffic follows may not be the same as the path the unicast traffic follows.

Currently the IEETF, NASA, and research groups worldwide use the Mbone for research and testing of multicast protocols and services, for multicast multimedia recordings of meetings and live space events across the Internet, and for desktop conferencing. Even live concert performances have been multicast over the Mbone. The number of sites participating in the Mbone has grown rapidly. As an experimental and volunteer effort, the Mbone has limited its use in commercial environments.

Chapter 11 discusses the Mbone in detail; the Web site http://www.mbone.com sponsored by ICAST Corporation contains an Mbone reference and documentation library and links to additional information and resources.

Internet Multicast Backbone

Understanding Multicasting Capabilities

An IP multicast-capable network forwards multicast packets according to their group addresses. Network routers that support multicast keep track of which parts of the network have multicast hosts joined to particular groups. Routers forward multicast packets only to subnetworks that have IP multicast-capable hosts joined to particular groups. Multicast-capable hosts and routes have certain requirements.

Multicasting Capabilities on the Host

RFC 1112 describes the IP multicast extensions to the standard IP protocol. Three levels of conformance to this standard exist. A level 0 host has no support for IP multicasting and is not affected by multicast activity.

To provide Level 1 multicasting, a host IP implementation must support the transmission of multicast IP datagrams. At Level 1, hosts can only send multicast datagrams. Level 1 allows a host to partake of some multicast-based services, such as resource location or status reporting. A Level 1 host cannot receive multicast datagrams.

To provide Level 2 multicasting, a host must also support the receipt of multicast IP datagrams. A Level 2 host must have full support for IP multicasting. Hosts can join and leave multicast groups and receive multicast datagrams sent to group addresses. Level 2 requires implementation of IGMP and extension of the IP and local network service interfaces within the host.

A Level 1 host that can only send multicast datagrams can be useful in limited multicast-based services such as resource location.

The most important part of host IP multicast support implementation is IGMP. Both IGMP and ICMP reside in the IP layer. The purpose of IGMP is to keep neighboring multicast routers informed of the host group memberships present on a particular local network and to provide the mechanisms by which hosts and routers can join and leave IP multicast groups. The mapping of IP addresses to local network addresses is considered to be the responsibility of local network modules.

IGMP uses the reserved multicast group address 224.0.0.1 to communicate with local routers. Called the "all hosts group", this multicast group addresses all hosts in the local LAN. It is through this channel that IP multicast routers learn if any hosts are joined to a multicast group in a particular LAN. Routers send IGMP queries to this address at the local LAN and hosts respond by telling which groups they want to join.

The mapping between a Class D IP address and an Ethernet MAC-layer multicast address is obtained by placing the low-order 23 bits of the Class D address into the low-order 23 bits of IANA's reserved MAC-layer multicast address block. Mapping from a class D group address to MAC address is not one-to-one, because the high 5 bits of the Class D group address are discarded.

Multicasting Capabilities on Routers

IP multicasting is an extension of link-layer multicast to IP Internets. Using IP multicasts, a single datagram can be addressed to multiple hosts without sending it to all of them. An IP datagram sent to the group is delivered to each group member with the same best-effort delivery as that provided for unicast IP traffic.

Forwarding of IP multicast datagrams is accomplished either through static routing information or through a multicast routing protocol. Devices that forward IP multicast datagrams are called multicast routers. They may or may not also forward IP unicasts. Routers forward multicast datagrams on the basis of their source and destination addresses. An IP multicast packet traversing an encapsulated tunnel as in the Mbone is characterized by its IP source and destination addresses being the IP addresses of the tunnel endpoint multicast routers.

In response to the growing need for multimedia applications and real-time data distribution, network-layer multicast services are being built into today's high-end routers, routing hubs, and network switches. Some new routers have native multicast packet routing. Multicast-capable routers communicate with neighboring multicast routers and exchange information about group membership and network topology. However, there are many routers that cannot route multicast packets correctly.

It is important to note that in multicast routing the destination address does not specify a route to a location, but merely a transmission session. Multicast routers should forward datagrams to all participants in the session.

A host sends a multicast message out onto a host network where multicast-enabled routers pick it up and forward the message to the appropriate groups. Routers keep track of multicast groups dynamically and build distribution "trees" that chart paths from each sender to all receivers. Multicast routers must be able to execute a multicast routing protocol that defines delivery paths that enable the forwarding of multicast datagrams across an internetwork.

Routers refer to the specific tree built for a sender when they receive traffic from that sender for a multicast group. The IP standards bodies have designed several routing protocols that can build distribution trees for multicast traffic and multicast routers must support one or several of these protocols.

The current routing protocols for multicast include the:

• DVMRP, an interior gateway protocol

• MOSPF, an extension of the OSPF link-state unicast routing protocol

• PIM, that enables networks running any unicast routing protocol to support IP multicast. PIM has both dense and sparse modes.

Multicast protocols can usually be layered on top of existing multiprotocol backbones with a software upgrade to existing routing devices. Ideally, network routing devices should provide all of these standards: IGMP, DVMRP, MOSPF, and PIM, thereby allowing the widest range of multicast operations and interoperability.

The most common multicast routing protocol is DVMRP, which works by first broadcasting to all reachable multicast routers. When no members are connected to a branch, the branch is pruned from the tree as shown in Figure 4.9. The broadcast from the source can reach a router from several directions. The multicast router selects the shortest of the routes to the group members.

Pruning a Multicast Delivery Tree

Further details on multicast routing can be found in RFC 1812 and in http://www.3com.com/nsc/501303.html "Introduction to IP Multicast Routing" by Chuck Semeria and Tom Maufer.

Multicast Routing in the Internet Protocol

The Internet consists of interconnected LANs and the IP layer on top of LANs that may or may not have native multicasting support. The multicast-capable network shown in Figure 4.10 consists of LANs with native multicast support connected by IP multicast-capable routers.

IP Multicast Internet Routing

In this example, Host A can address the host group by addressing the host group's Class D address. When Host A sends the message onto its network, the multicast routers pick up the message and forward the multicast transmission to the appropriate subnets.

Each physical network can have several multicast-capable routers. Network protocols select one of them as the designated router for the network. This router then communicates with other designated routers in neighboring networks to construct a spanning tree for each multicast source. This procedure is called Reverse Path Multicasting (RPM). Datagrams from the source host to other group members travel over this spanning tree. A spanning tree has no loops and guarantees the shortest possible route to the receiver.

The copying of the message is done by the multicast method of the LANs involved. In this case all LANs support native multicasting and the multicast transmission takes the same bandwidth on host A's network as a single copy, regardless of how many clients are members of the host group on the other side of the Internet. Even if not all LANs have native multicast support, the added cost of transmitting copies will be limited to a single LAN.

Considerations When Adding Multicast Support to the IP Layer

When IP multicasting support is added to the IP layer several potential problems need to be resolved. The major issues include resolving IP multicast address to LAN (multicast) addresses, copying and forwarding of messages, and registering host group membership.

Older TCP/IP implementations are apt to have no support for sending or receiving multicast transmissions. Such an implementation discards packets addressed to multicast addresses as being corrupt or invalid.

For a host to be able to send to a multicast address, the IP protocol implementation must support a mapping from the host group address to the corresponding multicast LAN address. This mapping is analogous to ARP mappings where host group addresses are resolved to LAN addresses.

IGMP needs to be implemented so hosts who want to can join host groups and listen to multicast messages. IGMP informs local multicast routers that a host is a member of a particular multicast group.

Note the following:

• Hosts on an Internet capable of sending to a multicast address can send packets addressed to a host group address

• Processes running on hosts capable of receiving multicast packets can join host groups, after which the processes receive all transmissions sent to that host group address.

• The routing of IP multicast packets requires special functions absent in unicast IP routers.

Multicast router functions can be located on an IP host. Multicast routers forward multicast transmissions for hosts outside the LAN to the next IP multicast-capable router using a unicast tunneling method. Tunneling is the encapsulation of multicast packets using a unicast IP header between two multicast routers.

IP Multicast-Enabled Application Development

Two major types of applications rely on network layer multicast services: multimedia and information distribution applications such as those that provide real-time news to the desktop.

Most implementations of TCP/IP on major platforms support IP multicast. To develop multicast enabled application, contact platform and stack vendors for information about their programming interfaces. Some vendors also license high-level development kits that can help implement IP multicast solutions.

Multimedia Applications

Some multimedia applications are capable of streaming full-motion video, audio, and animated graphical content to the desktop. Others are real-time interactive applications, such as desktop video, collaborative engineering, and shared white boards. Multimedia applications and real-time interactive applications such a video conferencing use a great deal of bandwidth. The importance of clear picture and hi-fi quality voice should not be underestimated even in standard everyday videoconferences.

Sometimes there is a need to transmit stored data streams to very large numbers of recipients. Examples here could include updates of Web caches or corporate announcements to employees. In this case, using IP multicast-enabled applications would be beneficial and cost-effective.

IP multicast can unite collaborative workgroups and help the workplace realize the full potential of these new applications.

Information Distribution Applications

Information distribution applications benefit from the use of IP multicasting. This category of application can provide real-time news and financial services to subscribing desktop users.

Non-multimedia applications that involve the transfer of large databases of information can benefit from IP multicast. Sometimes there is a need to transmit stored data streams to very large numbers of recipients. Examples here could include updates of Web caches or corporate announcements to employees. In this case, using IP multicast-enabled applications would be beneficial and cost-effective.

Evaluation and Implementation

Many vendors of networking products now support IP multicast. Currently multicast-enabled infrastructure elements can range from routers, switches, TCP/IP stacks, network interface cards, and desktop operating system to application software. In fact, most recent network hardware and software from leading vendors is either multicast-enabled or allows upgrading to IP multicast. Vendors are usually quite willing to explain features and help determine what is required.

The IP Multicast Initiative also can provide information about IP multicast technologies, products, and services. Visit their Web page at http://www.ipmulticast.com http://www.ipmulticast.com or contact them at:

Stardust Technologies, Inc., 1901 S. Bascom Ave, #333, Campbell, CA 95008 USA.

Tel: 408-879-8080; Fax: 408-879-8081

Recommendations From the IP Multicast Initiative

• A phased approach to evaluating and deploying IP multicast including deploying IP multicast on the intranet before deploying it on the WAN

• A network analysis and user profile to determine the benefits and cost of implementing IP multicasting for a company

• Examination of several alternative plans for the deployment of multicast-based applications over a WAN and the use of transitional approaches such as tunneling

• The use of a test-bed evaluation of both LAN and WAN implementations inhouse or at a vendor's site

• Staff training in IP multicast network administration and diagnosis

• The choice of IETF standards-based products designed for native IP multicast.

The IP Multicast Initiative Web site has a technical resource center that provides more background and in-depth information.

After Deciding to Implement IP Multicasting

An organization may be a candidate to implement IP multicasting if it distributes software to a number of nodes on a regular basis and if the load on the corporate network needs to be reduced. Once the decision is made it is a good idea initially to plan groups so they are all on the local intranet or on a private network. Set up a pilot project on a single LAN to test the software and determine the bandwidth savings to expect. Try to keep the pilot project isolated from the production network. After satisfactory testing deploy IP multicasting on the production network. Make sure all routers are multicast-enabled. An organization may need to deploy IP multicast in stages, especially if the network is geographically dispersed. The use of tunneling can link the corporate LANs supporting multicasting.

A Checklist for Deploying IP Multicasting

Key points for deploying IP Multicasting include making sure that:

• The sending and receiving nodeís operating system and TCP/IP stack support multicast and the IGMP. The latest versions of UNIX, Windows NT, and Windows 95 accommodate the TCP/IP stack, IP multicasting, and IGMP.

• Each node's network adapter driver implements multicasting. Newer adapters and network drivers have built-in support for IP multicast

• Routers, bridges, and switches in the network support multicasting at the IP layer. Many new routers already support IP multicast; others may require an upgrade. Wide ranges of network equipment vendors have IP multicast-ready products

• Choose protocols carefully. Depending on the underlying routing protocol, different protocols may apply.

• Applications to be used must be multicast-enabled. Standards are being developed and incorporated into applications for enhanced services, like reliable and real-time delivery of IP multicasting traffic.

Use IP multicast upgrade and enhanced application program interfaces (APIs) available on the market to add IP multicast to applications. IP multicasting APIs include Berkeley sockets multicast API and the Winsock API for Windows applications.

Figure 4.11 summarizes the different components that must support multicasting for successful multicasting to occur between networks.

Different Components Needed for Successful Multicasting

A user does not have to upgrade to a higher bandwidth or a faster CPU as the number of multicast clients connecting to the server increases.

The IP Multicast Initiative

The IPMI)= is an international, multi-vendor forum whose purpose is to work closely with the IETF on IP multicast standards and to accelerate the adoption of those standards. Membership in the forum provides leading-edge technology, and marketing and business information for participating companies.

IPMI's Web site is a comprehensive resource of IP multicast information and services including an IP multicast technical resource center, a series of white papers, and a comprehensive products and services directory. The site also has information about the IPMI special Internet Multicast Channel (IMC) project that is a prototype Internet "broadcast" network. IPMI also runs seminars and IP multicast interoperability invitational events. The Web site also offers a list of members of the IP Multicast Initiative who can be contacted for information and assistance.

Visit the IPMI Web site at http://www.ipmi.com

The Initiative and its services are managed and provided by Stardust Technologies, Inc. See their Web site at http://www.stardust.com for detailed information about Stardust. You can also reach IPMI at:

Stardust Forums, Inc., 1901 S. Bascom Ave. Suite 333, Campbell, CA 95008;

Tel: 408-879-8080 Fax: 408-879-8081

Security and IP Multicasting

Security issues in IP multicast tend to revolve around the applications in use. For example, it is conceivable that an application program could run code from an attacker that it received from a multicast stream and placed unchecked in a buffer.

Privacy might be an issue with a video conferencing application. Here a secret key that encrypts the session data might be the answer. However, providing security services for multicast, such as traffic integrity, authentication, and confidentiality, is particularly problematic since it requires securely distributing a group (session) key to each of a group's receivers. Traditional key distribution techniques do not work well for wide-area multicasting, where group members may be widely distributed across the Internet, and a wide-area group may be densely populated.

RFC 1949 defines an experimental protocol to provide a scalable solution to multicast key distribution. This proposal requires some simple support mechanisms to be integrated into IGMP.

If part of the network traverses the Internet, firewalls may have to be reconfigured to allow IP multicast traffic through. Alternatively, a tunnel could be used. Researchers and firewall vendors are currently working on ways to deal with IP multicast.

Differences Between IPv4 and IPv6 Multicast Addressing

IPng, the next generation of the IP protocol, fully supports IP multicast. As IPng, also called IPv6, becomes implemented in nodes connected to the Internet, multicasting will be integrated. Its use will no longer be limited to local networks and experimental Internet implementations. IPv6 is the preferred way to refer to the new protocol.

IPv6 reserves a range of addresses for multicast that is substantially larger than the address space of the current IPv4 Class D multicast service. The address space in IPv6 is 128 bits. The IPv6 protocol allocates a fraction of 1/256 from this address space to multicast addresses.

IPv6 multicast addresses have the format shown in Figure 4.12. A multicast address can be assigned to a single system, restricted to a specific site, associated with a particular network link, or distributed worldwide. Multicast addresses must not be used as source addresses in IPv6 datagrams or appear in any routing header. A value of FF (11111111) identifies an address as a multicast address. The IPv6 multicast address has three other fields, the Flgs field, Scop field, and the Group ID field.

Multicast Address Format

The low-order bit of Flags indicates permanently or non-permanently-assigned multicast address. Other flag bits are zero. The Scope field limits the scope of the multicast group. Possible scope values include node-local, link-local, site-local, organization-local, and global. Non-permanently-assigned multicast addresses are meaningful only within a given scope.

Mapping of IPv6 multicast addresses to Ethernet MAC addresses is similar to IPv4 mapping, but the low-order 32 bits of group addresses are mapped to MAC address instead of the low-order 23 bits as in the IPv4 specification.

For more information about IPv6 and Ethernet networks see RFC 1972, M. Crawford, "A Method for the Transmission of IPv6 Packets over Ethernet Networks", August 1996.

Backward Forward
Chapter: Preface | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.
Beta Books | Beta Bookstores | Computing McGraw-Hill

Professional Publishing Home | Contact Us | Customer Service | For Authors | International Offices | New Book Alert | Search Catalog/Order | Site Map | What's New

A Division of the McGraw-Hill Companies
Copyright © 1998 The McGraw-Hill Companies, Inc. All rights reserved. Any use is subject to the Terms of Use the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers.


Marcus Goncalves
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Chapter Five

Multicast Operation

The rapidly advancing development of networked multimedia applications will significantly affect users and has the potential of revolutionizing and restructuring computer networking and the industry as a whole. Many of these emerging Internet applications are one-to-many or many-to-many multicast-based applications as are numerous information distribution services that provide real-time news, finance, and securities data to subscribers' desktops through Internet connections.

Today, a wide variety of companies such as Toys `R Us and General Motors are using multicast applications to provide software updates, file transfers, and on-demand sales and service information to their stores and dealerships.

This chapter discusses the requirements for IP multicast delivery and provides a:

• Summary of network requirements as they pertain to IP multicast and multimedia applications

• Brief introduction to the relationships between Layer 3 and Layer 2 stitching and IP multicasting

• Discussion about multicast addressing including well-known multicast addresses, Layer 3 to Layer 2 address mapping, and a summary of IPv6 multicast addressing

• Summary of multicast forwarding methods

• Brief description of time-to-live (TTL) and quality of service (QoS) issues as they pertain to multicasting.

A Quick Description

With multicasting, the recipient joins a multicast session group. The source sends a single message to a group address and the network infrastructure delivers the traffic to all members of that group. If the path diverges at a router, then and only then is a copy of the message made. The source does not need to send multiple copies of the message.

The client makes the decision whether or not to listen to the multicast address. This is analogous to a person turning on a radio and selecting a particular station. In a multicast environment, the server needs to send only one video stream to a multicast address; any number of clients can listen to the multicast address and receive the data stream. Multicasting is helpful in controlling network traffic and reducing network and host processing by eliminating traffic redundancy. Figure 5.1 shows an example of a multicast transmission and, for comparison, includes an example of both unicast and broadcast transmissions.

Example of a Multicast Transmission

Multicast transmission can be implemented at both the data-link layer (Layer 2) and the network layer (Layer 3). It can also run over various media types including Ethernet, FDDI, and ATM.

An individual computer can listen to a unicast address, several multicast addresses, and the broadcast address. Implementing multicasting at the network layer in a campus environment allows traffic to be sent only to those segments that request the traffic.

A host machine running the IGMP reports membership activity, such as joining or leaving a group, to the network router. The router uses the information selectively to forward data to the network where the relevant host machine resides. This reduces the bandwidth required for multi-destination data delivery.

Most major router vendors support IP multicast routing. Networks that do not support IP multicast transport multicast packets through a multicast tunnel which encapsulates IP multicast frames within regular IP frames.

Multicast Requirements

All levels of the multimedia industry and information distribution services place delivery requirements on a network and the network's infrastructure. Any multimedia or data distribution application that requires point-to-multipoint transmission can benefit from network-layer multicast services.

Industry Needs

Different segments of the multimedia and information distribution service industries provide content, applications, platforms, and networking infrastructure. These segments form a hierarchy as shown in Figure 5.2, while Table 5.1 shows the function they perform.

Segments of the Multimedia and Information Distribution Service Industries

Multimedia and Information Distribution Service Industry Segments

Industry Segment Uses the network and multicasting to

Content Providers deliver content to subscribers and customers. The news, television, and entertainment industries are examples of content providers.

Application Developers create real-time data distribution applications, multimedia applications, and network applications based on multicasting for efficient delivery.

Platform and Network Developers create the hardware, firmware, and protocols required for maintaining and supporting multicasting. Network-layer multicast services are being built into today's high-end routers, routing hubs, and network switches in response to the growing need for multimedia applications and real-time data distribution.

Network infrastructure providers deliver network services such as ATM and ISDN and provide the underlying private public network infrastructures that support the use of multicasting.

In the past, data, voice, video, and other real-time services each ran on their own networks in parallel with the internetwork backbone.

Current multicast applications might include distance learning, desktop videoconferencing, and certain groupware applications. Multicast desktop videoconferencing allows arbitrary groups of users to solve business problems, and desktop video training is a form of distance learning that can increase the power of corporate, school, and home school education programs.

Today organizations are using videoconferencing, voice communications, cable TV and other specialized services that without multicasting might require their own networks (see Figure 5.3).

Commercial and educational researchers are extensively evaluating and developing multipoint protocols. Currently, the IP community is focusing significant effort on techniques for IP multicast routing. Most new protocols can be layered on top of existing multiprotocol backbones; usually of software upgrades of upgrading routing devices. IP multicast enables more precise routing of multicast traffic, a characteristic that reduces network congestion and improves security.

Multicast is an important factor in a multiservice network, as is high-performance network hardware and QoS transport.

Integrated Multiservice Network

Network Requirements to Support Multicasting

IP multicasting provides an efficient, multipoint, Layer 3 transport mechanism for delivering audio, video, and data to networked devices. In a multiservice high-performance network hardware is an important dimension, as are sufficient bandwidth, consistent QoS transport, and multicast message delivery.

Bandwidth

Applications require varying amounts of bandwidth. The frame size, frame rate, encoding scheme, and compression scheme the application uses all influence the bandwidth requirements. Frame size most strongly affects bandwidth. The video-encoding scheme used can affect frame size, rate, and quality of image. Older video encoding schemes can be hardware-based while newer ones tend to use software-based encoding. Several environments might need additional bandwidth. In all cases, using IP multicasting would help preserve bandwidth.

A LAN segment that carries numerous Individual desktops running multiservice applications may need additional bandwidth. This could be accomplished by further segmenting the LAN so there are fewer users on each segment. A multicast-enabled LAN switch might be useful in this environment. Adding high-speed servers might also be required.

A campus or workgroup backbone running multiservice applications typically needs more bandwidth. FDDI provides 100 Mbps and some backbones are using ATM networks to achieve the needed bandwidth.

A WAN is usually a candidate for extra bandwidth; WAN services typically run over a public network infrastructure which can make bandwidth expensive.

Quality of Service

Business has an economic need to merge multiple independent networks. Running separate data, telephone, and perhaps teleconferencing, networks is expensive. Applications in a multiservice environment, such as data, voice, and video have different QoS requirements.

For example, delivery of real-time multiservice applications such as videoconferencing must be on time or it becomes useless. Without proper planning and configuration in a multiservice environment other traffic can consume all the available bandwidth; there would not be enough bandwidth to allow consistent quality of service for the multiservice applications.

QoS provides network services differentiated by their level of security, bandwidth, delay, jitter, error rates, cost, compression, and other parameters. Currently, there is a great deal of work under way on the protocols and products that make internetwork QoS possible. Sections at the end of this chapter discuss some of these QoS parameters.

Multicast Message Delivery

Multicast message delivery is useful when an application involves two or more participants, as in video conferencing sessions. For multicasting to function properly, computers and other devices on the network need to know which computers and devices are to receive multicast traffic and how to build paths to multicast destinations.

A number of protocols enable multicast routing:

• RFC 1112 "Host Extensions for IP Multicasting" includes the IGMP protocol that allows a computer to inform the network that it is a member of a multicast group

• RFC 2117 "Protocol-Independent Multicast - Sparse Mode (PIM-SM) Protocol Specification" is a router-to-router protocol that supports multicast traffic over existing unicast routing protocols. PIM-SM is designed to provide scalable interdomain multicast routing across the Internet

• Protocol-Independent Multicast ñ Dense Mode (PIM-PIM) is currently an Internet draft multicast routing algorithm for multicast groups that are densely distributed across an Internet.

IPv4 Multicast Addressing

Multicasting is a valuable tool for networking including Layer 2 switching, point-to-multipoint transmissions and router-to-router communications. Layer 3-to-Layer 2 translation, dynamic membership control, and multicast-aware routing are important parts of IP multicasting. Layer 2 switching provides scalable bandwidth for end users and servers, and IP multicasting provides an efficient, multipoint, Layer 3 transport mechanism for delivering audio, video, and data to networked devices.

All network protocols need a method to translate the IP network address ISO/OSI Layer 3 into a hardware/media address (Layer 2), such as an Ethernet MAC address.

The set of receiving nodes that defines a multicast group receives a multicast address. Senders use the multicast address as the destination IP address of a packet to be transmitted to all group members.

A majority of the TCP/IP stack and router vendors have adopted the IP multicast IETF standard. IP multicast uses class D IP addresses, which provide for group communication.

An IP multicast group address represents a selected subset of all hosts. A message sender sends only one message packet to the group. The routers in the internetwork provide intelligent forwarding of those packets to all of the recipients in the group, but not to other hosts outside the group.

IPv4 Addressing Architecture

In an IPv4 implementation, each physical network and host has its own unique network address. Routers or gateways can have one or more addresses depending on the number of interfaces present. IP addresses consist of a 32-bit value usually presented in decimal dot notation consisting of 4 octets (bytes) separated by a dot; for example 172.16.10.0.

There are three fundamental types of IPv4 addresses: unicast, broadcast, and multicast. A unicast address transmits a packet to a single destination. A broadcast address sends a datagram to an entire subnetwork. A multicast address enables the delivery of datagrams to a set of hosts configured as members of a multicast group in various scattered subnetworks.

IPv4 Address Classes

IPv4 recognizes three kinds of unicast addresses classes, A, B, and C, that identify a specific network interface addresses. IPv4 also two specialized address classes: D and E.

Rather than being assigned to a specific interface, a Class D address identifies the members of a logical group of interfaces. All logical holders of a particular Class D address receive packets sent to that address.

Basically, the only difference between a multicast IP packet and a unicast IP packet is the presence of a group address, a Class D destination address format (224.0.0.0- 239.255.255.255) in the Destination Address field of the IP header.

The IANA reserves Class E addresses for future and experimental uses. Table 5.2 shows the five forms of IPv4 addresses.

Five IPv4 Address Types

Address type Consists of With an address range of

Class A 126 networks, each can have up to (16M-2) nodes 1.0.0.0 - 126.0.0.0

Class B (16K-2) networks, each can have up to (64K-2) nodes. 127.0.0.0 - 191.255.0.0

Class C (2M-2) networks, each can have up to 254 nodes. 192.0.0.0 - 223.255.255.0

Class D A multicast address 224.0.0.0 - 240.0.0.0)

Class E Reserved for future use 241.0.0.0 - 248.0.0.0

Each class of IPv4 addresses consists of two parts: a network identifier portion and a host or node identifier portion as shown in Figure 5.4. In this example the binary address 10000000 00000111 00001111 00000001 has the decimal dot notation of 128.7.15.1. This is a Class B address with the network ID of 128.7.

Special forms of Internet addresses include the following:

• 0.0.0.0 indicates this host

• 0.host-number indicates this host on this net

• 255.255.255.255 indicates limited broadcast to the local net

• Net-number.255 indicates directed broadcast for the specified net

• 127.anything indicates the loopback internal in the host. This should never appear on the network.

Five Forms of IPv4 Addresses

IPv4 Subnetting

Subnetting is a technique of assigning addresses so that a single IP network address can span multiple physical networks. Subnetting uses some of the bits of the host-ID part of the IP address as a physical network identifier. The subnet mask determines the bits of the network identifier. With subnetting, the network ID and host ID division changes to network ID, subnetwork ID, and host ID. The subnet field takes the space that it needs by reducing the host ID field. Individual organization assign the subnet ID and the identifiers for the host on each subnet.

A subnet masks differentiates between various subnets. It is a 32-bit number with all ones in the network ID and subnetwork ID fields and all zeros in the host ID field. A host uses a logical AND function on a subnetwork mask to a particular address to determine if it can deliver the datagram to a host on the current subnet or if it must send the datagram to a router for delivery.

Figure 5.5 shows division of a single Class B network into two subnetworks. In this example, all gateways except Gateway A route as if there were a single physical network. Gateway A is physically interconnected between the networks.

A Class B Network Divided in to Two Subnetworks

Impact of Multicast Addressing

The introduction of multicast addressing with RFC 1112 expanded the meaning of IP addresses to include source and destination addresses. A multicast destination address is a locator for a group of hosts that can be topographically separated over a wide area. A multicast destination address lifetime can be short. In addition, a multicast destination address can traverse a network address translator (NAT), and is not necessarily restricted to an intranet or to the Internet.

Broadcast and Multicast in IPv4

Broadcast is a special case of multicast where every host on the networks belongs to the same multicast group. Broadcast protocols have the following important limitations:

• Indiscriminate delivery–This means that every host on the network receives all packets. This is inefficient and delivers packets to hosts who do not need them

• Unreliable–This means that there is no standard, reliable delivery protocol that works with broadcast packets

• Limited to the local network–This means that broadcast protocols work only on the local network and networks that are bridged to one other. Large networks, such as the Internet, cannot handle broadcast transmissions.

Layer 3 Multicasting

Layer 3 can send unicast, multicast, and broadcast data. All hosts on a subnet read Layer 3 broadcasts. Routers typically confine these broadcasts to the subnet and stop them from propagating across the Internet. Layer 3 multicasts have a special status. Multicast-capable routers can propagate Layer 3 multicasts to a group of receivers who can be located on any number of subnets or anywhere on the global Internet.

Class D Address Format

Figure 5.6 shows the format of a Class D IP multicast address. Each address can be considered a channel by which groups of hosts interested in receiving the same content can be identified. Class D addresses have their high-order 4 bits set to 1110 followed by the 28-bit multiclass ID. Note that the last 28 bits of a Class D address contain the multicast group ID and have no further structure. This differs from the properties of Class A, B, and C IP addresses.

Class D host group addresses are typically written in standard dotted decimal notation with group addresses ranging from 224.0.0.0 to 239.255.255.255. The high-order bits of 1110 yield the 224 base address.

The address 224.0.0.0 is reserved and is not to be assigned to any group. 224.0.0.1 is assigned to the permanent group of all IP hosts (including gateways).

Multicast Class D Address Format

A host group consists of the set of hosts listening to a particular IP multicast address. Members of a host group can be on multiple networks. Membership in a group is dynamic and hosts can join and leave host groups. An IP host group address is dynamically bound to a set of local network interfaces on a set of IP networks.

Class D Address Ranges

There are two types of group addresses, permanent and temporary. The IANA assigns the permanent addresses and maintains a list of registered IP multicast groups. Of the well-known addresses, two are 224.0.0.1 and 224.0.0.2. The first is the all-hosts group used to address all IP Multicast hosts on the directly connected network. The second is the address for all the routers on a subnet.

The Class D multicast address block is divided into ranges as shown in Figure 5.7.

Class D Multicast Addressing

The address 224.0.0.0 is reserved and cannot be assigned to any group. The IANA reserves the block of multicast addresses ranging from 224.0.0.1 to 224.0.0.255 for routing protocols and other low-level topology discovery or maintenance protocols. The middle range, 224.0.1.0 to 238.255.255.255 is for use by multicast end-user applications within groups, intranets, and the Internet. The upper range of the Class D address set, 239.0.0.0 to 239.255.255.255, is designated for locally administered or site-specific multicast applications

Well-Known Multicast Addresses

RFC 1112 "Host Extensions for IP Multicasting" specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Table 5.3 lists current Internet multicast well-known addresses:

Some Well-Known Class D Addresses

Well-Known Class D Address Purpose

224.0.0.0 Base Address (Reserved) (RFC1112)

224.0.0.1 All Systems on this Subnet (RFC1112)

224.0.0.2 All Routers on this Subnet

224.0.0.3 Unassigned

224.0.0.4 DVMRP Routers (RFC1075)

224.0.0.5 OSPFIGP All Routers (RFC1583)

224.0.0.6 OSPFIGP Designated Routers (RFC1583)

224.0.0.7 ST Routers (RFC1190)

224.0.0.8 ST Hosts (RFC1190)

224.0.0.9 RIP2 Routers

224.0.0.10 IGRP Routers

224.0.0.11 Mobile-Agents

224.0.0.12-224.0.0.255 Unassigned

224.0.1.0 VMTP Managers Group (RFC1045)

224.0.1.1 NTP--Network Time Protocol (RFC1119)

224.0.1.2 SGI-Dogfight

224.0.1.3 Rwhod

224.0.1.4 VNP

224.0.1.5 Artificial Horizons ñ Aviator

224.0.1.6 NSS - Name Service Server

224.0.1.7 AUDIONEWS - Audio News Multicast

224.0.1.8 SUN NIS+ Information Service

224.0.1.9 MTP Multicast Transport Protocol

224.0.1.10 IETF-1-LOW-AUDIO

224.0.1.11 IETF-1-AUDIO

224.0.1.12 IETF-1-VIDEO

224.0.1.13 IETF-2-LOW-AUDIO

224.0.1.14 IETF-2-AUDIO

224.0.1.15 IETF-2-VIDEO

224.0.1.16 MUSIC-SERVICE

224.0.1.17 SEANET-TELEMETRY

224.0.1.18 SEANET-IMAGE

224.0.1.19 MLOADD

224.0.1.20 Any private experiment

224.0.1.21 DVMRP on MOSPF

224.0.1.22 SVRLOC

224.0.1.23 hgxing@aol.com>

224.0.1.24 microsoft-ds

224.0.1.25 nbc-pro

224.0.1.26 nbc-pfn

224.0.1.27-224.0.1.255 Unassigned

224.0.2.1 rwho Group (BSD) (unofficial)

224.0.2.2 SUN RPC PMAPPROC_CALLIT

224.0.3.000-224.0.3.255 RFE Generic Service

224.0.4.000-224.0.4.255 RFE Individual Conferences

224.0.5.000-224.0.5.127 CDPD Groups

224.0.5.128-224.0.5.255 Unassigned

224.0.6.000-224.0.6.127 Cornell ISIS Project

224.0.6.128-224.0.6.255 Unassigned

224.1.0.0-224.1.255.255 ST Multicast Groups (RFC1190)

224.2.0.0-224.2.255.255 Multimedia Conference Calls

224.252.0.0-224.255.255.255 DIS transient groups

232.0.0.0-232.255.255.255 VMTP transient groups (RFC1045)

When used on an Ethernet or IEEE 802 network, the 23 low-order bits of the IP Multicast address are placed in the low-order 23 bits of the Ethernet or IEEE 802 net multicast address 1.0.94.0.0.0.

Layer 3-to-Layer 2 Translation

Multicast network protocols need a method to map a Class D address into a hardware/media address such as an Ethernet MAC address.

The IANA owns a reserved portion of the IEEE-802 MAC-layer multicast address space in addition to the reserved Class D addresses. All of these Ethernet addresses in the reserved block begin with hexadecimal 01-00-5E. This block includes addresses 00:00:5e:00:00:00 through 00:00:5e:ff:ff:ff. Half this block is for multicast addresses. Ethernet addresses corresponding to IP multicasting are in the range 01:00:5e:00:00:00 through 01:00:5e:7f:ff:ff.

Layer 3-to-Layer 2 Mapping Technique

Mapping Class D addresses to the IANA reserved address block is relatively simple, as shown in Figure 5.8 which maps the multicast group address 224.10.8.5 (E0-0A-08-05) into an Ethernet (IEEE-802) multicast address by placing the low-order 23 bits of the Class D address into the low-order 23 bits of IANA's reserved address block. This allows IP multicasting to use the hardware-level multicast support provided by many network interface cards.

Mapping Between Class D and IEEE-802 Multicast Addresses

Note that this mapping is not unique because it ignores the upper five bits of the IP multicast group address. The device driver or the IP modules must perform filtering, since the interface card can receive multicast frames the host does not really want. Thirty-two different multicast group IDs map to each Ethernet address ID. For example, the multicast addresses 224.138.8.5 (E0-8A-08-05) and 225.10.8.5 (E1-0A-08-05) would also map to the Ethernet address (01-00-5E-0A-08-05) in this figure.

The TCP/IP stacks on machines must be IP multicast-aware to understand the significance of this special range of IP addresses and to program a network adapter properly to receive requested multicast addresses.

End-node hosts need network interface cards that efficiently filter for LAN data-link layer addresses mapped from network-layer IP multicast addresses.

Multicast Filtering Switch

An IP multicast-aware layer filtering switch provides the same benefits as a multicast router, but in the local area. Such a switch can automatically set up multicast filters so the multicast traffic is only directed to the participating end nodes. Without one, the multicast traffic is sent to all segments on the local subnet.

Switching is the process of taking an incoming frame from one interface and delivering it out through another interface. The interface the frame is sent out on depends on the destination MAC address of the frame (see Figure 5.9).

Layer 2 Destination Address

Transmission and Delivery of Multicast Datagrams

To send an IP multicast datagram, the sender specifies an appropriate destination address, which represents a host group. The source host sends the IP multicast datagrams using the same Send IP operation used for unicast datagrams. If both the sender and receivers are on the same subnetwork:

• The source addresses the IP packet to the multicast group

• The network interface card device drivers map the Class D address to the corresponding IEEE-802 multicast address and forward the frame to group members

• Each node wanting to receive the frame notifies its IP layer that it wants to receive datagrams addressed to the group.

When the sender is attached to one subnetwork and receivers reside on different subnetworks the message passes through routers and additional steps are required. The routers are required to:

• Implement a multicast routing protocol that permits the construction of multicast delivery trees

• Support multicast data packet forwarding

• Implement a group membership protocol such as IGMP that permits the router to learn about the existence of group member on its attached subnetwork.

IPv6 Multicast Addressing

The address space in IPv6 is 128 bits. The IPv6 protocol allocates a fraction of 1/256 from this address space to multicast addresses.

IPv6 multicast addresses have the format shown in Figure 5.10. A multicast address can be assigned to a single system, restricted to a specific site, associated with a particular network link, or distributed worldwide. Multicast addresses must not be used as source addresses in IPv6 datagrams or appear in any routing header.

IPv6 Multicast Address Format

A value of FF (11111111) identifies an address as a multicast address. The IPv6 multicast address has three other fields, the Flgs field, Scop field, and Group ID field.

The Flgs field consists of four flags. The high-order three flags should always initialize to 0 and are reserved.

• The T flag when set to 0 indicates a permanently assigned multicast address. Such an address is called a well-known multicast address. The global Internet numbering authority assigns the well-known multicast addresses.

• The T flag when set to 1 indicates a non-permanently assigned multicast address. Such an address is known as a transient multicast address.

The Scop value limits the scope of the multicast group. Table 5.4 lists the settings for this 4-bit multicast scope value.

The group ID identifies the multicast group within the scope. The group can be either a permanent multicast group or a transient multicast group.

IPv6 Multicast Scope Values

Value Description

0 reserved

1 node-local scope

2 link-local scope

3 (unassigned)

4 (unassigned)

5 site-local scope

6 (unassigned)

7 (unassigned)

8 organization-local scope

9 (unassigned)

A (unassigned)

B (unassigned)

C (unassigned)

D (unassigned)

E global scope

F reserved

Non-Permanently and Permanently Assigned Multicast Addresses

Non-permanently assigned multicast addresses (transient multicast addresses) have meaning only within a given scope. A group at one site using a non-permanent site-local address multicast address has no relationship to a:

• Group at a different site that is using the same address

• Nonpermanent group with the same group ID but is using a different scope

• Permanent group that has the same group ID.

A permanently assigned multicast address is independent of the scope value. Table 5.5 shows the effect of assigning an NTP servers group a permanent multicast address with a group ID of 43 (hex).

Example of Permanently Assigned Multicast Address Meanings

Address Means all NTP servers

FF01:0:0:0:0:0:0:43 On the same node as the sender

FF02:0:0:0:0:0:0:43 On the same link as the sender

FF05:0:0:0:0:0:0:43 At the same site as the sender

FF0E:0:0:0:0:0:0:43 In the internet

Predefined Well-Known Multicast Addresses

Table 5.6 lists the predefined well-known multicast address types and addresses.

The solicited-node multicast address consists of the low-order 32-bits of the address appended to the 96-bit prefix FF02:0:0:0:0:1. This produces a multicast address in the range in the range FF02:0:0:0:0:1:0000:0000 to FF02:0:0:0:0:1:FFFF:FFFF. For example, the solicited node multicast address corresponding to the IPv6 address 4037::01:800:200E:8C6C is FF02::1:200E:8C6C.

IPv6 addresses that differ only in the high-order bits map to the same solicited-node address. This reduces the number of multicast addresses a node must join.

An IPv6 node is required to compute and support a solicited-node multicast address for every unicast and anycast address it is assigned.

Some Predefined Multicast Addresses

Well-known multicast address type Address

Reserved multicast addresses

These addresses will never be assigned to any multicast group FF00:0:0:0:0:0:0:0

FF01:0:0:0:0:0:0:0

FF02:0:0:0:0:0:0:0

FF03:0:0:0:0:0:0:0

FF04:0:0:0:0:0:0:0

FF05:0:0:0:0:0:0:0

FF06:0:0:0:0:0:0:0

FF07:0:0:0:0:0:0:0 FF08:0:0:0:0:0:0:0

FF09:0:0:0:0:0:0:0

FF0A:0:0:0:0:0:0:0

FF0B:0:0:0:0:0:0:0

FF0C:0:0:0:0:0:0:0

FF0D:0:0:0:0:0:0:0

FF0E:0:0:0:0:0:0:0

FF0F:0:0:0:0:0:0:0

All node addresses

These identify the group of all IPv6 nodes within scope 1 or 2. FF01:0:0:0:0:0:0:1

(scope 1 node-local) FF02:0:0:0:0:0:0:1

(scope 2 link-local)

All router addresses

These identify the group of all IPv6 routers within Scope 1 or 2. FF01:0:0:0:0:0:0:2

(scope 1 node-local) FF02:0:0:0:0:0:0:2

(scope 2 link-local)

DHCP Server/Relay-Agent

These identify the group of all IPv6 DHCP servers and relay agents within Scope 2. FF02:0:0:0:0:0:0:C

(link-local)

Solicited-node addresses

are computed as functions of a node's unicast and anycast addresses. FF02:0:0:0:0:1:XXXX:XXXX

Building a Multicast Group

Source hosts for a multicast group are generally audio, video, financial, news, or assorted other multimedia serves that stream data into the network. The network administrator or an automated application assigns a Class D multicast address to the server application and all its members. From then on, all servers interacting with the application address their packets to the group's address.

II a receiver wants to join a multicast group, it begins by sending an IGMP message to its local subnet. This message contains the Class D address of the group to which the receiver wants to belong. The local multicast-capable router receives the IGMP message.

RFC 1112 defines IGMP, the IETF standard for multicast registration. IGMP specifies how the host is to inform the network that it is a member of a particular multicast group.

A multicast-capable router must be present in every subnet that contains multicast receivers. One of the functions of this router is to give receivers on its attached subnets access to the multicast delivery system. After the router receives the IGMP message from the receiver, it forwards all multicast traffic for the target group to the receiver's subnet (see Figure 5.11).

Relationship of Multicast Groups and Routing Protocols

Individual hosts are free to join or leave a multicast group at any time. There can be any number of members in a multicast group and those members can be located anywhere in the Internet. A host can be a member of more than one multicast group at any given time. A host that is a member of a multicast group can receive messages from a host that is not a member of that group or of any group.

IGMP is a two-way protocol. Routers use IGMP to learn about the presence of group members on their directly attached subnetworks. Upon joining a multicast group, a host:

• Transmits a group membership protocol message for the group(s) from which it wishes to receive

• Sets its IP process and network interface card to receive frames addressed to the multicast group.

As the multicast group membership increases in size, the likelihood increases of a new group member being able to locate a nearby branch of the multicast distribution tree.

If the group member hosts on a subnet fail to respond to IGMP messages from the route, the router removes the subnet from the delivery path. This process, referred to as pruning, ensures that multicast traffic goes only to subnets where there are group members.

A host can belong to more than one multicast group. Such a host can respond to a router's IGMP query with the Class D addresses of several groups.

Figure 5.12 shows a host that is a member of Group 1 (G1) and Group 2 G2). When a host is a member of multiple groups it can receive multicast datagrams from all the groups simultaneously or at different times. However, sufficient resources and network bandwidth need to be present for a host to receive simultaneous group transmissions from several groups.

Host in Multiple Multicast Groups

IGMP Version 2 or higher permits:

• Routers to send group specific messages requesting a response from the group members

• Receivers to send a Leave Group message to the router requesting immediate removal from a group's membership.

In the future it may be possible for a receiving host to request multicast traffic from specific sources within a group.

Overview of Multicast Forwarding Methods

There are several methods to forward IP multicast traffic from the source hosts to receivers. The first step is to map a group of sources and receive hosts to a common Class D address. So there is efficient delivery of multicast traffic, the next step involves defining a set of multicast delivery paths for routers to use. To accomplish this routers need to talk to each other using a network layer multicast routing protocol that allows them to build a multicast delivery tree. This involves calculating a set of paths for the multicast packet to travel that go only to those subnets with group members (see Figure 5.13).

Multicast Delivery Tree

Routers must relay multicast packets from remote sources. Protocol software is built into routers to help build multicast delivery trees for forwarding packets. Major multicast forwarding protocols use one of two techniques as shown in Table 5.7:

Multicast Forwarding Techniques and Corresponding Routing Protocols

Forwarding Technique Routing Protocols

Source-Rooted Trees Distance Vector Multicast Routing Protocol (DVMRP) and Multicast Open Shortest Path First (MOSPF)

Shared Trees Core Based Trees (CBT) and Protocol Independent Multicast (PIM)

Source-Rooted Tree Protocols

SRT protocols reside in multicast-capable routers. They build a tree for each multicast source within a group, connecting the source to all the receiving members of the group. If a group has seven source hosts then the source-rooted tree protocol builds seven distinct delivery trees.

An SRT path makes a direct connection from the particular multicast source to the downstream members and is often referred to as a "source-rooted shortest-path tree." These paths do not pass through a central multicast server (see Figure 5.14). After the protocol builds this source root tree, the multicast source forwards all multicast traffic for a session along this path to its receivers.

Source-Rooted Shortest Path Trees

Different protocols use different routing metrics such as hops, delay, or cost to determine the shortest path between a source and its receivers. Source-rooted tree protocols typically determine the shortest tree between a source and its receivers using hops as the metric. The shortest multicast path might not always be identical to the shortest physical path through the unicast topology. This might be true where a mix exists of multicast-capable routers and unicast-only routers that a multicast tree ignores. In this case the shortest multicast path might have more hops than the shortest unicast path.

Routers use multicast routing protocols such as DVMRP and MOSPF to build source-rooted shortest-path trees.

DVMRP typically uses tunneling mechanisms and the Mbone uses its source-rooted approach. MOSPF is best suited for environments that have relatively few source/group pairs active at any given time.

Efficient of routing multicast traffic is a complex problem and new techniques and protocols have been developed to address the problem. Chapter 7 describes the DVMRP and MOSPF protocols in some detail.

Shared Trees

The shared-rooted tree method of forwarding is the most dominant form of multicast delivery. However, the shared-tree method of forwarding is a better choice than the shared-rooted tree method when a multicast environment involves sparsely populated multicast groups that may have low-grade network connections.

The shared-tree method uses a central multicast router, sometimes referred to as a core router. Multicast source hosts send their multicast packets to this core router, which in turn forwards the packets through a common shared tree to the members of the group. A shared-tree approach used a single tree between all sources and group members (see Figure 5.15).

Shared-Tree Path

A shared-tree approach to forwarding places less demand on routers and network bandwidth as it builds the tree than does a source-rooted tree approach. Both the CBT protocol and the PIM Sparse Mode protocol use the shared-tree method of forwarding.

Chapter 7 describes the CBT and PIM protocols in some detail.

Time-to-Live Setting

Each IP multicast datagram contains an IP header, which in turn has a TTL field. The value in the TTL field of the IP header controls the scope of an IP multicast transmission. The TTL value controls the metric that an IP multicast packet is allowed to propagate and controls whether packets are forwarded out of an interface (see Figure 5.16). These place a regional scope on the propagation of the packet through internetworking routers.

Generally, a system administrator or programmer specifies the TTL value in hops. Only multicast packets with a TTL greater than the interface TTL threshold are forwarded on the interface.

IPv4 Header Format with Time-to-Live Field

The time-to-live field contains a value indicating the maximum amount of time the datagram is allowed to remain in the Internet system. The TTL can be measured either in router hops or in units of seconds. When this field contains the value zero, the datagram is destroyed. The TTL field is modified in Internet header processing. Each module that processes the Internet header decreases the TTL by at least one. This field uses 8 bits.

Protocols restrict a multicast datagram with an initial TTL of 0 to the same host. By default, multicast datagrams are sent with a TTL set to 1. This restricts the datagram to the same subnet.

Multicast-capable routers can forward datagrams with TTLs higher than 1. In this case, multicast routers attached to the local network take responsibility for forwarding the datagram to the Internet or branches of the intranet. Each time a multicast-capable router forwards a multicast datagram, it decreases the TTL value (number of hops) by 1. If the TTL reaches zero (0), the router drops the datagram. This prevents the datagram from being forwarded to regions of the Internet that do not contain multicast group members.

When the TTL is greater than 1, routers forward the datagram to other networks to which group members belong. A multicast router on the network completes the delivery of the datagram as though it were a locally transmitted multicast datagram.

The Mbone has several standard settings for TTL: 1 for local net, 15 for site, 63 for region and 127 for world.

Some applications can increase the TTL to perform an expanding search to locate the nearest network with attached multicast group members. The application sends the first multicast datagram with a TTL of 1. It then tries a TTL of 2 if it receives no reply to its first datagram. The application repeats this process by setting the TTL to 3 and so on until the application locates the closest network with attached group members.

It is possible to confine multicast traffic within an enterprise network and prevent multicast datagrams from traversing certain subnets. Some multicast routers allow the system administrator to set the TTL thresholds to less than a specified TTL.

The special range of addresses 224.0.0.0 through 224.0.0.255 is intended for applications that never need to multicast farther than one hop. A multicast router should never forward a datagram with one of these addresses as the destination, regardless of the TTL.

Role of Quality of Service, and the Resource Reservation Protocol

The IETF, commercial research, and educational research groups are doing a great deal of work on protocols that make internetwork quality of service possible. A key standard is the IETF Resource Reservation Protocol (RSVP). This is an Internet control protocol that operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack.

RSVP allows a host to request specific qualities of service from the network for particular application data streams or flows. For example, a host could specify a specific network service level, based on average and peak bandwidth, maximum acceptable delay, priority queuing, congestion control, and other parameters. Routers also use RSVP to deliver QoS requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service.

Quality of Service

Network backbones need to support QoS protocols so that routers and switches can handle intensive, time-sensitive traffic loads. QoS provides network services differentiated by their level of security, bandwidth, delay (latency), jitter, error rates, cost, compression, and other parameters. In addition QoS techniques define ways for these different traffic types to share paths harmoniously within an internetwork. These traffic types include: Constant Bit Rate (CBR), Variable Bit Rate (VBR), and Available Bit Rate (ABR) applications.

Flows

A flow is a distinguishable stream of related datagrams that results from a single user activity and requires the same QoS. All datagrams in a flow have the same source and destination address. For example, a flow might consist of one transport connection or one video stream between a given host pair.

Flows are simplex; they have a single source but N destinations. The flow communicates the QoS reservation requirements to the network through a flow spec that is part of the flow. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows.

Put another way, a flow is a distinguishable stream of related datagrams that results from a single user activity and requires the same QoS. For example, a flow might consist of one transport connection or one video stream between a given host pair.

As defined by RFC 1363, a flowspec is a data structure that internetwork hosts use to request special service of the internetwork. Such special services are typically requests for guarantees about how about how the internetwork is to handle some of the hosts' traffic. Multimedia applications, for example, frequently require hosts along the Internet path to be able to provide guarantees about the quality of the communication between applications. Minimum bandwidth requirements to ensure timely delivery of images are an example.

Constant Bit Rate

Examples of applications that produce constant bit rate traffic on the network include older audio traffic and video codecs. Referred to as CBR applications, they have a required minimum bandwidth, cannot function with less bandwidth, and do not benefit from extra bandwidth (see Figure 5.17). A circuit-switched WAN environment is the typical place to find these applications. In this environment, they receive dedicated bandwidth.

Constant Bit Rate Service

Variable Bit Rate

Examples of applications that produce a variable stream of bits on the network include modern LAN TV, modern video codecs, and traditional interactive data applications such as telnet sessions. Referred to as VBR applications, they are characterized by a bursty data stream that fluctuates between low and high bandwidth requirements (see Figure 5.18).

VBR traffic can run in either circuit-switched or packet-switched networks. Each circuit of a circuit-switched network provides enough bandwidth to handle the peak rate a VBR application requires. If the VBR traffic falls below the peak rate, the extra bandwidth remains unused.

The set of VBR applications running on a packet-switched network receives enough bandwidth to handle the average required rate. A technique known as predictive quality of service handles the peaks by statistical sharing of the extra bandwidth.

Variable Bit Rate Service

Available Bit Rate

Examples of applications that can function with a wide range of available bandwidth include traditional file transfer data applications and newer multimedia mail and notes applications. Referred to as ABR applications they run:

slowly with little bandwidth and faster as they access additional bandwidth (see Figure 5.19).

ABR applications run well on traditional packet-switched data networks that provide best-effort quality-of-service guarantees.

Available Bit Rate Service

Latency

Many real-time interactive applications are sensitive to accumulated delay. A round trip latency budget (round-trip delay) of less than 400 ms is common. The sending computer, the network, and the receiving computer all contribute to the round-trip latency budget.

Most internetworking devices receive a packet before sending it out on another interface. Referred to as processing delay, the amount of delay that the device introduces depends on:

• The size of the packet

• The speed of the media

• The processing steps that the device might have to perform can including:

–Looking up a route and changing a header

–Changing the data link layer encapsulation

–Incrementing the hop count.

The network introduces latency with the types of delay shown in Table 5.8.

Network Induced Latency

Delay Type Description

Propagation Amount of time it takes information to travel the distance of the line. The speed of light controls propagation delay. Propagation delay is independent of the networking technology used.

Transmission Amount of time it takes to put a packet on the medium. The speed of the medium and the size of the packet determine the transmission delay.

Store-and-forward Amount of time it takes for an internetworking device to receive a packet before it can send it. Examples of such devices include switches, bridges, and routers.

Jitter

Jitter is any inconsistency in the rate at which digital information is converted into an analog signal and can occur in networks that produce variable latency for different packets. Technically jitter is the abrupt and unwanted variations of one or more signal characteristics, such as the interval between successive pulses, the amplitude of successive cycles, or the frequency or phase of successive cycles.

Integrated Services

Building a network that can economically support QoS and each class of traffic can be a challenge. Several approaches for building networks that support integrated services exist including implementing ATM and the RSVP.

Refer to Chapters 2 and 3 for a discussion about the ATM infrastructure and Chapter 12 for more details about IP multicasting and ATM networks.

Integrated Services Architecture

The large-scale experiment of multicasting the IETF meetings across the Internet has depended upon the availability of:

• Workstations equipped with built-in multimedia hardware including audio codecs and video frame grabbers

• The Mbone serving as a temporary multicast backbone for IP multicasting

• Highly-sophisticated digital audio and video applications.

Early experiments showed that real-time applications often do not work well across the Internet because of variable queuing delays and congestion losses.

As originally conceived, the Internet offers only a very simple QoS, point-to-point best-effort data delivery. Therefore, Braden, Clark, and Shenker in RFC 1633 an extension to the Internet architecture to provide integrated support for real-time and non-real-time QoS which provides some control over end-to-end packet delays.

In addition to real-time QoS, RFC 1633 discusses establishing controlled link sharing, which includes the ability to share the bandwidth on a particular link and to divide traffic into administrative classes. The classes could represent different user groups or different protocol families. RFC 1633 uses the term integrated services (IS) for an Internet service model that includes best-effort service, real-time service, and controlled link sharing.

"Traffic control" is the name given to the router function that creates different qualities of service. Three components (listed in Table 5.9) implement traffic control: the packet scheduler, the classifier, and admission control.

Components of Traffic Control

Component Function

Packet Scheduler Manages the forwarding of different packet streams using a set of queues and perhaps other mechanisms like timers

Classifier For the purpose of traffic control and accounting, this maps the incoming packet into a class based upon the contents of the existing packet header and additional classification number that may be added to each packet. A class is an abstraction local to a particular router. Different routers along the path might classify the same packet differently.

Admission Control Implements the decision algorithm that a router or host uses to determine whether a new flow can be granted the requested QoS without impacting earlier guarantees

Routers need to be able to reserve resources to provide special QoS for specific user packet streams or flows. This means routers need a flow-specific state. This represents a fundamental change to the Internet model based on the concept that all flow-related state should be in the end systems.

The RSVP has been designed to meet these requirements. It specifies how the flow state added to the routers for resource reservation can be made "soft", to preserve the robustness of the Internet protocol suite.

Introducing the Resource ReSerVation Protocol

The RSVP accommodates heterogeneous service needs in a multicast environment. It provides flexible control over the sharing of reservations along branches of the multicast delivery trees. RSVP is not itself a routing protocol, but is designed to operate with current and future unicast and multicast routing protocols.

• Hosts use the RSVP protocol to request specific qualities of service from the network for particular application data streams or flows. A request usually results in the reservation of resources in each node along the data path

• Routers use the RSVP protocol to deliver QoS requests to all nodes along the path of the flows and to establish and maintain state to provide the requested service.

RSVP operates on top of IPv4 or IPv6 and occupies the place of a transport protocol in the protocol stack. An RSVP implementation typically executes in the background, not in the data-forwarding path.

RSVP is an Internet control protocol, like ICMP, IGMP, or routing protocols. It does not transport application data.

An RSVP process obtains routes from the local routing database. In the case of multicast, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path or paths of that group. Routing protocols determine the packet's destination. RSVP's only concern is with the QoS of those packets forwarded in accordance with routing.

Figure 5.20 illustrates the flow of data packets in a single RSVP session and assumes multicast data distribution. The arrows indicate data flowing from senders S1 and S2 to receivers R1, R2, and R3. The cloud represents the distribution mesh created by multicast routing. This multicast distribution mesh is referred to as a session and is defined by the common IP (multicast) destination address of the receivers.

Multicast distribution forwards a copy of each data packet from a sender (S) to every receiver (R); a unicast distribution session has a single receiver (R). Each sender can be running in a unique Internet host, or a single host might contain multiple senders distinguished by generalized source ports.

Multicast Distribution Session

Refer to Chapter 13 for detailed information about RSVP.

Backward Forward
Chapter: Preface | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.
Beta Books | Beta Bookstores | Computing McGraw-Hill

Professional Publishing Home | Contact Us | Customer Service | For Authors | International Offices | New Book Alert | Search Catalog/Order | Site Map | What's New

A Division of the McGraw-Hill Companies
Copyright © 1998 The McGraw-Hill Companies, Inc. All rights reserved. Any use is subject to the Terms of Use the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers.


Marcus Goncalves
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Chapter Six

Under the Hood of IP Multicasting Protocols

RFC 1112 "Host Extensions for IP Multicasting" is the recommended standard for IP multicasting in the Internet. Members of an IP multicast datagram destination host group all receive the datagram with the same best-effort reliability as do regular unicast IP datagrams.

RFC 1112 specifies that the IP module must also be extended to implement the IGMP protocol included as an appendix. Like the ICMP, the IGMP is an integral part of IP. IP hosts use IGMv1 or IGMPv2, described in RFC 2236, to report their multicast group memberships to routers. RFC 2236 updates RFC 1112.

This chapter briefly:

• Introduces the concepts from RFC 1112

• Describes the necessary extension to the IP module to support IP multicasting

• Describes the IGMP and its message format

• Reviews IGMP message types as they apply to IPv4 and IPv6, and discusses the compatibility of IGMPv2 with IGMPv1 hosts.

• Summarizes the difference between IGMPV1 and IGMPv2.

• Describes the events that lead to host and router state transitions

• Lists the major IGMP timers and their default values.

Host Extensions for IP Multicasting

As defined by RFC 1112, IP multicasting is the transmission of an IP datagram to a host group, a set of zero or more hosts identified by a single IP destination address. This RFC applies a host IP implementation to support IP multicasting and defines a host as any Internet host or gateway other than those acting as multicast routers. Other RFCs define the algorithms and protocols used within and between multicast routers.

Introduction

Host group membership is dynamic, hosts can join and leave groups at any time; in addition:

• A group can be any size and its members can be located anywhere on the network

• A host can be a member of more than one group at a time

• A host can send datagrams to a group even if the host is not a member of the group.

Permanent and Transient Groups

A host group may be permanent or transient. Permanent host groups receive an administratively assigned well-known address. The membership in a permanent group can vary, just as with any other group.

Transient host groups receive an IP address dynamically from the pool of addresses not reserved for permanent groups. A transient group and its IP address assignment exist only as long as the group has members.

Multicast-Capable Routers

Multicast-capable routers forward IP multicast datagrams over the Internet. If the time-to-live value in the IP header of a multicast datagram is 1, the host sends the datagram only to the destination host group members on the local network.

If the TTL value is greater than 1, the multicast routers attached to the local network forward the datagram to all other networks with members of the destination group. Multicast-capable routers attached to the member networks deliver the datagram as a local multicast, but only on member networks reachable within the IP time-to-live.

Conformance

Currently there is no requirement in the Internet community that all IP implementation support IP multicast. There are three levels of conformance:

• Level 0–These hosts do not implement IP multicasting and generally are unaffected by multicast activity. On some types of networks, misdelivery of multicast datagrams to these hosts can occur because of the presence of Level 1 or 2 hosts.

• Level 1–These hosts can send IP multicast datagrams but cannot receive them. This type of host is not allowed to join any host groups. A Level 1 host can take part in some multicast-based services such as such as resource location or status reporting

• Level 3–These hosts can send and receive IP multicast datagrams to host groups and have full support for IP multicasting. They implement the extension of the IP and local network service interfaces within the host and IGMP.

Host Group Addressing Issues

Class D IP addresses identify host groups and have their high-order 4 bits set to 1110 followed by the 28-bit multiclass ID. Typically written in standard dotted decimal notation, Class D host group addresses range from 224.0.0.0 to 239.255.255.255. Figure 6.1 shows the Class D address format. The address 224.0.0.0 is reserved and is not to be assigned to any group. 224.0.0.1 is assigned to the permanent group of all IP hosts (including gateways).

Multicast Class D Address Format

The last 28 bits of a class D address is the multicast group ID and has no further structure. Refer to the Class D address format section of Chapter 5 for a description of Class D addressing and address mapping.

Except for permanent assignment, an IP host group address is dynamically bound to a set of local network interfaces on a set of IP networks. An IP host group address is not bound to a set of IP unicast addresses. Multicast-capable routers need to associate only a single multicast address with each host group that has local members. These routers do not need to maintain a list of the members' individual IP or Ethernet addresses.

Sample Host IP Multicast Implementation

With IP multicasting, ICMP and IGMP are both considered part of the IP layer as shown in Figure 6.2. The local network module has the responsibility of mapping the IP address to the local network address. RFC 1112 provides for two new services for IP multicast-capable hosts: the transmission and receipt of multicast IP datagrams.

For each service RFC 1112 specifies extensions for the IP service interface, the IP module, the local network service interface, and an Ethernet local network module.

A Host IP Multicast Implementation Model

Sending Multicast IP Datagrams

On a single physical network, the sending process specifies a destination IP multicast address. The device driver converts this address to the Layer 2 address, such as an Ethernet address, and sends the datagram. Receiving processes notify their IP layers that they want to receive datagrams from a particular multicast address. The device drive on the receiving host must enable reception of multicast frames.

Level 1 and Level 2 hosts must support the transmission of multicast IP datagrams. A system administrator can easily upgrade a level 0 IP implementation to Level 1 with little new code. Hosts can be attached to more than one network.

Extensions to the IP Service Interface for Outgoing Multicast Datagrams

An upper-layer protocol module needs to specify a multicast group address as the destination of an IP datagram rather than an individual IP address. The protocol uses the same send IP operation to transmit both unicast and multicast IP datagrams.

• The IP service interface should provide a way for the upper-layer protocol to specify the IP TTL of an outgoing multicast datagram, otherwise the upper-layer protocol should default to 1. This means that an explicit choice is required to multicast beyond a single network.

• The IP service interface should provide a way for the upper-layer protocol to identify which network interface to use for IP multicast traffic, otherwise system administration chooses a default interface.

• The service interface should provide a way for the upper-layer protocol to inhibit local delivery of the datagram when the host is itself a member of a group to which a datagram is being sent. The default is to loopback a copy of the datagram.

Providing a way for the upper-layer protocol to inhibit local delivery of datagrams is a performance optimization for upper-layer protocols. It restricts the membership of a group to one process per host. For example, the membership of a group might be able to use a routing protocol, or a protocol that handles loopback of group communication at a higher layer, such as a multicast transport protocol.

Extensions to the IP Module for Outgoing Multicast Datagrams

The IP module must recognize IP host group addresses when routing outgoing datagrams. To allow multicast transmissions, the routing logic must be:

If IP-destination is on the same local network or IP-destination is a host group, send datagram locally to IP-destination else send datagram locally to GatewayTo ( IP-destination )

• The IP source address of the outgoing datagram must be one of the individual addresses of the outgoing interface

• A host group address must never be in the source address field or in a source route option of an outgoing IP datagram.

Extensions to the Local Network Service Interface for Outgoing Multicast Datagrams

It is not necessary to change the local network service interface to support sending multicast IP datagrams. The IP module specifies a multicast group destination when it invokes the Send Local operation.

Extensions to Local Network Modules for Outgoing Multicast Datagrams

Ethernet allows multicast addresses in the destination field of Ethernet packets. To send multicast IP datagrams, map the IP host group addresses to Ethernet multicast addresses.

Map an IP host group address to an Ethernet multicast address by placing the low-order 23-bits of the IP address into the low-order 23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex). It is possible for more than one host group address to map to the same Ethernet multicast address because there are 28 significant bits in an IP host group address. Thirty-two different multicast group IDs map to each Ethernet address. Table 6.1 shows possible extensions to local network modules that are not Ethernet.

Refer to the Class D address format section of Chapter 5 for more information about mapping an IP host group address to an Ethernet multicast address.

It is possible for the interface card to receive multicast frames the host does not care about because the mapping is not unique and either the device driver or the IP module needs to perform filtering.

Possible Extensions to Local Network Modules Other Than Ethernet

Local Network Module Type of Mapping and Method of Sending Datagrams

Networks supporting broadcast only Map IP host group addresses to a single local broadcast address

Point-to-point link joining two hosts Transmit multicast datagrams just like unicast datagrams

Store-and-forward network Map IP host group addresses to the well-known local address of an IP multicast router. A router on such a network would complete multicast delivery within the network as well as among networks.

Two other reasons exists why filtering might be needed:

• Some LAN adapters support a finite number of concurrent multicast addresses. If the number of concurrent multicast addresses exceeds this value, then the adapter must receive all multicasts.

• Some LAN adapters filter according to a hash table value rather than the whole address. This means there is a possibility that two multicast addresses with the same hash value might be in use at the same time.

Despite this requirement for software filtering of multicast packets, multicasting still causes much less overhead for uninterestd hosts. In particular, those hosts not in any host group are not listening to any multicast addresses and all multicast messages are filtered by the network interface hardware.

Receiving Multicast IP Datagrams

Receiving processes on a multicast host need to notify their IP layers that they want to receive multicast datagrams for a particular multicast address. The device driver associated with an interface card on the host must enable reception of the multicast datagrams.

With UDP, a single process receives an incoming unicast UDP datagram. With multicast, when a host receives a multicast datagram it delivers a copy to all the processes that belong to that group. Multiple processes on a given host can belong to the same multicast group.

Layer 2 processes deliver all destination multicast MAC addresses to all ports because it processes these destination multicast MAC addresses just like Layer 2 broadcast addresses. Any switch that receives the multicast datagram forwards it to all of its interfaces and many hosts could receive messages they do not want (see Figure 6.3).

Layer 2 Processing of Broadcast and Multicast Frames

Routers at Layer 3 do not inherently forward multicast traffic and must implement a protocol such as IGMP that instructs routers when and when not to forward multicast traffic. IGMP tells the router if any hosts on a given physical network belong to a given multicast group.

Level 2 hosts must support the reception of multicast IP datagrams. Level 1 hosts are not required to do so.

Extensions to the IP Service Interface for Incoming Multicast Datagrams

An upper-layer protocol uses the same receive IP operation to receive IP multicast datagrams and unicast datagrams. Before the upper-layer protocol can receive datagrams for a particular group, it must ask the IP module to join that group. To support IP multicasting, the IP service interface must be extended to support:

• JoinHostGroup (group-address, interface)–This operation requests that this host become a member of the host group identified by group-address on the given network interface. JoinHostGroup can fail due to an invalid group address or interface or to the lack of local resources.

• LeaveHostGroup (group-address, interface)–This operation requests that this host give up its membership in the host group identified by group-address on the given network interface. LeaveHostGroup can fail due to an invalid group address or interface or because the host does not belong to the given group on the given interface.

If a host supports only one interface, omit the interface argument. When a host supports multiple interfaces, the upper-layer protocol can choose to leave the interface unspecified and use the default interface for sending multicast datagrams.

The same group can be on more than one interface. In this case, the module can receive multiple datagrams. More than one upper-layer protocol can request membership in the same group

Extensions to the IP Module for Incoming Multicast Datagrams

To support receiving IP multicast the IP module must be extended to implement the IGMP protocol. To support IGMP, every Level 2 host must join the all-hosts group on each network interface. The Level 2 host joins the all-hosts group at initialization and must remain a member as long as the host is active. The all-hosts group address is 224.0.0.1. IGMP keeps neighboring multicast-capable routers informed of the host group memberships present on a particular local network.

The all-hosts address may not be used as an internet-wide broadcast address. For the purpose of IGMP, membership in the all-hosts group is necessary only while the host belongs to at least one other group.

RFC 1112 specifies that the host shall remain a member of the all-hosts group at all times. This is partly because the all-hosts address can serve other routing-oriented purposes, such as advertising the presence of gateways or resolving local addresses.

In addition, the IP module must maintain a list of host-group memberships associated with each network interface. The module processes incoming datagrams for one of those groups exactly the way it processes datagrams destined to one of the host's individual addresses. The module discards incoming datagrams destined for groups to which the host does not belong. To support IP multicast, the IP module should:

• Discard an incoming datagram on hosts with more than one network interface, if the datagram arrives on one interface and is destined for a group to which the host belongs on a different interface

• Accept an incoming datagram with an IP TTL value of 1. This applies to arriving datagrams not being forwarded

• Quietly discard a datagram with an IP host group address in its source address field

• Never generate an ICMP error message in response to a datagram destined to an IP host group. This includes ECMP Destination Unreachable, Time Exceeded, Parameter Problem, Source Quench, and Redirect error messages

• Update the list of host group memberships in response to JoinHostGroup and LeaveHostGroup requests from upper-layer protocols.

A reference count or similar mechanism associated with each membership handles multiple requests to join and leave the same group. For example, the process notifies the local network module for a given interface on the first request to join and the last request to leave group on that interface. This enables the local network module to update its multicast reception filter.

Extensions to the Local Network Service Interface for Incoming Multicast Datagrams

The protocol delivers incoming local network multicast packets to the IP module using the same Receive Local operation as local network unicast packets use. To allow the IP module to tell the local network module which multicast packets to accept, extend the local network service interface to provide two new operations:

• JoinLocalGroup (group-address)–This operation requests the local network module to accept and deliver subsequently arriving packets destined for the given IP host group address

• LeaveLocalGroup (group-address)–This operation requests the local network module to stop delivering packets destined for the given IP host group address

The local network module must not deliver any multicast packets transmitted from that module. The IP layer or higher handles loopback of multicasts.

Extensions to Local Network Modules for Incoming Multicast Datagrams

RFC 1112 specifies that an Ethernet module must be able to receive packets addressed to the Ethernet multicast addresses corresponding to the host's IP host group addresses. Some Ethernet interfaces limit to a few the number of addresses that the hardware can be configured to recognize. This means it might be necessary to set the address filter to accept all multicast packets when the number of addresses exceeds the limit of the filter. Table 6.2 shows possible extensions to local network modules that are not Ethernet.

Other Extensions to Local Network Modules for Incoming Multicast Datagrams

Local Network Module Type of Mapping and Method of Sending Datagrams

IEEE 802.2 networks Treat as in Ethernet for the purpose of receiving multicast IP datagrams

Networks supporting broadcast only Accept all incoming broadcast packets and pass them to the IP module for IP-level filtering

Point-to-point link joining two hosts Multicast IP datagrams arrive as local network unicasts. No change to the local network module is necessary.

Store-and-forward network Multicast IP datagrams arrive as local network unicasts. No change to the local network module is necessary.

Internet Group Management Protocol Basic Operation

Like the ICMP, the IGMP is an integral part of IP and uses IP datagrams to transmit data. Depending on the implementation of IGMP, IP hosts use either IGMPv1 described in RFC 1112 or IGMPv2 described in RFC 2236 to report their multicast group memberships to routers. RFC 2236 updates RFC 1112. ICMPv6 incorporates some functions from IGMP. IGMP Version 3 is a preliminary draft specification.

Hosts implementing IGMP are Level 2 hosts and can receive IP multicasts. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. Unlike other protocols, IGMP has a fixed-size message within an IP datagram as shown in Figure 6.4.

• IP hosts use the IGMP to report their multicast group memberships to any immediately neighboring multicast routers

• IP multicast-capable routers use IGMP to learn about group memberships on their attached physical networks.

Forging IGMP messages is theoretically possible and doing so would have some effect on network performance. RFC 2236 "Internet Group Management Protocol, Version 2" describes the possible effects on network security and performance.

IP Datagram with IGMP Messages

RFC 2236 is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk.

Any router that is a member of a multicast group should operate as a host as well as a router. Such routers can respond to their own queries. A router needs to run IGMP on only one of the interfaces if the router has multiple physical interfaces on a single network. Hosts need to perform their actions on all interfaces that have associated memberships.

For each attached network, a multicast router maintains a list of multicast group memberships and a timer for each membership. Multicast group memberships mean the presence of at least one member of a multicast group on the attached network. They are not a list of all of the members of the attached network.

IGMP Messages

IP datagrams encapsulate IGMP messages with an IP protocol number of 2. IGMP messages are sent with IP TTL 1, and contain the new IP Router Alert option type in their IP header. RFC 2113 describes this new IP option type that alerts transit routers to examine more closely the contents of an IP packet. This option type is useful with protocols, such as IGMP, that are addressed to a destination but require relatively complex processing in routers along the way.

The IGMP message types included Group Membership Query messages, Group Membership Report messages, and Leave Group Membership messages. IGMPv1 and IGMPv2 messages have the format shown in Figure 6.5.

IGMP Message Format

Version Field

As shown in Figure 6.5, IGMPv2 combines the IGMPv1 Version and Type fields into a single Type field. In IGMPv1 implementations, this field carries a value of 1.

Type Field

IGMPv1 specifies two message types: Host Membership Query messages and Host Membership Report messages. IGMPv2 specifies three message types: Group Membership Query messages, Group Membership Report messages, and Leave Group Membership messages.

• Membership Query messages–Referred to simply as query messages, the group address differentiates two sub-types of Membership Query message as follows:

–General Query messages for routers to use to learn which groups have members on an attached network

–Group-Specific Query for routers to use to learn if a particular group has any members on an attached network.

To be valid, the Query message must be at least 8 octets long, and have a correct IGMP checksum. The group address must be either zero or a valid multicast group address.

• Group Membership Report messages–A new IGMP type is assigned to Version 2 Membership Report messages, so a router can tell the difference between an IGMPv1 and IGMPv2 host. Within IGMPv2 there is an additional message type for backward-compatibility with IGMPv1 that triggers a Version 1 group membership report.

• Leave Group Membership messages–This is a new IGMP type created for IGMPv2.

Message Types and Destinations

Table 6.3 summarizes the IGMP message types and message destination group.

IGMP Message Type and Destination Groups

Message Type Destination Group

General Query ALL-SYSTEMS (224.0.0.1)

Group-Specific Query The group being queried

Membership Report The group being reported

Leave Message ALL-ROUTERS (224.0.0.2)

ICMP divides its message header type field values into types 0 through 127 for error messages and types 128 trough 255 for informational messages. Of particular interest here are the ICMP information messages that point to the IGMP information messages as shown in (Table 6.4). The most recent "Assigned Numbers" (RFC-1700) specifies the up-to-date values of the ICMP Type field.

IGMP Specific ICMP Informational Message Types

ICMP Message Header Type Field Value IGMP Message Type

130 Group Membership Query

131 Group Membership Report

132 Leave Group Membership

IGMP Multicast Membership Report Messages

When a host receives a general or group-specific multicast membership query, it does a number of things.

First the host identifies the groups on the interface from which it received the query and sets delay timers for each group of which it is a member. If a timer for the group is already running, it is reset depending on the value of the Max Response Time.

The host multicasts a membership report to the group when the group's timer expires. Under some conditions a host might receive another host's report while it has a timer running. In this case, the host stops its timer for that group and does not send a report for that group.

When a router receives a report, it:

• Adds the group being reported to the list of multicast group memberships on the network on which it received the report

• Sets the timer for the membership to the Group Membership Interval the amount of time that must pass before a multicast router decides there are no more members of a group on a network.

If the router does not receive reports for a particular group before the timer expires, the router assumes the group has no local members. In this case it does not forward multicasts for that group onto the attached network that it receives from remote origins.

IGMP Multicast Leave Group Membership

When a host leaves a multicast group it sends a Leave Group message depending on the specific implementation of IGMP on the host. Some hosts send a Leave Group message if the host leaving the group was the last host to reply to a query with a membership report for that group. Other implementations might have any host leaving the group send a Leave Group message no matter when that host replied with a membership report to a query. Routers should always accept a leave group message address to the group that is being left. Leave Group messages are typically addressed to the all-router group. IGMP sets the group address field in the membership Leave Group message header to the IP multicast group address of the group being left. An IGMPv2 host can suppress Leave Group messages on a network where the host is using IGMPv1.

Max Response Time field

In IGMPv1 this field is unused; senders set this field to zero and receivers ignore this field.

In IGMPv2 implementations, Membership query messages use the Max Response Time field. The protocol specifies that the response time is to be measured in units of 1/10 second and defines the response time as the maximum time before a host must send a report in response to a query message.

For all other IGMPv2 message types the sender sets this field to zero and receivers ignore this field.

By varying this setting in membership query messages:

• IGMPv2 routers are able to tune the leave latency setting. This means IGMPv2 routers can control the time between when the last host leaves a group and router discovers that there are no more attached group members.

• A host can tune the burstiness of IGMP traffic on a subnet.

Checksum Field

For both versions, IGMP sets the checksum field to zero for computing the checksum. The RFC 1112 specifies the checksum as the 16-bit one's complement of the ones complement sum of the 8-octet IGMP message.

The IGMP protocol (RFC 2236) specifies the checksum as the 16-bit ones complement of the ones complement sum of the whole IGMP message. This is the entire IP payload. Note that IGMP messages can be longer than 8 octets. Always compute the IGMP checksum over the whole IP payload, not just over the first 8 octets.

The protocol specifies that the checksum must be computed and inserted into the checksum field when transmitting packets and that the checksum must be verified before processing the packets.

Group Address Field

IP addresses in this field identify the group address being queried, reported, or left. In an IGMPv1 Host Membership Query message, the host sets the Group Address field to zero when sending a query and ignores this field when it receives a query.

In IGMPv2 implementations, the group address (see Figure 6.5) differentiates between the two types of query messages. In a Membership Query message:

• A host sets the Group Address field to zero when sending a General Query

• A host sets the Group Address field to the group address being queried when sending a Group-Specific Query.

For both versions of the IGMP protocol, the Group Address field in a Host Membership Report message holds the IP host group address of the group being reported (see Figure 6.6).

IGMP sets the Group Address field in the membership Leave Group message header to the IP multicast group address of the group being left. An IGMPv2 host can suppress Leave Group messages on a network where the host is using IGMPv1.

IGMP sets the Group Address field in the membership report message header to the IP multicast group address of the group being reported.

IGMP Reports and Queries

IGMP Operation

A multicast router can act as querier or non-querier. There is normally only one querier for each physical network. When a multicast router hears a Query message from another router that has a lower IP address, the protocol requires that it become a non-querier on that network.

Router Messages

Multicast routers send Group Membership Query messages to discover which host groups have members on their attached local networks. The router addresses such queries to the all-hosts group address 224.0.0.1 with a Group Address field of 0 and an IP TTL of 1.

A router with multiple physical interfaces on a single network need only run IGMP on one of them. Hosts need to perform their actions on all interfaces having memberships associated with them.

Multicast routers send Queries periodically to refresh their knowledge of memberships present on a particular network.

Host Responses

When a host joins a new group, it should immediately transmit a report for that group, rather than waiting for a query in case it is the first member of that group on the network.

Hosts respond to a query by generating Group Membership reports. The reports identify each host group to which the host belongs on the network interface from which the host received the query. A multicast router maintains a list of multicast group memberships for its attached networks. The router also maintains a timer for each membership.

The host starts a report delay timer for each of its group memberships on the network interface so reports are spread out over a short interval instead of occurring all at once. To prevent duplication a host suppresses a report if it receives another host's report (Version 1 or 2) while it has a timer running. Normally the member host whose delay timer expires first generates the report for each group present on the network.

The host sends a report with an IP destination address equal to the host group address being reported. A router receiving a report adds the group to its list of multicast group memberships for that network and sets the timer for the membership to the Group Membership Interval. Repeated reports refresh the timer.

A host never sets the report delay timer for a host's membership in the all-hosts group (224.0.0.1), and that membership is never reported.

Leaving a Host Group

Both IGMPv1 and IGMPv2 multicast routers send queries periodically to refresh their knowledge of memberships present on a particular network. IGMPv1 and IGMPv2 implementations have different ways of handling group members leaving a group.

IGMPv1 Implementations

If an IGMPv1 multicast router receives no reports for a particular group after a number of queries, the router assumes the group has no local members and there is no need for remote forwarding of originated multicasts for that group onto the local network.

On a network with no multicast routers, the only IGMP traffic is the report (s) sent whenever a host joins a new group.

IGMPv2 Implementations

When a host who was the last host to report for the group leaves a multicast group, it should send a Leave Group message to the all-routers multicast group address 224.0.0.2. Leave Group messages are addressed to the all-routers group because other group members have no need to know that a host has left the group. If the departing host was not the last host to reply to a query, it does not have to send a Leave Group message because other group members could be on the subnet. If the departing hosts wants to send a Leave Group message, it may do so when it leaves a group.

To accommodate earlier implementations of IGMP, IGMPv2 routers should accept a Leave Group message addressed to the group being left.

Several things happen when a router acting as a querier receives a Leave Group message for a group that has group members on the reception interface. The router:

• Sends Group-Specific Queries to the group being left

• Sets the Max Response time to the Last Member query interval

• Assumes the group has no local members if it receives no reports after the response time expires.

The protocol requires non-queriers to ignore Leave Group messages for which there are no group members on the reception interface.

On receipt of a Group-Specific Query message a non-querier sets its group membership timer to the Max Response time specified in the message. This is true if the non-querier has an existing group membership timer greater than the Last Member Query Count times the Max Response time specified in the message.

Compatibility with IGMPv1 Routers

An IGMPv2 host can be on a subnet where the router is an IGMPv1 router. Under these circumstances, the IGMPv1 router:

• Sends general queries with the Max Response time set to 0

• Expects Version 1 membership reports and ignores IGMP Version 2 membership reports.

The IGMPv2 protocol requires a state variable for each interface. The variable identifies the multicast querier on that interface as running IGMPv1 or IGMPv2. The recipient of the query uses this state variable to decide what type of membership reports to send for solicited or unsolicited membership reports.

An IGMPv2 router may be placed on a subnet where at least one router on the subnet has not yet been upgraded to IGMPv2. Under these circumstances the querier must use IGMPv1, which is administratively configured. The ICMPv2 protocol states that some implementations can allow the system administrators to enable the use of IGMPv1 on their routers; in the absence of explicit configuration, the configuration must default to IGMPv2. When in IGMPv1 mode, routers:

• Must send Periodic queries with a Max Response time of 0

• Must ignore Leave Group messages.

• Should log a warning if a router is not explicitly configured to use IGMPv1 and hears an IGMPv1 query.

Compatibility with IGMPv1 Hosts

IGMPv2 and IGMPv1 hosts can coexist on the same subnet. If they do, a host is required to permit the suppression of the membership report of the opposite version.

IGMPv2 and IGMPv1 routers can also coexist on the same subnet. If they do, a router receiving a Version 1 membership report is required to set a timer indicating the presence of Version 1 hosts that are members of the group for which the router heard the report. This timer setting is the same as the group membership interval.

If any Version 1 hosts are present for a particular group, a router is required to ignore any Leave Group messages it receives for that group.

IGMP Version 3 in Progress

IGMP Version 3 is a preliminary draft specification published in <draft-ietf-idmr-igmp-v3-00.txt>. Version 3 of IGMP adds support for source filtering. This means that IGMP Version 3 can give a system the ability to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address.

In other words, a multicast router can learn which sources are of interest to neighboring systems, for packets sent to any particular multicast address. A multicast router needs to know only that at least one system on an attached network is interested in multicast datagrams sent to a specific multicast address from a specific source. Multicast routing protocols use this information to avoid delivering multicast packets from specific sources to networks where there are no interested receivers.

With IGMP Versions 1 and 2, if a host wants to receive any sources from a group, the traffic from all sources for the group has to be forwarded onto the subnetwork.

IGMP Version 3 helps conserve bandwidth by allowing a host to select the specific sources from which it wants to receive traffic. Multicast routing protocols use this information to conserve bandwidth when constructing the branches of their multicast delivery trees.

Interoperation With Older Versions Of IGMP

IGMP Version 3 hosts and routers interoperate with hosts and routers that have not yet been upgraded to IGMPv3.Table 6.5 shows how to identify the version of a Host Membership Query message. Routers discard query messages that do not match any of the conditions shown in this table.

Identification of the IGMP Version of a Host Membership Query Message

IGMP Version Message Identification

IGMPv1 Query Length = 8 octets and Max Response time field is zero

IGMPv2 Query Length = 8 octets and Max Response time field is non-zero

IGMPv3 Query Length = 12 octets and Reserved field is zero

IGMPv3 hosts can operate in Version 1 and Version 2 compatibility modes. The version of the querier router on an interface governs the mode in which a host operates. The Host Membership Query can reveal the version of the querier. An IGMPv3 host may be placed on a network where:

• The querier router has not yet been upgraded to IGMPv3

• There are hosts not yet upgraded to IGMPv3

• At least one router on the network has not yet been upgraded to IGMPv3.

The API for Requesting IP Multicast Reception

An IP system conceptually has at least one Application Programming Interface (API). Upper-layer protocols or application programs use the API to ask the IP layer to enable and disable reception of packets sent to specific IP multicast addresses. In order to take full advantage of the capabilities of IGMPv3, a system's IP API must support the following operation or a logical equivalent:

IPMulticastListen (socket, interface, multicast-address, filter-mode, source-list)

For example, a system sends a "Source-List-Change Record" whenever a local invocation of IPMulticastListen causes a change of source list that is not coincident with a change of filter mode, of the interface-level state entry for a particular multicast address. Refer to the IGMP RFCs and internet drafts for details.

Host State Diagram

The state transition diagram shown in Figure 6.7 specifies host behavior. It shows each state transition and lists the event that causes the transition and any actions taken during the transition. A host can be in one of three states concerning a single IP multicast group on any single network interface:

• Non-Member State–The condition in which the host does not belong to the group on the interface. This is the initial state for all memberships on all network interfaces

• Delaying Member State–The condition in which the host belongs to the group on the interface and has a report delay timer running for that membership.

• Idle Member State–The condition in which the host belongs to the group on the interface and does not have a report delay timer running for that membership.

State Transition Diagram

For the all-hosts group address 224.0.0.1, the host starts in Idle Member state for that group on every interface. It never transitions to another state, and never sends a report for that group.

Events That Cause a Host State Transition

Five different types of events described in Table 6.6 can cause a state transition.

Events Causing a Host State Transition

Event Causes state transition when

Join group The host decides to join the group on the interface

Leave group The host decides to leave the group on the interface

Query received The host receives either a valid General Membership Query message, or a valid Group-Specific Membership Query message. Queries are ignored for memberships in the non-member state.

Report received The host receives a valid IGMP Version 1 or Version 2 Membership Report message. A report is ignored for memberships in the Non-Member or Idle Member state.

Timer expired The report delay timer for the group on the interface expires. It can occur only in the Delaying Member state.

To be valid, both the Query message and the Report message must be at least 8 octets long and have a correct IGMP checksum.

Responses to Events Causing a Host State Transition

IGMPv1 specifies three and IGMPv2 specifies seven different possible actions in response to events that cause a state transition. Table 6.7 describes these actions.

Actions in Response to Events That Cause a Host State Transition

Action Description Protocol Version

Send report For the group on the interface IGMPv1 and IGMPv2 implementations

Send leave For the group on the interface. The Leave Message is sent to the ALL-ROUTERS group address 224.0.0.2. IGMPv2 implementations

Set flag Indicates that this was the last host to send a report for this group IGMPv2 implementations

Clear flag Indicates that this was not the last host to send a report for this group IGMPv2 implementations

Start timer For the group on the interface, using a random delay value for IGMPv1 implementations and using a delay value chosen uniformly from the 0, Max Response Time interval. IGMPv1 and IGMPv2 implementations

Stop timer For the group on the interface IGMPv1 and IGMPv2 implementations

Reset timer For the group on the interface to a new value, using a delay value chosen uniformly from the 0, Max Response Time interval IGMPv2 implementations

Refer to RFC 1112 and RFC 2236 for additional state diagrams and details about host state transitions.

Router State Diagrams

IGMPv2 specifies router behavior in a number of state transition diagrams. Two are discussed here.

Router States With Respect to Any Single Attached Network

The state transition diagram shown in Figure 6.8 specifies router states with respect to any single attached network. It shows each state transition and lists the event that causes the transition and any actions taken during the transition. A router can be in one of two states with respect to any single attached network:

• Querier state–The condition in which the router is to transmit IGMP Membership Queries on this network

• Non-Querier state–The condition in which another router that is to transmit IGMP membership queries on this network.

Router State Transition Diagram

A router should start in the Initial state on all attached networks, and immediately move to Querier state.

Events That Cause a Router to Change State

Three different types of events described in Table 6.8 can cause a router to change states.

Events Causing a Router to Change State

Event Causes state transition when

Query timer expired The timer set for query transmission expires

Query received from a router with a lower IP address A router receives an IGMP membership query from another router on the same network with a lower IP address

Other querier present timer expired The timer set to track the presence of another querier with a lower IP address on the network expires

Responses to Events Causing a Router to Change State

IGMPv2 specifies three possible actions in response to events that cause a router to change state. Table 6.9 describes these actions.

Actions in Response to Events That Cause a Router to Change State

Action Description Version

Start general query timer For the attached network IGMPv2

Start other querier present timer For the attached network and set to Other Querier Present interval IGMPv2

Send general query On the attached network. Send the general query to the all-systems group 224.0.0.1 with a Max Response time for the Query Response interval. IGMPv2

Router State With Respect to an IP Multicast Group On Any Single Attached Network

A router should start in the Initial state on all attached networks and immediately move to Querier state. Figure 6.9 shows the state diagram for a router in Querier state. Note that in order to keep track of which groups have members, a router can also be in one of four possible states with respect to any single IP multicast group on any single attached network:

• No Members Present state–The condition in which no hosts on the network have sent reports for this multicast group. This is the initial state for all groups on the router.

• Members Present state–The condition in which a host on the network has sent a membership report for this multicast group

• Version 1 Members Present state–The condition in which an IGMPv1 host on the network has sent a Version 1 membership report for this multicast group.

• Checking Membership state–The condition in which the router has a Leave Group message but has not heard a membership report for the multicast group.

The State Diagram for a Router in Querier State

Events That Cause a Router State Transition

Six different types of events described in Table 6.10 can cause router state transitions.

Events Causing Router State Transitions

Event Causes state transition when

V2 report received The router receives a Version 2 membership report for the group on the interface

V1 report received The router receives a Version 1 membership report for the group on the interface

Leave received The router receives an IGMP Group Leave message for the group on the interface

Timer expired The timer set for a group membership expires

Retransmit timer expired The timer set to retransmit a group-specific membership query expires

V1 host timer expired The timer set to note the presence of Version 1 hosts as group members expires

To be valid, both the membership report for the group and the Leave message for the group must be at least 8 octets long and have correct IGMP checksums.

Responses to Events Causing a Router State Transition

IGMPv2 specifies six different possible actions in response to events that cause a router state transition (see Table 6.11).

Actions in Response to Events That Cause a Router State Transition

Action Description

Start timer For the group membership on the interface and reset the timer to its initial Group Membership Interval value if the timer is currently running

Start timer For the group membership on the interface. This action sets the timer to the Last Member Query Interval value if this router is a querier. This action sets the Max Response time in the packet for the Last Member Query count if this router is a non-querier.

Start retransmit timer For the Last Member Query interval for the group membership on the interface.

Start V1 host timer For the group membership on the interface; resets the timer to its initial Group Membership interval if the timer is currently running

Send group-specific query For the group on the attached network; send the Group-Specific query to the group being queried with a Max Response time of Last Member Query interval

Notify routing + Notify the routing protocol that there are members of this group on this connected network

Notify routing - Notify the routing protocol that there are no longer any members of this group on this connected network

The state diagram for a router in Non-Querier state is similar. However, non-queriers do not send any messages. They do not care whether a Membership Report message is Version 1 or Version 2.

Refer to RFC 1112 and RFC 2236 for additional state diagrams and details of router state transitions.

List Of Timers and Default Values

A system administrator can configure most IGMP timers. Table 6.12 lists the major IGMP timers and their default settings.

Non-default settings must be consistent among all routers on a single link.

IGMP Timers and Default Settings

Timers Description/Function Default

Robustness Variable Allows tuning for the expected packet loss on a subnet; must not be zero 2

Query interval The interval between general queries; used for tuning the number of IGMP messages on the subnet 125 seconds

Query Response interval The Max Response time for a general query; used for tuning the burstiness of IGMP messages on the subnet 100 (10 seconds)

Group Membership interval Amount of time before a multicast router decides there are no members of a group on a network Robustness Variable x Query Interval + one Query Response interval

Other Querier Present interval Amount of time before a multicast router decides no other querier is present Robustness Variable x Query interval + 1/2 of one Query Response interval

Startup Query interval The interval between general queries on startup 1/4 the Query interval

Startup Query count Number of queries sent out on startup Robustness Variable

Last Member Query interval Max Response time in Group-Specific queries sent in response to Leave Group messages. Also the time between Group-Specific Query messages. 10 (1 second)

Last Member Query count Number of Group-Specific queries before the router decides there are no local members Robustness Variable

Unsolicited Report interval Time between repetitions of a report of membership in a group 10 seconds

Version 1 Router Present timeout The time a host must wait between hearing a Version 1 query and sending any IGMPv2 messages 400 seconds

Backward Forward
Chapter: Preface | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.
Beta Books | Beta Bookstores | Computing McGraw-Hill

Professional Publishing Home | Contact Us | Customer Service | For Authors | International Offices | New Book Alert | Search Catalog/Order | Site Map | What's New

A Division of the McGraw-Hill Companies
Copyright © 1998 The McGraw-Hill Companies, Inc. All rights reserved. Any use is subject to the Terms of Use the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers.


Marcus Goncalves
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Chapter Seven

Multicast Routing Concepts and Algorithms

The last few years have seen the widespread deployment of the World Wide Web and multicast protocols that support group communications. These protocols use a one-to-many paradigm to send datagrams and typically employ Class D IP addresses to specify multicast groups. Routers play an important role in IP multicasting.

The mechanism for multicast routing is complex. Hosts can join or leave a multicast group at any time. This means the path along which a multicast-capable router sends datagrams, and the routing table for multicast-capable routers, can change frequently. Finding a good path to a destination can be difficult and complicated. The rapid growth of bandwidth-hungry multimedia applications makes good multicast routing very important since with good multicast routing algorithms and protocols, wasting bandwidth can be avoided.

This chapter briefly:

• Introduces routing in an IP environment

• Describes routing protocol types including distance-vector protocols, link-state protocols, and interior and exterior routing protocols.

• Introduces multicasting routing

• Describes the dense and sparse modes of multicasting

• Explores a number of different algorithms that can potentially be employed by multicast routing protocols, including spanning tree and reverse path broadcasting.

Routers use the address format of a datagram to determine if that datagram is to be unicast, anycast, multicast, or broadcast (see Table 7.1). Multicast traffic uses Class D addresses, which can be allocated dynamically.

Datagram Delivery Methods

Delivery Method Definition

Unicast Delivering a packet to a single receiver

Anycast Delivering a packet to one interface of a set of receivers

Multicast Delivering a packet to a set of receivers

Broadcast Delivering a packet to all receivers

Routers within the Internet are organized hierarchically. Some are used to move information through one particular group of networks under the same administrative authority and control.

Multicast IP Delivery Service

Refer to RFC 1768 "Host Group Extensions for CLNP Multicasting" for a description of multicast extensions to the CLNP protocol similar to those provided to IP by RFC 1112. CLNP is an OSI connectionless network protocol. These extensions are intended to provide the mechanisms needed by a host for multicasting in a CLNP-based Internet.

Introduction to Routing in an IP Environment

The Internet community usually refers to devices that perform the forwarding function of the IP suite as routers or IP routers. Routers within the Internet are organized hierarchically. The OSI community usually refers to these devices as intermediate systems. Such devices are sometimes also referred to as gateways but use of this term should be avoided to prevent confusion with application gateways.

Routing is a method of switching data from a point on one network to a point on another network. It is the main process used by Internet hosts to deliver packets to the target machine. Each intermediary router passes along the message to the next router. Finding a good path (creating a routing table in a router) to a destination is not always easy.

Routing requires a unique identification for each destination, usually the specific network number and host number. It assumes that the address has at least partial information about the location of a host. This means routers can forward data without having to broadcast and without having a complete list of all the possible destinations for the data. Part of this process involves analyzing a routing table to determine the best path.

IP Routing

IP routing involves the examination of the IP protocol header and some of the bits of the IP address to identify the network location for which the datagram is destined. The remaining bits in the address uniquely identify the host on the destination network that is ultimately to receive the datagram. If the sender is on the same network as the destination of the datagram, the sender determines the data link address of the recipient and sends the datagram directly to the recipient.

If the sender is on a different network than the recipient, the sender forwards the datagram to a router and lets the router forward the datagram the destination network.

The last router at the destination network determines the data-link address of the recipient and forwards the datagram directly to that host.

The ability to forward packets is a major difference between Internet hosts and routers. Routers use forwarding algorithms of one form or another, while Internet hosts do not require forwarding capabilities. A number of different algorithms can potentially be employed by multicast routing protocols, including:

• Flooding

• Spanning trees

• Reverse-Path Broadcasting (RPB)

• Truncated Reverse-Path Broadcasting (TRPB)

• Reverse-Path Multicasting (RPM)

• Core-based trees.

From a simplistic view, the Internet routing system consists of two components: interior and exterior routing. The concept of an Autonomous System (AS) plays a key role in separating interior from exterior routing (see Figure 7.2). Routing protocols form the heart of the Internet.

Interior and Exterior Routing

IP routing protocols are dynamic and require software in the routing devices to calculate the routes. The dynamic routing algorithms can select the best routes for packets and can adapt to changes in the network. The network administrator establishes the paths for static routes and these routes do not change until the network administrator changes them.

A router builds an IP routing table consisting of destination address-next hop pairs. The IP datagram moves one router hop at a time through the network. Each router on the way determines the next router hop by matching the destination address with an entry in its routing table.

Error Reporting

Each node forwards packets based on internal information. IP does not provide for error reporting. RFC 792 defines the Internet Control Message Protocol (ICMP). ICMP handles error and system level messages and sends them to the offending gateway or host. It uses the basic support of IP as if it were a higher-level protocol, but ICMP is actually an integral part of IP, and must be implemented by every IP module, particularly those implementations that run in routers. In addition to reporting routing failures, ICMP provides:

• ICMP Echo and Reply messages used to test node reachability

• ICMP Redirect messages used to increased routing efficiency

• ICMP Time Exceeded messages for notifying sources that a datagram has exceeded its TTL.

Autonomous Systems

An AS is a collection of subnetworks with hosts attached and interconnected by a set of routes inside a domain under common technical management. Put another way, an AS is a collection of Classless Inter-Domain Routing Protocol (CIDR) IP address prefixes under common technical management. An AS is expected to present a consistent picture to other ASs of which networks are reachable through the AS.

An AS uses interior routing protocols such as Routing Information Protocol (RIP), Open Shortest Path First protocol (OSPF), and Multicast Open Shortest Path First (MSOPF) for routing within the AS. Exterior routing protocols such as the Border Gateway Protocol (BGP) provide inter-AS routing so that an AS can reach other autonomous systems in the Internet.

An Autonomous System number identifies an AS. The IANA assigns AS numbers in the range of 1 through 65534. BGP uses the AS number to implement policy routing and avoid top-level routing loops. Each autonomous system a route passes through prepends its AS number to the beginning of the AS path. The AS path list the autonomous systems the routing information passed through to get to a particular router.

Autonomous systems fall into three distinct types as shown in Table 7.2. Figure 7.3 shows two types of autonomous systems.

Three types of Autonomous Systems

AS type This type of AS

Stub AS Only connects to one other AS. For routing purposes, it is a simple extension of the other AS. A Stub AS can usually have a default route to its parent.

Transit AS Connects to more than one other AS and can be used as a conduit for transit traffic between other autonomous systems. A Transit AS must use default-less routers.

Multihomed AS Connects to more than one other AS, but does not allow transit traffic to pass. However, its interior hosts can route traffic through multiple ASs. A Multihomed AS can use a default route to one of its neighbor ASs.

Stub and Transit Autonomous Systems

Routing Protocols

Routing protocols form the heart of the Internet. They define the mechanism for building routing tables, uniquely identifying routing packets, and the rules for switching data from one point on a network to another. Network engineers assign costs to network paths. Routing protocols select the least-cost path to the destination. Routing protocols fall into four categories:

• Distance-vector routing protocols

• Link state routing protocols

• Interior routing protocols, usually referred to as Interior Gateway Protocols (IGPs).

• Exterior routing protocols.

Distance-Vector Routing Protocols

In distance-vector routing each router informs its neighbor about its routing table. To establish the network path, the receiving router chooses the neighbor that advertises the lowest cost. The receiving router then adds the path to its neighbor into its routing table for re-advertisement. The Hello and RIP are examples of distance-vector routing protocols. The Interdomain Routing Protocol (IDRP) is an OSI-based distance-vector routing protocol that defines the path for packets sent through the network.

Link-State Routing Protocols

In link-state routing each router maintains a partial map of the network. If a network link comes up or goes down, link-state protocols flood a notification of this change of state throughout the network. All routers note the change and recompute the routes in their routing table. Link-state routing is more reliable and easier to debug than distance-vector routing. However, it is more complex and more memory-intensive. The OSPF protocol is an example of a link-state routing protocol.

Interior Routing Protocols

Interior routing or IGPs exchange reachability information within an AS. Most common routing protocols, such as Hello, RIP, and OSPF, are interior routing protocols. The basic routable element is the IP network or subnetwork, or CIDR prefix for newer protocols.

Exterior Routing Protocols

Exterior routing occurs between autonomous systems. Service providers and large or complex networks mostly use exterior routing. The basic routable element is the AS, a collection of CIDR prefixes identified by an AS number.

There can be may different interior routing protocols in use but a single exterior routing protocol manages the global Internet. Exterior routing protocols are usually referred to as exterior gateway protocols. The Border Gateway Protocol (BGP-4) is an exterior routing protocol. Interdomain Routing Protocol (IDRP) is currently adapted to support exchange of interdomain system routing information among routers that support the forwarding of IPv6 packets.

IDRP and BGP Router Connectivity

Current exterior routing protocols such as BGP-4 and IDRP require all BGP and IDRP routers to have connectivity with each other to exchange routing information acquired from other routing domains. This is true for BGP/IDRP routers that belong to the same routing domain and take part in interdomain routing. If the routing domain is large, each border router needs to maintain a substantial number of connections

If border routers in other domains are reachable through shared communication media it could be useful for a border router to establish and maintain routing sessions with those border routers. Routers that are directly reachable through a shared medium are referred to as adjacent routers. Direct peering with these routers allows a router to acquire information about destinations directly reachable through the adjacent border router.

This arrangement can work well in may instances, though there can be problems with a switched medium such as an ATM, SMDS, or frame relay network which can interconnect a large number of routers. The number of connections required to maintain this type of direct peering between the routers can be very large and hence impractical.

IDRP/BGP Route Servers

To solve the problem of maintaining a large number of direct peering connections, D. Haskin in RFC 1863 proposes the use of IDRP/BGP route servers. This type of server could be used to relay external routes between client routers. The servers would relay these external routes with all of their attributes.

A client router would maintain IDRP/BGP sessions only with the assigned route servers. The router server would propagate all routes received from a client router to other client routers. The client routers would receive the same information as if they were participating in direct peering will all adjacent routers. Referred to as virtual peering, this type of arrangement allows client routers independently to apply their own criteria to these external routes according to their own local policies.

Routing Tables

Routers periodically send routing update messages to adjacent routers, conveying the state of the network as perceived by that particular router. The routers record this data in routing tables that are then used to determine optimal transmission paths for forwarding messages across the network.

The routing table is created by direct configuration by the administrator or dynamically through the periodic broadcasting of router update messages. Protocols like the RIP, OSPF, and Cisco's IGRP are sent from all routers at periodic intervals. The means that all routers become aware of how to reach all other networks.

Routers in a number of routing protocols share their routing tables and use a hop as a metric to determine the maximum path limit. In IPv6 implementations, each network should have an IPv6 destination address prefix and prefix length associated with it. Usually the network administrator sets the hop metric and destination address prefix and length. Routers inform each other of their presence.

For example, each router in an RIP network broadcasts its routing table to all other router at set intervals of 30 seconds. This generates a fair amount of traffic. When a router receives a neighbor's RIP table, it uses the information provided to update its own routing table and then sends the updated table to its neighbors. This procedure is repeated until all routers have a consistent view of the network topology. Each router ends up with a model of the network. Once this occurs, the network has achieved convergence, as shown in Figure 7.4.

The routers use the model to figure out the shortest route to use to send a particular packet to its destination.

Achieving Network Convergence with RIP

Each router is assumed to have a routing table. Each entry contains at least the following types of information:

• Destination–The IPv4 destination address or the IPv6 prefix of the destination

• Metric–A metric representing the total cost of getting a datagram from the router to the specified destination. This metric is the sum of the costs associated with the networks that would be traversed to get to the destination.

• Next router address–The address of the next router or hop on the path to the destination

• Route change flag–A flag indicating that information about the route has changed recently

• Timers–Assorted timers associated with the router such as timers used to signal the sending of the complete routing table to every neighboring router.

The metric for a directly connected network (usually 1) is set to the cost of that network. In some case, depending on the implementation of the routing protocol, the network administrator can enter static routes for networks outside the scope of the routing system.

Generally a routing protocol maintains only the best route to a destination. When new information provides a better route, it replaces old route information. When implementing a routing protocol, every router in the AS needs to participate in the protocol in order to receive complete routing information. Some ASs have multiple interior routing protocols in use. In this case, there must be at least one router that can provide routing information between the protocols.

Routing Protocol Metrics

The metric is one of the units a routing protocol uses to help a system determine the best route. Metrics can be based on hop count, routing delay, or an arbitrary value set by the system manager depending on the type of routing protocol in use. Routing metrics can influence the value of assigned internal preferences.

Table 7.3 shows the range of possible values for some routing protocol metrics and the value used by each protocol to reach a destination. If a metric equals the value shown in Table 7.3 in the unreachable column, the router cannot route the packet to the destination node using the specified routing protocol.

Routing Protocol Metrics

Protocol Metric Represents Metric Range Unreachable

RIP distance (hop-count) 0 -15 16

Hello delay (milliseconds) 0 -29999 30000

OSPF cost of path dimensionless Delete

ISIS cost of path 0 - 254 Delete

EGP distance (unused) 0-65535 255

BGP unspecified 0-65534 65535

Multicast Routing

Routing multicast traffic is more complex than routing unicast traffic. Individual hosts use IGMP to let their subnet router know they are joining a multicast session. It is an inefficient use of bandwidth for routers to send a separate copy of the data to each receiving subnet because many of the data streams would follow the same path throughout much of the network.

A multicast address identifies a particular transmission session, rather than a specific physical destination. The source does not need to know all the relevant addresses.

The number of receivers for a multicast session can be quite large. The network routers must be able to translate multicast addresses into host addresses. In multicast routing, routers interact to exchange information about neighboring routers. The group management protocol selects a single router as the Designated Router (DR) for each physical network. The DR is usually the closest router to the root (see Figure 7.5). Selecting a DR avoids duplication of effort.

Choosing a Designated Router

By using the multicast routing protocols, a multicast-capable router dynamically builds multipoint route trees using the group membership information learned from IGMP communications. These multipoint route trees map paths from a sender to all receivers. To support multicasting, a router needs to support at least one of the multicast routing protocols.

There is more information available for engineers interested in evaluating or implementing IP multicast for an organization, product, or service and needing to know about the distinguishing features of the routing protocols. For this information, review "Introduction to IP Multicast Routing A technical overview of IP Multicast routing protocols and their features" by Vicki Johnson and Marjory Johnson for the IP Multicast Initiative (IPMI). This white paper is available at http://www.ipmulticast.com/community/whitepapers/introrouting.html

Multicast Routing Choices

The network layer supports multicast communications by providing:

• Class D addresses for IPv4 implementations and the unique multicast addressing for IPv6 implementations. In addition, the network layer provides a mechanism to map the multicast address onto the data-link layer multicast address structure. A value of FF (11111111) identifies an IPv6 address as a multicast address. Figure 7.6 shows the IPv4 and IPv6 multicast address formats.

IPv4 and IPv6 Multicast Address Format

A dynamic mechanism for a computer to register with the network that it is a member of a particular group. This lets network routers know which networks need to receive traffic for each group. RFC 1112 and RFC 2236 define Version 1 and 2 respectively of IGMP that specify how the host should inform the network that it is a member of a particular multicast group.

• A multicast routing mechanism that lets the network build packet distribution trees for a source to send packets to the group membership. A primary goal of these trees is to ensure that each packet exists only one time on any given network.

Routing Standards

The IETF has been developing several standards for routing IP multicast traffic:

• RFC 1075 defines the Distance Vector Multicast Routing Protocol (DVMRP)

• RFC 1584 defines the Multicast Open Shortest Path First (MOSPF) protocol, an extension to OSPF that allows support of IP Multicast

• RFC 2117 defines the Protocol Independent Multicast-Sparse Mode (PIM-SM) protocol, one of two protocols describing PIM originally conceived by Cisco Systems.

• Protocol Independent Multicast-Dense Mode (PIM-DM) is currently an Internet standards-track draft.

Basic Approaches to IP Multicast Routing

The IP multicast protocol transmits IP multicast traffic for a source-and-destination-group pair over a spanning tree that connects all the hosts in the group. The construction method of the multicast spanning trees varies among the IP multicast routing protocols. Once the multicast-capable routers construct a tree the protocols distribute all multicast traffic over it.

IP Multicast routing protocols generally follow one of two basic approaches: dense mode and sparse mode.

The Dense-Mode Approach to Multicast Routing

Dense mode assumes that the multicast group members are densely distributed throughout the network with many subnets containing at least one group member. Dense mode is also characterized by plentiful bandwidth. Dense-mode routing protocols include DVMRP, MOSPF, and PIM-DM.

Dense-mode multicast routing protocols rely on a technique called flooding to propagate information to all network routers.

The Sparse-Mode Approach to Multicast Routing

Sparse mode assumes the multicast group members are sparsely and distributed throughout the network and bandwidth is not necessarily widely available. In sparse mode users could be scattered across many regions of the Internet or users could be connected through ISDN lines.

Because users are widely dispersed, flooding would unnecessarily waste network bandwidth and could cause serious performance problems. Sparse-mode routing protocols include:

Core-based Trees (CBT) and PIM-SM.

It is important to note that sparse mode does not imply that the group has a few members, just that they are widely dispersed.

Multicast Algorithms

Multicast routing protocols construct the multicast datagram delivery trees and forward multicast datagrams over those trees. Different protocols may use different algorithms to construct their delivery trees. All of the IP multicast routing algorithms and protocols are rapidly evolving. The following sections briefly describe some of these algorithms and protocols. As stated previously in this chapter:

• Dense-mode multicast routing protocols rely on some sort of flooding to propagate information to all network routers

• Sparse-mode multicast routing protocols rely on selective techniques to set up and maintain multicast trees.

Flooding

This is the simplest of the forwarding algorithms. Implementing a flooding algorithm is the easiest way to deliver multicast datagrams to all the routers in an internet. Here is what happens with a flooding algorithm (see Figure 7.7):

1) A router receives a datagram addressed to a multicast group

2) The router uses a protocol mechanism and determines if this is the first time it has seen this particular datagram:

• If this is the first time the router has seen this datagram, the router forwards the datagram on all interfaces except the one on which it arrived. This guarantees that the multicast datagram gets to all the routers.

• If the router has seen the datagram before, it discards the datagram.

Example of Flooding Algorithm and a First-Time Seen Datagram

When a protocol uses a flooding algorithm, the router only needs to keep track of the most recently seen datagrams. A router does not have to maintain a routing table if a flooding algorithm is used. However, there are some disadvantages of using a flooding algorithm:

• Flooding does not scale well for the Internet

• The algorithm does not work for WANs because it generates a large number of duplicate packets

• Flooding uses all available paths across the internetwork instead of just a limited number. Traffic on all paths in the network can easily lead to congestion.

• Flooding uses router memory inefficiently because each router has to maintain a table entry for each recently-seen packet.

Spanning Trees

Tree construction is a popular and efficient multicast routing solution. Indeed, spanning-tree routing has become the standard routing protocol for IEEE 802 LANs at the data-link layer. A spanning tree defines a tree structure in which a single path connects any two routers on the Internet or intranet. Using a spanning-tree algorithm can eliminate loops in the network topology.

Loops in the Network Topology

Loops occur when datagrams can follow more than one path to get from one point to another point on the same network. If there is a loop in an extended network, bridges and routers can forward traffic indefinitely, which can result in increased traffic and degradation of network performance.

Figure 7.8 shows an example of a network containing a loop where two forwarding devices, not one, connect LANs A and B. In this example, Station B can reach Station A through either forwarding device 1 or forwarding device 2.

Example of a Network Containing a Loop

Implementing a Spanning Tree Algorithm

Implementing a spanning tree algorithm that produces a logical tree topology out of any arrangement of forwarding devices solves the problem of looping. The result of a spanning tree is a single path between any two endstations on an extended network.

The steps in forming a spanning tree consist of:

1) Choosing a root forwarding device–Each forwarding device begins by assuming it is the root, and tells everyone else connected to it that it is the root.

Generally the device that has the lowest priority value becomes the root. If priority values are equal, the device with the lowest MAC address becomes the root.

2) Determining the path costs–If a forwarding device hears about another, better bridge, it stops telling everyone else it is the root and starts telling everyone else about the better device.

3) Selecting a root port and electing a designated forwarding device on each LAN–Eventually, everyone agrees on the best forwarding device, and that device becomes the root.

A root port of a device offers the lowest-cost path to the root-forwarding device. In the event of equal path costs, the port interface with the lowest interface priority becomes the root port. If the paths' interfaces to the root are also equal, then the port on the device with the lowest priority value becomes the root port.

4) Electing a designated port (router) for each subnet–Generally the spanning tree algorithm selects the port that connects the designated forwarding device to the LAN as the designated port. Typically this is the device on the subnet closest to the root.

Each forwarding device deactivates ports in such a manner that there is only one path from any given point on the network to the root. All loops have now been eliminated.

The spanning tree algorithm removes all redundant ports. Figure 7.9 shows the results of a spanning tree algorithm that provides a loop-free topology with only a single path between any two hosts.

Spanning Tree Loop-Free Logical Topology

Once the spanning tree exists, a multicast router can forward multicast datagrams to all interfaces in the spanning tree except the one from which the datagram arrived.

Chuck Semeria and Tom Maufer in their white paper "Introduction to IP Multicast Routing" say "A spanning tree solution is powerful and is relatively easy to implement since there is a great deal of experience with spanning tree protocols in the Internet community. However, a spanning tree solution can centralize traffic on a small number of links, and may not provide the most efficient path between the source subnetwork and group members."

The Optimized Engineering Corporation has put together a collection of essays and papers on technical issues for networking professionals called "The Optimized Engineering Technical Compendium." Located at http://www.optimized.com/tech_cmp/index.html this series of articles can be used as a reference tool and as a means for networking professionals to enhance their general knowledge of networking technology.

Constrained Steiner Trees

Multicast datagrams are forwarded in parallel to routers along the branches of the tree. Duplication of a datagram only occurs at the forks in the tree. The minimum average path delay and the cost of the multicast tree optimize such a tree.

The average path delay is the average of the minimum path delays from the source to each destination in the multicast group.

A Constrained Steiner Tree (CST) is a delay-bounded minimum-cost tree. Several things occur in construction of a CST. First, it is assumed that the source has all the information necessary to construct the tree, then the protocols:

• Determine the constrained cheapest path from the source to every destination group member

–Each path minimizes the average delay path

–Each path has a delay less than the delay-bound constraint

• The CST algorithm constructs the constrained spanning tree where there is only one active path between any two routers on the subset of the Internet.

When a multicast datagram enters a multicast router, the router forwards the datagram to all interfaces that are part of the spanning tree except the one from which the packet arrived. This method guarantees that no datagram loops back and that the datagram reaches all routers on the tree.

Reverse-Path Broadcasting

This algorithm builds a group-specific spanning tree for every possible source on a subnetwork. Building a group-specific spanning tree could provide an efficient path between the source subnetwork and group members. Such a spanning tree is rooted from the subnetwork that directly connects to the source. This means there is a spanning tree for every active source-group pair. Routers use the Reverse Path Broadcasting (RPB) algorithm to construct these source-rooted trees (see Figure 7.10).

Reverse Path Broadcasting Spanning Tree

RPB constructs a different spanning tree for each active source-group pair. It is reasonably efficient and easy to implement.

Operation of RPB

When a source sends its first multicast packet to the group, routers create the source-rooted tree. For each source-group pair the router forwards the multicast datagram on all outgoing interfaces if the datagram arrives by way of the shortest path from the source (the parent link). Otherwise the router discards the datagram. Routers forward multicast datagrams over outbound links called child links (see Figure 7.11).

Reverse Path Broadcasting-Forwarding Algorithm

A link-state routing protocol uses its topological database to determine whether a neighboring router on a possible child link considers the local router to be on its shortest path back to the source.

A distance-vector routing protocol can use a neighbor's advertised previous hop for the source-group pair or poison reverse the route to determine if a downstream neighboring router considers the local router to be on its shortest path back to the source.

Example RPB

In order to reduce duplicate packets, there is an enhanced version of this algorithm. In our example RPB implementation the source connects to Router A as shown in Figure 7.12. In this case Router B:

• Receives a datagram from Router A and considers Link 1 to be the parent link for the source-group pair

• Forwards the datagram on Link 4, Link 5, and any local leaf subnetworks that have group members

• Knows from routing message exchanges that Router C considers Link 2 as its parent link for the source-group pair and does not forward the datagram on Link 3.

Router C would drop a datagram coming over Link 3 because it would be arriving on a non-parent link for the source-group pair.

Example of Reverse-Path Broadcasting

When it builds the distribution tree for the source group pair, the RPB algorithm does not consider multicast group membership. This means that a subnetwork that has no group members might unnecessarily receive datagrams.

This enhancement works well with a link-state protocol since each router maintains information on the entire routing domain.

Truncated Reverse-Path Broadcasting

This algorithm improves upon RPB's limitations: RPB does not take into account group memberships when building its source-group spanning tree. This means that multicast datagrams can be forwarded to subnetworks that have no members for that particular group.

The Truncated Reverse Path Broadcasting (TRPB) algorithm uses IGMP to determine the group memberships on each leaf subnetwork. Once group membership is known, TRPB avoids forwarding datagrams onto a leaf subnetwork which does not have a member of the destination group present. The router truncates the spanning delivery tree if a leaf subnetwork does not have group members. This process of excluding interfaces not in the shortest path tree is called "pruning."

A router using TRPB is called the parent of a network if it is responsible for forwarding datagrams onto that network through its interface. Only the parent router forwards multicast packets from the source over to the destinations.

Identifying a Leaf Network

Routers at the edge of the network with no further downstream routers in the TRPB tree are called leaf routers. RFC 1075 describes in detail how a multicasting routing protocol can determine whether a network is a leaf. Routers can determine if any group members reside on a network because group members periodically announce that fact by sending IGMP group membership messages to their local router.

Once the protocols determine that a leaf network does or does not have group members, they propagate this information up the shortest path tree:

• The router augments the pairs it sends to its neighbors with the set of groups for which the leaf network is interested in receiving multicast datagrams

• The protocols propagate the information from router to router so that for each of its links, a given router knows to which groups it should forward multicast datagrams.

Example of TRPB

In our sample TRPB implementation the source connects to the router through the parent link as shown in Figure 7.13. Members of multicast groups 1 (G1), 2 (G2), and 3 (G3) are associated with forwarding devices downstream from the router.

When the router receives a multicast datagram for the source, G1 pair, the router:

• Forwards the datagram on Interface 2 because this interface has at least one member of Group 1.

• Forwards the datagram on Interface 3 if, and only if, a downstream router considers Interface 3 part of its parent link for the source, G1 pair.

• Does not forward the datagram on Interface 4. This interface has no members in the destination group.

Truncated Reverse-Path Broadcasting

TRPB eliminates unnecessary traffic on leaf subnetworks but does not consider group memberships when building the branches of the distribution tree.

Reverse-Path Multicasting (RPM)

RPM is an enhancement algorithm to RPB and TRPB. Specifically, it is a multicasting technique in which a router forwards a multicast datagram out of all but the receiving interface if the receiving interface is one used to forward unicast datagrams to the source of the multicast datagram.

In other words, RPM creates a delivery tree that spans only subnetworks with group members and routers and subnetworks along the shortest path to subnetworks with group members. RPM prunes the source-rooted spanning tree so that the routing protocols forward datagrams only along branches that lead to members of the destination group.

Operation of RPM

A multicast router uses the TRPB algorithm and forwards the first datagram it receives for a source-group pair to all routers in the internetwork. The TRPB algorithm guarantees that each leaf router receives the first multicast datagram (see Figure 7.14).

If the leaf router Then the leaf router

Has a group member on any of its subnetworks Uses the IGMP information it has about the group member and forwards the datagram based on that information

Has no group member on any of its subnetwork Uses a prune message and informs the upstream router that it should not forward datagrams for that source-group pair on the interface over which the upstream router is receiving the prune message

An upstream router receiving a prune message stores that information. If the upstream router receives prune messages on all of its child links, then the process repeats itself on up the tree. This process generates a multicast tree that only has branches to active group members.

The protocols refresh the multicast tree from time to time and when this occurs, each router clears all of its prune messages from memory. The router forwards the next multicast datagram it receives to all of its child links. This starts anew the process of defining the multicast tree.

Reverse Path Multicasting

RPM Limitations

As mentioned before, the dynamic nature of group membership means that the trees periodically need refreshing. This in turn means that multicast datagrams must be periodically forwarded to every router in the internetwork. This can present scaling problems for an Internet-wide delivery service. In addition, each router must keep state information about groups and sources. While this might not be a problem with a small number of groups and sources, it could present significant concerns if the number of sources and groups in the multicast internetwork expands.

Shortest-Path Trees

An example of an unconstrained multicast routing algorithm, the Shortest-Path Trees (SPT) algorithm constructs a spanning tree from the source to all the destination group members. It minimizes a given cost without considering the Qos requirements. For example, it might minimize the end-to-end delays or the number of hops. STP uses an algorithm such as Dijkstra's shortest-path algorithm or the Bellman-Ford algorithm to minimize the cost function.

Core-Based Trees

The Core-Based Trees (CBT) algorithm builds one delivery tree shared by all the group's senders and receivers instead of building a single tree for each source-group pair. With a CBT implementation, routers send the multicast traffic over the same delivery tree regardless of the source.

CBT is a relatively new architecture described by A. Ballardie in RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture", September 1997. It is progressing through the IDMR working group of the IETF.

The primary advantage of the shared-tree approach is that it typically offers more favorable scaling characteristics than do the other multicast algorithms. Figure 7.15 illustrates a core-based tree. On the other hand, CBT can result in traffic concentration and bottlenecks near core routers. This is because traffic from all sources traverses the same set of links as it approaches the core.

RFC 2189, also by Ballardie, describes the CBT protocol as a network layer multicast routing protocol. The protocol is designed to build and maintain a shared multicast distribution tree that spans only those networks and links leading to interested receivers. The sending and receiving of multicast data by hosts on a subnetwork conforms to the traditional IP multicast service model.

A CBT tree can be a single core or a multi-cored tree depending upon the size of the group. In CBT, a core router is one that acts as a meeting point between a sender and group receivers. The CBT protocol described in RFC 2189 uses the term rendezvous point (RP) to mean the same thing.

A router that is part of a CBT distribution tree is known as an "on-tree router" and maintains active state for the group.

Multi-Core CBT Multicast Delivery Tree

CBT Design Goals

The CBT multicast routing architecture outlines four major design goals:

1) CBT is scalable. It uses low memory and has low bandwidth processing requirements. Because CBT does not incur source-specific state, it is particularly suited to many sender applications.

2) CBT is a robust multicast routing algorithm. Core placement is optimized to provide for a robust multicast delivery tree

3) CBT protocol is relatively simple compared to most other multicast routing protocols. This simplicity can lead to enhanced performance compared to other protocols.

4) CBT is routing-algorithms and protocol-independent. It can be installed anywhere and allows for interdomain multicast routing. CBT has well-defined interoperability mechanisms with DVMRP, the protocol that currently interconnects a collection of heterogeneous multicast regions.

Operation

When a host wishes to become a member of a group a number of steps occur.

• The host multicasts an IGMP host membership report across its attached link

• A local CBT-aware router invokes the tree-joining process by:

–Generating a JOIN_REQUEST message

–Sending the message to the next hop on the path toward the group's core router

• The core router, or another router on the path between the sending router and the core, explicitly acknowledges the message

• The join message sets up a transient join state in the routers it traverses consisting of group, incoming interface, and outgoing interface. All intermediate routers process this join request. They:

–Identify from which interface the join request was received

–Define the CBT delivery tree to that host

• The transient state eventually times out unless it is "confirmed" with a join acknowledgment from upstream. The join acknowledgment traverses the reverse path of the corresponding join message and can do so because of the presence of the transient join state.

• Once the acknowledgment reaches the router that originated the join message, the new receiver can receive traffic sent to the group.

If a host wishes to be a source for a group, but is not a member of that group, it unicasts the datagram toward the core router. When the datagram reaches a router that is a member of the CBT tree, that router multicasts the datagram the rest of the way.

CBT Limitations

There are a few limitations with implementing CBT. Network congestion can occur with CBT because hosts use the same set of links to send messages and datagrams to the core router. In addition, CBT might not be suitable for real-time applications because as the number of groups increases, a shared delivery tree can lead to an increased end-to-end delay.

CBT assumes the existence of a multicast core-assignment service that manages the core routers and determines the placement of major and minor cores. Such a service requires global topology information to make optimal placement decisions.

Backward Forward
Chapter: Preface | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.
Beta Books | Beta Bookstores | Computing McGraw-Hill

Professional Publishing Home | Contact Us | Customer Service | For Authors | International Offices | New Book Alert | Search Catalog/Order | Site Map | What's New

A Division of the McGraw-Hill Companies
Copyright © 1998 The McGraw-Hill Companies, Inc. All rights reserved. Any use is subject to the Terms of Use the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers.


Marcus Goncalves
$55.00 0-07-913791-1 		Backward
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Chapter Eight

Multicast Routing Protocols

Multicast IP networks are network-layer-(Layer 3) router networks. Routers use routing algorithms to determine the best route for a datagram to travel through the network from its source to its destination. At a basic conceptual level, major multicast forwarding protocols use one of two techniques:

• Source-Rooted Trees—When a source-rooted tree (SRT) protocol is in use, a tree connects each source within a group to the members of its group. SRT links create direct paths to join the multicast source to its downstream receiver. Once a source-rooted tree exists for a multicast source and it group members, all traffic to the members of the group passes along this tree. Both the DVMRP and MOSPF protocol use source routed trees algorithms. The Internet Mbone uses DVMRP as the routing protocol for the Mbone.

• Shared Trees—Shared-tree multicast delivery is for sparsely populated multicast groups that may have low-grade network connections. Shared-tree multicast forwarding paths rely on a central core router that is a rendezvous point between multicast sources and destinations. The core router forwards the multicast datagrams through a shared tree to the members of the group. Shared trees use only a single tree between all sources and receivers of a given multicast group. The CBT protocol and the PIM-SM protocols are examples of shared trees.

Using these routing protocols, multicast-aware routers take the group membership information learned from IGMP communications and dynamically build multipoint route trees.

This chapter briefly:

• Reviews the characteristics of dense- and sparse-mode multicasting and examples of routing protocols that support each mode

• Introduces the DVMRP, one of the dense-mode protocols

• Summarizes the MOSPF protocol, one of the dense-mode protocols

• Introduces the PIM-DM protocol

• Describes two sparse-mode protocols: PIM-SM and CBT.

Group Membership Protocol

Routers use a group membership protocol, usually the IGMP to learn about group members on subnets that are directly connected to the router.

When a host joins a multicast group, it sends a message to its local router that it wants to receive group messages for specified groups. The host then sets its IP process and network interface card to receive frames addressed to the multicast group.

This process for joining a group scales well. As the multicast group increases in size, new group members more likely can locate a nearby branch of the multicast distribution tree. Refer to Chapter 6 for a detailed description of IGMP.

Sparse-Mode Multicast Routing

Sparse-mode multicast routing protocols must rely on selective techniques to set up and maintain multicast trees. Sparse-mode protocols use a receiver-initiated process to construct a multicast distribution tree. This means a router constructs the multicast distribution tree only when one of the hosts on its subnet requests membership in a particular multicast group.

Dense-Mode Multicast Routing

A dense mode multicast routing protocol assumes that the multicast group members are densely distributed throughout the network. With dense mode many subnets containing at least one group member and bandwidth is plentiful. Most dense mode multicast routing protocols use source-rooted tree based routing algorithms. Dense-mode routing protocols include: DVMRP, MOSPF, and PIM-DM.

Distance Vector Multicast Routing Protocol

The DVMRP is an interior gateway protocol suitable for use within an autonomous system, but not between different autonomous systems. DVMRP is based on the public domain routed program and many vendors implement it in their equipment. Of the multicast routing protocols, DVMRP has been around the longest and is currently the most widely used. DVMRP is specifically for forwarding multicast datagrams through an internetwork.

Developers originally derived the DVRMP specification from the Routing Information Protocol (RIP). The original specification used the TRPB algorithm briefly described in Chapter 7.

To calculate the best path to the destination DVRMP uses the previous hop back to the source as the metric. To calculate the best path to the destination, RIP uses the next hop to the destination as the metric.

Vendor implementations have extended DVMRP implementations to use variants of the RPB algorithm. Some implementations use the Reverse Path Multicasting (RPM) algorithm to construct a source-rooted multicast delivery tree. The latest DVMRP implementations can be quite different from the original RFC specification. When building the source-rooted tree, a DVMRP-enabled router floods datagrams out to all interfaces except the one that leads back to the datagrams source.

When selecting a DVRMP implementation for multicasting routing, make sure the implementation supports DVMRP prune messages; implementations of DVMRP might not.

Tunneling DVMRP into unicast IP datagrams that are then sent over the Internet is the basis for the popular Mbone. The Mbone is the multicast backbone on the global Internet. There is wide spread use of the Mbone by the research community for such things as desktop conferencing and the dissemination of conference proceedings. Live concerts have even been "broadcast" over the Mbone. DVMRP routers are required to run separate routing processes for unicast and multicast packets.

DVMRP Datagrams

A DVMRP datagram consists of two portions: a small, fixed-length IGMP header, and a stream of tagged data as shown in Figure 8.1. DVMRP uses IGMP to exchange routing datagrams.

DVMRP Message Format

In this datagram the version is 1 and the type for DVMRP is 3. The subtype is one of the values listed in Table 8.1.

DVMRP Subtype Values

Value Description

1 Response; the message provides routes to some destination(s)

2 Request; the message requests routes to some destination(s)

3 Non-membership report; the message provides non-membership report(s)

4 Non-membership cancellation; the message cancels previous non-membership report(s)

Excluding the IP header, the checksum is the 16-bit ones complement of the ones complement sum of the entire message. Zero the checksum field for computing the checksum.

The remainder of the DVMRP message is a stream of tagged data that provides extensibility and reduces the amount of redundant data in a message. Elements in the stream, called commands, are multiples of 16 bits. Table 8.2 lists and describes these commands. The length of DVMRP messages is limited to 512 bytes, excluding the IP header.

Tagged Data Commands

Value Command Description Other Commands Allowed in Same Message

0 NULL Provides additional alignment or padding to 32 bits Null, AFI, Subnetmask, Metric, Flags0, Infinity, DA, RDA, NMR, NMR-cancel

2 Address Family Indicator Provides the address family for subsequent addresses in the stream Null, AFI, Subnetmask, Metric, Flags0, Infinity, DA, RDA, NMR, NMR-cancel

3 Subnetmask Provides the subnet mask to use for subsequent routes. Bits 0 through 7 must be 1, and all of the bits must not be 1 Null, AFI, Subnetmask, Metric, Flags0, Infinity, DA, RDA

4 Metric Provides the metric to subsequent destinations. The metric is relative to the router that sent this DVMRP routing update Null, AFI, Subnetmask, Metric, Flags0, Infinity, DA

5 Flags0 Provides a way to set a number of flags. This is an experimental command that may be changed in the future Null, AFI, Subnetmask, Metric, Flags0, Infinity, DA

6 Infinity Defines the infinity for subsequent metrics in the stream Null, AFI, Subnetmask, Metric, Flags0, Infinity, DA

7 Destination Address Provides a list of destinations Null, AFI, Subnetmask, Metric, Flags0, Infinity, DA

8 Requested Destination Address Provides a list of destinations for which routes are requested Null, AFI, Subnetmask, Flags0, RDA

9 Non Membership Report This experimental command tells the receiving router that the sending router has no descendent group members in the given group Null, AFI, Flags0, NMR

10 Non Membership Report Cancel This experimental command cancels any previous corresponding non-membership reports each listed multicast address Null, AFI, Flags0, NMR-cancel

Physical and Tunnel Interfaces

DVMRP-capable routers can have ports with a physical interface to a directly attached subnetwork or a tunnel interface to another multicast island. The configuration of the interfaces of a DVMRP router consists of a metric that provides the cost of the interface and a Time-to-Live (TTL) threshold to limit the extent of the transmission.

Pruning the spanning tree involves the metric and the TTL values. The configuration of each tunnel interface consists of two additional parameters: the IP address of the local router's interface and the IP address of the remote router's interface.

A tunnel is a method for sending datagrams between multicast-capable routers separated by other routers that do not support multicast routing. The multicast-capable router lightly encapsulates a normal multicast datagram in a unicast datagram and forwards it across the internetwork.

Each tunnel has a local endpoint, remote endpoint, metric, and threshold. Routers at each end of the tunnel only have to agree upon the local and remote endpoints.

The protocols replace the IP source address of the datagram with the address of the local tunnel endpoint and replace the IP destination address with an address of the remoter router at the tunnel endpoint. Intermediate, non-multicast gateways route the encapsulated datagram to the remote tunnel endpoint.

When a multicast datagram leaves the tunnel, the multicast router strips off the encapsulation and processes the datagram. As shown in Figure 8.2, a tunnel allows multicast traffic to pass seamlessly between two multicast routers connected by unicast routers.

IP Tunneling

Any ICMP error messages go to the originating multicast router. Hosts should not be aware of the use of a tunnel by a multicast router. If the protocol did not change the datagram's IP source address when encapsulating the datagram, any ICMP errors would go to the originating host.

Two types of tunneling schemes exist: truncated and pruned.

Truncated Tunneling

This was the first type of tunneling, used in the early stages of the Mbone. With truncated tunneling, routers forward datagrams based on the TTL value of the datagram and the threshold value of the multicast-capable router. When a multicast datagram is forwarded through a multicast router, the router decreases the TTL value of the datagram by one.

There is a threshold value for each multicast router that corresponds to a TTL value. If the threshold value is less than the TTL value, the router decreases the TTL value and forwards the multicast datagram. When the threshold value exceeds the TTL value, the router does not forward the multicast datagram. The use of a datagram's TTL value and a router's threshold value limits the range of a multicast packet.

To reiterate, multicast routers only forward a multicast datagram across an interface if the TTL field in the IP header is greater than the TTL threshold assigned to the interface. Table 8.3 lists the TTL values that restrict the scope of an IP multicast.

TTL Scope Control Values

Initial TTL Scope

0 Restricted to same host

1 Restricted to same subnetwork

32 Restricted to same site

64 Restricted to same region

128 Restricted to same continent

255 Unrestricted in scope

Pruned Tunneling

With a pruned tunneling scheme, routers forward multicast datagrams based on their TTL values. However, multicast routers use IGMP messages to determine which routers are to receive the particular datagrams. In other words, the multicast traffic goes only to routers that express an interest in receiving it.

Pruning

DVMRP implementations usually use the RPM algorithm to forward multicast datagrams. The protocol forwards the initial datagram for a source-group pair to all routers if their TTL thresholds permit. Then, pruning begins.

Flooded multicast datagrams eventually reach all members of the multicast group. During the flooding process a downstream multicast-capable router might receive a multicast datagram destined for a group that does not reside on any of its interfaces. When this happens the router sends a prune message to the nearest upstream neighbor. A pruning message is group-specific and tells the upstream router that there are no group members on that interface and not to forward multicast datagrams down that path of the tree (see Figure 8.3). This creates a source-specific shortest-path tree with all leaves having group members.

If multiple groups reside on the interface, a pruning message can block datagrams destined for one group but not for the other groups.

After a given amount of time DVMRP refloods in order to reach any new hosts that want to receive a particular group. Additionally, a host residing on a pruned branch of a tree can send a group membership IGMP message to the router. When this occurs the router cancels any previous prune messages and allows multicast traffic for the target group to flow immediately to the new member.

Pruning a Branch of a Multicast Delivery Tree

DVMRP Router Functions

When a DVMRP router initializes, it considers itself the dominant router for the local subnet until it receives a Host Membership Query message from a neighbor router with a lower IP address. In order to avoid duplicate multicast datagrams when there is more than one DVMRP router on a subnetwork, one router is elected the designated router for the particular source subnetwork.

If there is more than one DVMRP router on the subnet, the routers choose the router with the lowest IP address as the designated router (see Figure 8.4). The designated router is responsible for the periodic transmission of IGMP Host Membership Query messages.

DVMRP Designated Router

Figure 8.5 shows multicast routers 1, 2, and 3. In this example, Router 3 is downstream and can receive multicast datagrams from the source subnetwork from Router 1 or Router 2.

Router 1 is dominant to Router 2 for the source subnetwork if the metric for Router 1 to the source subnetwork is lower than Router 2's metric. In this case, Router 1 forwards traffic from the source subnetwork while Router 2 discards traffic from the source subnetwork.

When Router 1 and Router 2 have equal metrics, the router with the lowest IP address on its child link, the downstream interface Router 3, becomes the dominant router.

DVMRP Dominant Router

DVMRP Routing Table

A multicast-capable router that supports DVMRP might need to run both multicast and unicast routing processes. The DVMRP process periodically exchanges routing table update messages with multicast-capable neighbors. To detect leaf routers, DVMRP relies on "poison reverse" updates. Receiving such an update for the source subnetwork on a downstream interface means the router keeps the downstream port on its list of forwarding ports.

As shown in Table 8.4 a DVMRP routing table contains Source Subnets and From-Gateways instead of Destinations and Next-Hop Gateways. The routing table represents the shortest-path source-rooted spanning tree to every participating subnetwork in the internetwork. A DVMRP routing table includes:

• Source Subnet–A subnetwork containing a host source for multicast datagrams.

• Subnet Mask–The subnet mask assigned to each Source Subnet

• From-Gateway–The previous-hop router leading back to the Source Subnet.

• TTL–The time-to-live in number of seconds before an entry is removed from the routing table. The TTL is used for table management.

DVMRP Routing Table

Source Subnet Subnet Mask From Router Metric TTL InPort OutPorts

128.1.0.0 255.255.0.0 128.7.5.2 3 200 1 2,3

128.2.0.0 255.255.0.0 128.7.5.2 5 150 2 1

128.3.0.0 255.255.0.0 128.6.3.1 2 150 2 1,3

128.4.0.0 255.255.0.0 128.6.3.1 4 200 1 2

DVMRP Forwarding Table

The DVMRP routing table does not consider group membership or received prune messages. Therefore DVMRP builds a forwarding table using a combination of routing table information, known-group information, and pruning messages. This forwarding table represents the shortest-path source-rooted delivery tree for each source-group pair. As shown in Table 8.5 a typical DVMRP forwarding table contains:

• Source Subnet–The subnetwork containing a host source for multicast datagrams addressed to the specified groups

• Multicast Group–The Class D IP address to which multicast datagrams are addressed.

• TTL–The time-to-live in number of seconds before an entry is removed from the routing table

• In Port–The parent port for the source-group pair

• Out Ports–The child ports over which the router forwards multicast datagrams for the source-group pair.

DVMRP Forwarding Table

Source Subnet Multicast Group TTL InPort OutPorts

128.1.0.0 224.1.1.1 200 1 2,3

224.2.2.2 100 1 2,3

224.3.3.3 250 1 2

128.2.0.0 224.1.1.1 150 2 2,3

Hierarchical DVMRP

The hierarchical DVMRP divides the Mbone into a number of individual routing domains. Each routing domain executes its own multicast routing protocol while routing between the individual domains uses another protocol, or another instance of the same protocol. Hierarchical routing:

• Reduces the demand for router resources

• Permits the deployment of different multicast routing protocols in each region of the Mbone

• Limits the effects of an individual link or router failure to those routers operating within a single domain

• Limits the effects of any change to the topological interconnection of regions to interdomain routers

• Limits the count-to-infinity constraints the maximum diameter of the Mbone topology to a single domain, not to the entire Mbone.

In hierarchical DVMRP each non-intersecting region has a unique Region ID. The routers within a region execute DVMRP as a Level 1 (L1) protocol. Each region has at least one boundary router that provides inter-regional connectivity. The boundary routers execute DVMRP as a Level 2 (L2) protocol for forwarding traffic between regions (see Figure 8.6).

Hierarchical DVMRP

L2 routers use Region IDs rather than the individual subnetwork addresses within the regions to exchange routing information. With hierarchical DVMRP, the protocol constructs an inter-regional multicast delivery tree based on the Region ID-group pair rather than the usual source-group pair.

Multicast Open Shortest-Path First

MOSPF Working Group of the IETF is responsible for the development of the MOSPF protocol. Portions of this work have been supported by DARPA under a NASA contract.

MOSPF is in RFC 1584 as a multicast-aware extension to the OSPF routing protocol. OSPF is an intradomain, link-state, hierarchical routing protocol. It provides fast rerouting and supports variable-length subnet masks and hierarchical routing within an autonomous system.

Autonomous systems can be divided into routing areas. A routing area is typically a collection of one or more closely related subnets. All areas must connect to the backbone area.

MOSPF provides the ability to forward multicast datagrams from one IP network to another through internet routers. MOSPF routes an IP multicast datagram based both on the source of the datagram and its multicast destination over the shortest path to each multicast destination. The protocol:

• Builds a shortest path at the source of the datagram and prunes from the tree all branches that do not contain multicast members

• Caches the results of the shortest-path calculation for use by subsequent datagrams that have the same source and destination.

• Replicates a multicast datagram only when the paths to the separate hosts diverge.

The MOSPF enhancements are backward-compatible. This means MOSPF-capable routers interoperate with non-multicast OSPF routers when forwarding unicast IP datagrams. However, MOSPF cannot tunnel multicast datagrams through non-multicast routers. Neither the MOSPF nor OSPF protocols encapsulated or decapsulate multicast or unicast datagrams as they transit an AS.

Intra-Area Routing with MOSPF

RFC 1584 describes the basic routing algorithm used by MOSPF that runs inside a single OSPF area. This algorithm supports multicast forwarding when the source and destination group members are in the same area and when the AS is a single area.

The path of the multicast datagram depends on the source network of the datagram and on the destination multicast group.

Local-Group Database

MOSPF supports a local-group database. Each entry in the database is a group-attached network pair. The local-group database keeps track of the group membership of the router's directly attached networks. MOSPF routers use the IGMP to build the local group database and monitor multicast group membership on directly attached subnetworks. Routers use the information in the local group database to decide onto which directly attached networks to forward an IP multicast datagram.

For example, building the local group database consists of the following steps:

• The designated router on an attached network sends periodic IGMP Host Membership queries on the network.

• Hosts send an IGMP Host Membership report for each multicast group to which they belong

• The designated router (DR) updates its local group database with the information contained in the group membership report

• The DR creates a separate group-membership link-state advertisement for each multicast group having one or more entries in the DR's local group database.

On any particular network, the DR is solely responsible for sending IGMP Host Membership queries and listening to IGMP Host Membership reports. This ensures that a network appears in the local group database of only one router and prevents the replication of multicast datagrams as they are delivered to local group members.

The designated router floods group-membership link-state advertisements in the OSPF area to inform all other routers about group memberships. This ensures that all remotely originated multicast datagrams are forwarded to the specified subnetwork for distribution to local group members.

Each router in an AS has a different local-group database. The local-group database facilitates the local delivery of multicast datagrams (see Table 8.6).

Sample Local-Group Databases

Router Local Group Database

RT1 [Group B, Network 1]

RT2 [Group A, N2], [Group B, Network 2]

RT3 [Group B, Network 3]

RT4 None

Shortest-Path Tree for Datagrams

The shortest-path tree for a datagram describes the path taken by a multicast datagram through the internetwork from the source subnetwork to each group member. The shortest-path tree of the datagram enables the delivery of multicast datagrams to distant group members who are not directly attached.

Routers use the shortest-path tree routing algorithm to construct the source-rooted shortest-path tree. Routers construct a separate tree on demand for each source-group pair. This means the tree is only built when the first multicast datagram is received having a particular source net–multicast destination combination.

MOSPF relies on IGMP to learn about hosts joining multicast groups. A local MOSPF-designated router keeps a database of directly attached members in each group

When an MOSPF-designated router learns about a new group member on its attached subnets:

• The router sends out a group membership Link-State Advertisement (LSA) message

• The protocol propagates the message to all other MOSPF routers within the OSPF area

• MOSPF routers add the group membership information contained in the LSA to the link-state database. To create a detailed map of the multicast topology (see Figure 8.7).

MOSPF LSA Propagation

When multicast data begins to flow from a source host, the MOSPF router use the multicast topologies stored in the router's enhanced link-state databases to compute forwarding paths. Routers only forward multicast packets to subnets that contain target group members.

When the initial datagram arrives:

• The router locates the source subnetwork in the MOSPF link-state database. The MOSPF link-state database adds group-membership link-state advertisements to the standard OSPF link-state advertisement database.

• The router uses the router link-state advertisement and network link-state advertisement and builds the shortest-path tree with the source network as the root.

• The router uses group-membership link-state advertisements to prune those branches that do not lead to subnetworks containing individual group members.

The protocol caches the results of this tree building process for future use. Figure 8.8 shows the shortest-path tree for a source-group pair. In this example, Router E's upstream neighbor is Router B. two downstream interfaces connect to Subnetwork 6 and Subnetwork 7.

Shortest-Path Tree

Forwarding Cache

MOSPF routers base their forwarding decisions on the contents of a data cache referred to as the forwarding cache. The protocols build a forwarding cache entry from two component pieces: the local group database and the shortest-path tree of the datagram. This tree, built on demand, is rooted at a multicast source of the datagram. The forwarding cache contains a separate entry for each source-destination combination. A cache entry indicates the neighboring upstream router or network from which the datagram must come and the downstream interfaces to which the datagram should be forwarded.

Each downstream interface in the cache has a TTL value that indicates the number of hops a datagram must travel to reach the next router or transit network requesting the multicast destination. To avoid wasting network resources, MOSPF capable routers do not forward a multicast datagram unless it can reach a multicast destination before the TTL expires.

Both the datagram shortest-path tree and the local-group database may contribute downstream interfaces to the forwarding cache entries. Such a downstream interface has a TTL of 1.

A MOSPF router clears its entire forwarding cache when the AS's topology changes. In addition, when the location of a multicast group's membership changes, all cache entries associated with the particular multicast destination group must be cleared.

Table 8.7 is an example of the forwarding cache entries built by routers in an AS for Source N4 and Destination Group A.

MOSPF Forwarding Cache

Router Upstream Nodes Downstream Interfaces (Interface:Hops)

RT10 Router RT6 (N6:1), (N8:2)

RT11 Net N8 (N9:1)

RT3 Net N4 (N3:1), (RT6:3)

RT6 Router RT3 (RT10:2)

RT2 Net N3 (N2:1)

Inter-Area Routing with MOSPF

Inter-area multicasting involves the behavior of the MOSPF protocol when the source of the datagram and some of its destination group members belong to different OSPF areas. While the calculation of the datagram shortest-path trees is different for MOSPF inter-area multicasting, the basic mechanisms for MOSPF inter-area multicasting are the same as for MOSPF intra-area multicasting; for example:

• The contents of the forwarding cache defines the forwarding of multicasts

• The MOSPF router builds the forwarding cache from the local-group database and the datagram shortest-path trees

• The forwarding algorithm is the same for both MOSPF intraarea and MOSPF inter-area multicasting.

Inter-Area Multicast Forwarders

In OSPF, area border routers forward routing information and datagrams between areas. MOSPF defines the function of an area border router so that a router on the border between two areas can forward multicast traffic bidirectionally. Border routers forward a controlled amount of group membership information and multicast traffic between adjoining areas. Border routers control how multicast-related LSA messages propagate through the Internet.

In MOSPF, border routers referred to as interarea multicast forwarders forward group-membership information and multicast datagrams between areas. An interarea multicast forwarder is a one of a subset of area border routes associated with an area. Whether a given OSPF area border router is also a MOSPF interarea multicast forwarder is dependent on configuration parameters and the capabilities of the particular router.

Interarea multicast forwarders summarize their attached areas' group membership information to the backbone in order to convey group membership information between areas. First the interarea multicast forwarder determines which groups have members in attached areas that are not part of its backbone area. Then the forwarder creates a group membership link-state advertisement in the backbone area for each of these groups (see Figure 8.9).

MOSPF summarizes a non-backbone area's group membership to the backbone but does not readvertise this information into other non-backbone areas.

Interarea Routing Architecture

MOSPF uses wild-card multicast receivers to ensure that all multicast traffic for a group is forwarded to group members in other areas. A wild-card multicast receiver is a router. All MOSPF multicast traffic should be forwarded to a wild-card multicast receiver. An interarea multicast forwarder in a non-backbone area acts as a wild-card multicast receiver. This ensures that all multicast traffic originating in a non-backbone area is forwarded to the backbone area.

The backbone area does not require wild-card multicast receivers because the routers in the backbone area have complete knowledge of group membership information for the entire OSPF system.

Interarea Datagram Shortest-Path Tree

When building datagram shortest-path trees it is not uncommon to find the multicast datagram source and at least some group members residing in separate areas. For interarea multicast routing, this can result in the building of incomplete datagram shortest-path trees; detailed topological information concerning one OSPF area is not distributed to other OSPF areas.

To compensate for these shortcomings, the protocol uses wild-card multicast receivers and OSPF summary-link link-state advertisements to make approximations of the topology. When the router initially constructs interarea shortest-path delivery tree the source subnetwork is located either in the same area as the router performing the calculation or in a different area.

When the source resides in the same area as the router doing the calculations, tree pruning must be carefully done so that the branches leading to other areas remain (see Figure 8.10). The local routers do not know if there are group members residing in other areas. The process prunes only those branches having neither group members nor wild-card multicast receivers.

Datagram Shortest-Path Tree Source in Same Area

When the source resides in a different area than the router doing the calculations, the immediate neighborhood of the source of the datagram is unknown. However, summary-link link-state advertisements in the area's link-state database indicate the cost of the paths between each of the area's interarea multicast forwarders and the datagram source.

The router uses the summary links to approximate the neighborhood of the source of the datagram and begins the tree with links directly connecting the source to each of the interarea multicast forwarders (see Figure 8.11). The interarea multicast forwarders must be included in the tree, since any multicast datagrams originating outside the local area enter the area through an interarea multicast forwarder.

The protocol requires that routers attached to multiple areas must calculate multiple trees and then merge them into a single forwarding cache entry for the source-group pair. After doing so, the routers discard the individual trees.

Datagram Shortest-Path Tree Source in a Remote Area

Stub Area Behavior

AS external links cannot approximate the neighborhood of the datagram's source in the shortest-path tree in the stub area. Stub areas do not import AS external links. Instead, routers forward into a stub area a datagram whose source resides outside the AS. Default summary links approximate the neighborhood of the source of the datagram. The stub area's intraarea multicast forwarders originate the default summary links.

In all other areas the construction of a stub area's datagram shortest-path trees functions for stub areas as it does for non-stub areas.

Inter-Autonomous System Multicasting with MOSPF

In inter-AS multicasting the source of a datagram and at least some of its destination group members reside in different ASs. It is possible for a MOSPF routing domain to serve as a core AS or backbone. This AS connects many different autonomous systems. In this situation, the majority of the MOSPF routers also act as inter-AS multicast forwarders.

Inter-AS multicast forwarders do not have to declare themselves wild-card receivers. Instead, the inter-AS multicast routers can use group-membership link-state advertisements and advertise all the groups they are interested in forwarding to other autonomous systems.

Core AS clients can advertise their group membership in the core. Such advertisements are asymmetric and the core does not advertise its or others' group membership to the clients. This achieves the same inter-AS multicast routing architecture that MOSPF uses for interarea multicast routing (see Figure 8.12).

The MOSPF standard defines the role for AS boundary routers, which forward multicast data and control information between domains and ASs.

Inter-AS communication can also refer to connectivity between an OSPF domain and another routing domain that could be within the same AS.

Interarea Routing Architecture

As with interarea shortest-path trees, different conditions can exist when the router initially constructs the inter-AS shortest-path delivery tree.

• The source subnetwork is located in the same area as the router performing the calculation

• The source subnetwork is located in a different area than the router performing the calculation.

• The source subnetwork is located in a different AS or in another routing domain within the same AS as the router performing the calculation.

The first two sets of conditions mirror the interarea examples described above except that inter-AS multicast forwarders are now included on the pruned shortest-path delivery tree.

AS border routers configured as inter-AS multicast forwarders determine if a datagram arriving at the multicast forwarder should be forwarded outside the local AS. Figure 8.13 shows a sample inter-AS shortest-path delivery tree with the source subnetwork and the router performing the calculation in the same area.

Inter-AS Datagram Shortest-Path Tree-Source in Same Area

Refer to Figure 8.14 for an example of an inter-AS shortest-path delivery tree where the inter-AS multicast forwarder resides in the same area as the router performing the calculation. If the inter-AS multicast forwarder is in a different area than the router performing the calculation, the router combines the summary-AS border-router link information and multicast-capable AS-external link information to approximate the topology surrounding the source.

Inter-AS Datagram Shortest-Path Tree-Source in Different AS

Protocol-Independent Multicast Protocols

Multicast routers use PIM to determine which other multicast routers should receive multicast packets. PIM has two simultaneously compatible modes of operation; dense mode and sparse, which are defined in separate protocols. RFC 2117, developed by the Inter-Domain Multicast Routing (IDMR) working group of the IETF describes PIM-SM. The protocol specification for PIM-DM is an IETF draft.

PIM Operation

PIM support is currently available in some router products. The intent of the PIM development effort is to provide for scalable interdomain multicast routing across the Internet. Routing based on PIM protocols is independent of the mechanisms provided by any particular unicast routing protocol. Any implementation supporting PIM requires the presence of a unicast routing protocol to provide routing table information and to adapt to topology changes.

Class D addresses are reserved for multicasting. An IP address identifies each multicast group.

Specifying the multicast group IP address as the destination address ensures that routers deliver multicast messages to all members of a group.

PIM Routing

Routers that support the PIM protocols are referred to as PIM routers. Two PIM routers are neighbors if there is a direct connection between them. PIM-enabled interfaces on routers connect either to neighboring PIM routers in the network or to host systems on a LAN.

Routers running the PIM protocol elect a PIM router adjacent to a host system as the designated router. Typically this router is the one with the highest IP address. PIM routing uses a shortest-path spanning tree algorithm. One PIM router exists at the root of each shortest-path tree while PIM routers with directly connected host systems are considered leaf routers.

PIM protocols do not define their own routing update messages; they also use the native unicast routing protocol the IP network runs on. This helps maintain additional state information to compensate for the unicast routing table not being multicast-aware.

PIM Forwarding

Both PIM-DM and PIM-SM use reverse-path forwarding. A router receiving a multicast datagram looks in its unicast routing table for the source of the datagram and the best path to back to the source. When the router receives a multicast datagram on the interface, for the best path back to the source, the router forwards a copy of the datagram on all of the other interfaces.

Refer to Chapter 7, for a discussion of the various forwarding algorithms

Datagrams arrive on the input interface and are considered to be upstream of the router. The datagrams forwarded on the output interface are considered to be downstream of the router.

PIM-Based Multicast Routing Tables

The PIM routers use assorted types of information from the routing table entry as shown in Figure 8.15 to construct a shortest-path spanning tree and maintain their multicast routing tables. When the root of a shortest path tree is the DR adjacent to the source of the datagram, the tree is a source-based tree, or source tree. Table 8.8 describes the fields in the routing table entry.

Source-Group Routing Table Entry Structure

Routing Table Entry Fields

Field Description

Source This field indicates the datagram's origin

Group This is the multicast group Class D IP address, in the range 224.0.0.0 through 239.255.255.255.

Register This field indicates that the designated router should register with the Rendezvous Point (RP) router datagrams with the same source and group address as this entry PIM-SM uses this field.

Rendezvous Point This field contains the IP address of the RP routed when the Register flag is set

Input Interface This field indicates the upstream network interface on which datagrams for this source-group are to arrive. The router does not forward datagrams that arrive on a different interface.

Output Interface This field contains the identifiers for the downstream interfaces over which datagrams for this source-group are to be forwarded.

Building a Source-Group Entry in a Source-Based Tree

Figure 8.16 is a pictorial representation of an entry in the routing table at a designated router. In this example Interface four is the input interface while Interface 1, 2, and 3 represent the output interface. S is set to the IP address of the source host and G is set to the IP address of the multicast group.

The designated router multicasts datagrams from the source to its downstream neighbors. Each downstream neighbor builds its own routing table entry, which lists the input interface as the interface connecting to the designated router and the output interface as the interfaces connecting to the downstream neighbors.

Source-Group Entry in a Source-Based Tree

Protocol-Independent Multicast–Dense Mode

The PIM-DM protocol multicast routing algorithm assumes a dense population of receivers in the network uses the reverse path multicasting algorithm. PIM-DM relies on the presence of an existing unicast routing protocol to adapt to topology changes, but it is independent of the mechanisms of the specific unicast routing protocol.

PIM-DM is useful when:

• Senders and receivers are close together with just a few senders and many receivers

• The volume of multicast traffic is high

• The stream of multicast traffic is constant.

PIM-DM builds the routing tree beginning at the source PIM router, and branches out across the network to all the leaf routers. If some areas of the network do not have group members, the PIM-DM routers prune the branches of the source tree for that group (see Figure 8.17). If multicast packets arrive on the interface that provides the shortest path back to the source, PIM-DM forwards those packets on all downstream interfaces until explicitly told not to by a prune message.

PIM Dense-Mode Operation

Protocol-Independent Multicast–Sparse Mode

The PIM-SM routing algorithm assumes that a sparse population of receivers exists in the network or that WANs separate the multicast groups. PIM-SM defines a centralized rendezvous point that links senders and receivers. There is only one PIM router configured as the RP for each multicast group that uses this protocol. The RP router maintains one shortest-path tree for each group it is responsible for. When a sender first sends data to the RP; when a receiver wants to receive data, it registers with the RP.

PIM-SM is useful when:

• There are few receivers in a group

• Senders and receivers are separated by WAN links

• Multicast traffic is intermittent.

When a source system sends a multicast datagram for a SM-PIM group, its designated router encapsulates the datagram and unicasts it through the network to the RP for that group. The RP then multicasts the datagram down the shared tree for that group (see Figure 8.18)

In PIM-SM, multicast datagrams are only transferred along paths to identified group member systems.

PIM Sparse-Mode Operation

The PIM specification allows receivers or routers to switch to a source-rooted shortest-path tree after the source starts multicasting (see Figure 8.19). This helps to reduce the inefficiencies of the shared tree.

Optimized Routing

The protocol permits up to three alternate RP routers as backups for the primary RP in case of failure. It lists alternate RP routers in order of preference. This ensures that the preferred router performs the role of the RP router.

Configure every PIM router in the network with the IP addresses of the RP routers for each of the PIM-SM groups The RP address information must be the same throughout the network.

When a source system wants to multicast data to a group:

• It sends the data packets onto its LAN

• The designated router creates a source-group entry in the routing table with which the source, group, and input interface. There is no output interface in this routing table entry

• It encapsulates the data in a PIM-Register message

• It unicasts the message to the RP for group.

The RP router:

• Unicasts back an acknowledgment, extracts the registered data, and checks to see if it has a shared tree group

• Forwards the datagram on the interfaces in the output interface list for that group

• Periodically unicasts register acknowledgments to the source-designated router. These messages indicate that the RP router is reachable.

Core-Based Trees (CBT)

Core-Based Trees (CBT) are most often referred to as forwarding algorithms. A CBT shared tree has a core router used to construct the tree. CBT constructs a single tree for all sources and members of the group instead of a single tree for each source-group pair (Figure 8.20). The protocol sends multicast traffic for the entire group over the same tree, regardless of the source. Senders do not need to be members of the group and group membership is dynamic. A CBT shared tree has a core router used to construct the tree.

A host wanting to become a member of a group sends a join request toward the core tree of that group. All intermediate routers process the request. They identify the interface on which the join request was received and define the CBT delivery tree to that host.

When a multicast datagram arrives at a router that is a member of the CBT tree, that router multicasts the datagram forward toward the core of the tree. This guarantees that the datagram is forwarded to all members of the group. This use of a shared tree can provide significant savings in terms of the amount of multicast state information stored in individual routers.

CBT aggregates traffic onto a smaller subset of links used for source-based trees. The concentration of traffic around the core results in decreased performance. Some versions of CBT support the use of multiple cores; load balancing might be achieved by using more than one core.

CBT Shared Tree

Backward
Chapter: Preface | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
Reserve your copy at a
Beta Bookstore near you! 		Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.
Beta Books | Beta Bookstores | Computing McGraw-Hill

Professional Publishing Home | Contact Us | Customer Service | For Authors | International Offices | New Book Alert | Search Catalog/Order | Site Map | What's New

A Division of the McGraw-Hill Companies
Copyright © 1998 The McGraw-Hill Companies, Inc. All rights reserved. Any use is subject to the Terms of Use the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers.


 Computing McGraw-Hill Beta Bookstores Beta Books McGraw-Hill Professional Publishing


Warning! This document has been designed to be viewed with a frames-capable browser. Please obtain a frames-capable browser such as Netscape Navigator or Microsoft Internet Explorer before attempting to view this document.

Or, if you would prefer to view this document without frames, click on no frames.