Special Feature—IP Multicast Transmission TechnologyIP Multicast Transmission Technologyand Technical Issues
Hiroaki Sato†Abstract
IP (Internet protocol) multicast is one of the key technologies for providing IP broadcasting, which isa major component of next-generation-network services. This article describes the background of recent
IP multicast deployment, gives a brief overview of current IP multicast technologies, and discusses sometechnical issues related to applying IP multicast to IP broadcasting. Finally, it introduces new technologies for solving the issues.

1. Introduction
Broadcasting by IP (Internet protocol) multicast is
expected to be at the heart of Triple Play services forthe Next Generation Network (NGN), and it is an
important technology within the convergence oftelecommunications and broadcasting. As clearlystated in the mid-term findings of the Telecommunications Commission of the Ministry of Internal
Affairs and Communications, “IP Multicast using
communications infrastructure such as optical fibershould be actively applied, ... if it satisfies the requirements to realize equivalent services to terrestrialbroadcasting.” Recent advances in the technology
and the infrastructure have fueled these expectations
for the potential of IP multicast. Stable packet transfer suitable for broadcasting has become possible
because of the penetration of fiber-to-the-home(FTTH), and further developments in multicast support for routers make it easier to build multicast networks. For example, multicast routers capable of carrying over 1000 channels are currently available on
the market.
2. Differences between unicast and multicast
The differences between unicast transmission,
which is currently the most commonly used method† NTT Network Service Systems Laboratories
Musashino-shi, 180-8585 Japan
Email: satou.hiroaki@lab.ntt.co.jp

38

of video distribution on the Internet, and multicast
transmission applied to IP broadcasting are shown inFig. 1. With unicast, the receiving device (receiver)connects directly to the streaming server containing
the video data. The streaming server recognizes theaccessing receiver and transmits the video data packets directly to it. With multicast, streaming servers do
not transmit data directly to receivers. The receivers
send a multicast request containing the desired channel ID to the nearest router (user edge). For example,
the user might acquire the channel ID beforehandfrom the program schedule webpage of the content
provider.
In multicast, the channel is identified by the (S,G)
pair, where S (source) is the IP address of the streaming server and G (group) is the multicast address. In
the example in Fig. 1(b), the receiver requests multicast address 233.0.0.1 from streaming server 3.3.3.3.
The multicast address is within a range of assigned IPaddresses. Specifically, in IPv4 that range is from
224.0.0.0 to 239.255.255.255; in IPv6 the range
includes all address that begin with 0xFF. Theseaddress ranges are used only for forwarding multicast
traffic, and may not be assigned as the IP addresses of
personal computers, etc. Routers can automaticallyrecognize packets in this address range as multicast
packets.
The streaming server sends the broadcasting video
data to the nearest router (server edge) as multicast(S,G) packets where G is destination address and S issource address. Within the IP network, each router
between a user edge and a server edge relays the mulNTT Technical Review

IP packets
to 2.2.2.2
Datafrom 1.1.1.1

IP network

Datato 1.1.1.1 IP packets
request from 2.2.2.2Receiver
IP = 2.2.2.2

Streamingserver
IP = 1.1.1.1(a) Unicast transmission.

Receiver
IP = 4.4.4.4

Receiver
IP = 5.5.5.5

IP packets
to 23
3from .0.0.1
3.3.3.3 Data
Multicastre(to 233.0.0 quest.1, from 3.3.3.3).1 Data
3.0.0
to 23 .3.3.3
3tfrom.3)ques
st re rom 3.3.3
aic
ltf,
1Mu.
03.0.
(to 23IP network

Router(useredge)

IP packets
to 233.0.0.1
Datafrom 3.3.3.3
Multicast request(to 233.0.0.1, from 3.3.3.3)

Router(serveredge)

IP packets
to 233.0.0.1
Datafrom 3.3.3.3

Streaming
server
IP = 3.3.3.3(b) Multicast transmission.

Fig. 1. Unicast versus multicast.

ticast request towards the streaming server of address
S according to the channel ID. When the multicast
request finally arrives at the router receiving the (S,G)
packets (in the worst case, the request will reach theserver edge if it traces the route shown in Fig.1(b)),
that router copies and sends them in the opposite
direction along the path that the multicast request
traveled. This mechanism enables broadcasting video
data to reach the receiver as (S,G) packets.
Unicast and multicast differ in terms of their suitability to applications as a result of the differences inflow described above. For example, unicast is suitable for video-on-demand type services. The directcontrol between the receiver and streaming server
makes possible special play control features such as
fast forwarding, rewinding, and pausing: the types offeatures that are attractive for video-on-demand.
However, one limitation of unicast is that extremely
powerful streaming resources are necessary to handle
streaming to many receivers simultaneously.
In multicast, because there is no direct control
between the receiver and the streaming server, it isdifficult to implement special play control capabilities. However, because it is only necessary to send asingle packet stream, multicast is well suited tobroadcast applications. Therefore, from the streaming server’s perspective, there are no limitations on
the number of possible receivers, and the streaming
load is extremely low.

Vol. 4 No. 12 Dec. 2006

3. Existing multicast technologies
The standard multicast protocols are: i) IGMP
(Internet group management protocol) [1] and MLD(Multicast Listener Discovery) [2] used between thereceiver and a user edge and ii) PIM (Protocol-independent multicast) used between routers on IP networks. Although PIM has a number of modes, weintroduce PIM-SSM (source-specific multicast) [3]here because it is expected to be the mainstream
mode in the foreseeable future. IGMP and MLD are
IPv4 and IPv6 protocols, respectively: while the IP
versions may differ, their behavior is the same. PIMSSM supports both IPv6 and IPv4.
As shown in Fig. 2, IGMP/MLD and PIM-SSM are
similar in the way they send a Join message as a multicast request to the adjacent router in the direction of
the streaming server. However, the inter-router protocol PIM-SSM includes a function for confirming theexistence of an adjacent router running the PIM protocol by a Hello message. This function makes it possible to control multicast bypassing routers that are
not running the PIM protocol.
On the other hand, IGMP/MLD, the protocol
between the receiver and router, has a function that
periodically confirms the existence of receivers thatdesire multicast data. Specifically, as shown in Fig. 2,
the router sends a query message, and if there is noJoin message response, the server determines that
there are no receivers wishing to receive multicast
39

Special Feature

IGMP/MLD

PIM-SSM

Query

Hello

Join (S,G)

RouterMulticast
address: G

Join (S,G)

RouterStreaming
server’s
IP address: SFig. 2. Message flow of existing multicast protocols.

(3) Change of optimalroute in route table
IGMP/MLD
Join (S, G)

Route table(via router 2)↓ change(via router 3)

Router1(2) Notification of linkstatus change(e.g., OSPF)(1) Link failure

Router2Router
4(4) Change intransfer pathof PIM-Join(S, G)PIM-Join
Router3

OSPF: open shortest path first)(S, GStreaming
server(S)(5) Change of packettransfer pathcorresponding tothe change in PIMJoin reception path

Fig. 3. Issues in highly reliable transfer.

data. The purpose for this is to prevent wasteful transfers of multicast packets when multicast data has
become unnecessary, for example, because thereceiver has been restarted or powered off.
4. Requirements and issues
This section overviews the major network requirements for IP broadcasting and issues related to applying IP multicast. The network is required to support
services equivalent to current broadcasting.
4.1 High quality transfer
The network should reserve link bandwidth so thatthe receiver can view contents stably. Moreover, for
NGN, the reserved bandwidth should be sufficient tohandle HDTV (high-definition television) video rates(10 Mbit/s or more). With the current best-effort
packet transfer, however, it is difficult to assign routes
according to channel bandwidth to achieve stable
packet transfer for 10 Mbit/s or higher rates. In particular, it is difficult to specify multicast routers andreserve bandwidth for redundant routes because multicast routes set by PIM depend on the result of transmission using unicast routing protocols.

404.2 Highly reliable transfer
The requirement for a highly reliable network isespecially important. It is shown in detail in Fig. 3.
From the perspective of transfer reliability, routeswitchover must be performed as quickly as possible
when a network failure occurs. The network shouldhave an extremely short downtime for a network failure (e.g., less than 1 s). With PIM, route switchovertakes a long time because it is executed after the convergence of unicast routes. As a result, the number ofroutes is larger, that is the network is larger, soswitchover takes longer. In some cases, PIM routeswitching takes several tens of seconds. Furthermore
with PIM, because the router manages the transfer
status of each channel, the switchover time increases
when more channels are provided.
4.3 Fast channel switching
To support TV channel surfing, the network shouldhave an extremely short response time between achannel change request and the display of video onscreen. With IGMP/MLD, it takes a few seconds toconfirm the status of the other receivers by Querymessages when the current channel is terminatedbefore switching to the new channel.

NTT Technical Review

Special Feature

4.4 Limited area of delivery
The network must be able to limit the geographicalarea over which content is broadcast because thebroadcasting license covers a limited area. It is functionally possible to configure IGMP/MLD filteringon routers. However, it is difficult to administer distribution policies distributed across routers.
4.5 Maintain operability
The network should provide easy failure analysis
and preventative maintenance using route redundancy. Because route control is in the opposite direction
to the data flow for PIM, it is difficult to analyze failures. With PIM, it is difficult to confirm the state of
non-ultimate redundant routes.

Hiroaki SatoSenior Research Engineer, First Promotion
Project and Broadband Network Systems Projectin NTT Network Service Systems Laboratories
and NGN System Promotion Project in NTT Service Integration Laboratories.
He received the B.E. degree from Waseda University, Tokyo, and the M.S. degree from Tokyo
Institute of Technology, Tokyo, in 1990 and1992, respectively. He joined NTT in 1992. Hedeveloped ATM OLT/OLTM (Model-C) to provide various ATM services and Intelligent
IPv4/IPv6 Node Systems for FLET’S Hikari Premium service by NTT West. He is currently
developing a service edge router for NGN. He isa member of the Institute of Electronics, Information and Communication Engineers of Japan.

5. Conclusion
New technologies for solving the above-mentioned
multicasting problems are described in other articles
in this issue. Multicast AAA (Authentication, Authorization, and Accounting) and Multicast MPLS (multiprotocol label switching) are key technologies. For
example, the use of i) path assignment by Multicast
MPLS traffic engineering and ii) coordination withadmission control using Multicast AAA leads to highquality transfers. Network reliability is improved by
fast route switchover by Multicast MPLS just likepoint-to-point MPLS. Aggregated administration ofdistribution policies using Multicast AAA simplifies
the management of router configurations. MPLSOAM of Multicast MPLS achieves advanced management of current and redundant multicast paths(OAM: operation, administration, and maintenance).
References
[1]
[2]
[3]

“Internet Group Management Protocol, Version 3,” RFC3376.
“Multicast Listener Discovery Version 2 (MLDv2),” RFC3810.
“Protocol Independent Multicast - Sparse Mode (PIM-SM),”
RFC4601.

Vol. 4 No. 12 Dec. 2006

41