Special Feature

Bandwidth-guaranteed Reliable
Multicasting
Seisho Yasukawa†
Abstract
In order to provide highly reliable IP (Internet protocol) broadcasting services, it is very important toguarantee the multicast bandwidth, and enhance multicast transmission reliability. This article describes
Multicast MPLS (multiprotocol label switching) for these purposes and explains its applicability to IP
broadcasting.

1. Advances in multicast network functions
Reliable IP (Internet protocol) broadcasting will
require several enhancements to the multicast network functions (Fig. 1). For example, for smoothdelivery of HDTV (high-definition television) video
streams, which require a large amount of bandwidth,a multicast network requires a “multicast bandwidthguarantee” function (c) to statically reserve line bandwidth for data streaming. To minimize broadcasting(a) Multicast group assignment function

Multicastserver
IP = 1.1.1.1

downtime caused by network failures, a “multicastfast rerouting” function (b) is required to enable fast
recover of the multicast delivery path when a pathfailure occurs. To deliver multiple broadcasting services separated into different broadcasting quality
levels, a “multicast group assignment” function (a) is
necessary at the server edge to filter traffic into multicast paths with different QoS (quality of service)levels (e.g., with different bandwidths, with/without
protection, etc.). To support planned or emergency(b) Multicast fast rerouting function(c) Multicast bandwidth guarantee function

Router(transitcore)

Router(useredge)

Router(transitcore)

Router(useredge)

Receiver
IP = 3.3.3.3

Receiver
IP = 4.4.4.4

Router(serveredge)
Multicastserver
IP = 2.2.2.2

Multicast group: channels 1–10
Multicast group: channels 11–20

Receiver
IP = 5.5.5.5

Receiver
IP = 6.6.6.6(d) Multicast explicit route control function

Fig. 1. Multicast functions for highly reliable transmission.
† NTT Network Service Systems Laboratories
Musashino-shi, 180-8585 Japan
Email: s.yasukawa@hco.ntt.co.jp

46

NTT Technical Review

Special Feature

maintenance, a “multicast explicit route control”
function (d) is required for aggregated pathswitchover of all multicast routes and for explicit
routing of delivery routes. However, because thesefour functions have not been implemented, it is difficult to achieve highly reliable IP broadcasting using
existing IP multicast technologies such as PIM (protocol-independent multicast). This article describes
Multicast MPLS, which enables all these operations[1], [2].

the Path message destined for user edge router 4 andto explicitly route to the user edge by sending thisPath message according to the specified path. Whenthe Path message arrives at the user edge router, therouter sends a Resv Message, which retraces the routethat the Path message followed. The Resv message
includes an MPLS forwarding label and configures
the label-switching table for Multicast MPLS forwarding at each node. In our example, the label
switching relationship is configured as 100 → 55 →300 from server edge router 1 to user edge router 4.
This procedure is followed for all multicast-receivinguser edge routers. At this point in the scenario, thetable for router 3, which is a branch node for the multicast route, is configured to assign the output label ofthe branch route by copying the payload and swapping the label of the incoming MPLS packet. In otherwords, at transit core router 3 in Fig. 2, the table isconfigured to branch-copy the MPLS packet arrivingfrom transit core router 2, which has input label 55 aslabel 300 for user edge router 4 and as label 10 for
user edge router 5 based on the MPLS label switching table. This is how the multicast MPLS path is preconfigured in Multicast MPLS.
At the server edge, an MPLS header is attached tothe input IP multicast data and the MPLS path-mapping table is set. This table makes it possible to filter
the forwarding Multicast MPLS path by multicast
group. Meanwhile, at each user edge router, theMPLS header is deleted from the input multicast

2. Multicast MPLS
Multiprotocol label switching (MPLS) transfers
packets according to label information in fixed-length
packet headers. It is a data transfer scheme that can
carry many kinds of traffic including IP packets andenables traffic engineering for these packets. Thissection describes Multicast MPLS technology thatenables MPLS transmission in a multicast environment. An overview of Multicast MPLS is presentedin Fig. 2. First, the server edge router establishes aMulticast MPLS path from the server edge to the useredge using the RSVP-TE (resource reservation protocol traffic extension) signaling protocol [3] with multicast extensions.
In the example in Fig. 2, server edge router 1
exchanges RSVP-TE Path/Resv messages with useredge routers 4, 5, and 7. At such a time, it is possible
to include routing information (1 → 2 → 3 → 4) inIN

IN

OUT

100

55
1005

IN

OUT

IN

55

300
10300

OUT

300
Router 3(transitcore)

55

100

OUT

Router 4(useredge)

Receiver
IP = 3.3.3.3

Receiver
IP = 4.4.4.4

10Multicastserver
IP = 1.1.1.1

Router 1(serveredge)

100

Router 5(useredge)

Router 2(transitcore)

OUT

05
1010
Router 6(transitcore)

Path message
Resv message

IN

5Receiver
IP = 5.5.5.5

Router 7(useredge)

Receiver
IP = 6.6.6.6

IN

OUT

IN

1005

55OUT

Fig. 2. Multicast MPLS.

Vol. 4 No. 12 Dec. 2006

47

Special Feature

MPLS packet, and the switching table is configured
for IP packet forwarding.
Because the multicast route is preconfigured in thisway, the IP multicast packets output by the streaming
server are converted to MPLS packets and filtered tothe appropriate MPLS path. These IP multicast packets are forwarded to the user edge according to themulticast MPLS route explicitly routed by the transit
core node. Then, at the user edge these packets arereconverted to IP packets and delivered to the receiver. At this time, all of the links that make up the multicast route are reserved by FastReroute, which provides fast link protection. In the event of a link failure, fast rerouting is executed through the reserved
links to avoid any disturbance, which makes fastrecovery possible.
Thus, multicast MPLS enables us to provide
advanced multicast transmission functions in order toachieve the various MPLS functions shown in Table
1.

3. Extension for uninterruptible multicast
transmission
To increase the reliability of IP broadcasting evenfurther, uninterruptible transmission in the multicast
transmission network is also envisioned. A method
for achieving uninterruptible multicast transmission
is shown in Fig. 3. The streaming server is given two
interfaces on the server edge. In this model the serveredge has a redundant architecture. Two symmetric
MPLS paths, which each have the same number ofhops from sender to receiver and the same branched
points but have disjoint routes, are configured onplanes A and B. The explicit route control function ofMulticast MPLS enables us to set up this kind of symmetric multicast MPLS path and this path enables
equal multicast transmission delays over both planes.
Furthermore, the receivers are also given dual interfaces at the user edge. The streaming server delivers
the multicast data in parallel to the dually redundant

Table 1. IP multicast technology and multicast MPLS technology.
IP Multicast

Multicast MPLS

Bandwidth guaranteed

Poor: No bandwidth guarantee

Good: RSVP-TE signaling sets up bandwidthguaranteed path.

Fast rerouting

Poor: Several tens of seconds. Depends on IP unicast
route convergence time and error detection time.

Good: A few tens of milliseconds. Independent ofIP unicast route convergence time.

Independent pathassignment per group

Poor: PIM-SSM establishes multicast path based on RPF.
Multicast paths that have the same source address follow
the same route.

Good: Enables independent path assignment.

Explicit route control

Poor: No control mechanism. Multicast route follows theRPF path for the source.

Good: Can control and set up any route based onpath information carried on Path message.

Overall pathswitchover

Poor: Cannot perform overall path switchover.

Good: MakeBeforeBreak enables overall pathswitchover without interruption.
RPF: reverse path forwarding

T2

Router(useredge)

T1
Receiver
IP = 5.5.5.5

T2

T4

Router(serveredge)

Router(transitT3 core)Multicastserver
IP = 1.1.1.1

T4
T2

Router(serveredge)

Router(transitT3 core)

T2

Router(useredge)

T1

Receiver
IP = 6.6.6.6

Fig. 3. Uninterrupted multicast transmission based on RTP.

48

NTT Technical Review

Special Feature

multicast routes. An RTP (realtime protocol) header
is attached to multicast data and the timestamp value
is stored in the header. This data is transferred to theuser edge along the symmetric multicast MPLS paths
nearly synchronously. At the user edge, the RTP
header’s timestamps arriving through the redundant
paths are processed, and the data is constantly selected from one path and transmitted downstream so thatthe succession of timestamps is maintained. With thismechanism, if one of the redundant paths fails, thedata from the other path can be received without
interruption and forwarded. Thus, uninterruptibletransmission can be achieved.

Seisho Yasukawa
Senior Researcher, NTT Network Service Systems Laboratories.
He received the B.E. and M.E. degrees inapplied physics from the University of Tokyo,
Tokyo, in 1993 and 1995, respectively. He joined
NTT Network Service Systems Laboratories in1995. The work described in this article was performed while he was a Senior Research Engineer
in the Broadband Network Project of NTT Network Service Systems Laboratories. He moved
to Department III, R&D Strategy Department in2006. He is a member of IEEE and the Instituteof Electronics, Information and Communication
Engineering (IEICE) of Japan. He received theYoung Researcher’s Award from IEICE in 2001.

Conclusion
Highly reliable IP broadcasting is possible throughadvances in the multicast transfer network achieved
using multicast MPLS. We are considering applying
it in the next-generation network as a method ofachieving highly reliable multicast transmission.
References
[1]

[2]

[3]

S. Yasukawa (ed.), “Signaling Requirements for Point-to-Multipoint
Traffic-Engineered MPLS Label Switched Paths (LSPs),” RFC4461,
April 2006.
R. Aggarwal, D. Papadimitriou, and S. Yasukawa, “Extensions toRSVP-TE for Point to Multipoint TE LSPs,” draft-ietf-mpls-rsvp-tep2mp-05.txt.
D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, and V. Srinivasan, “RSVP-TE: Extensions to RSVP for LSP Tunnels,” RFC3209,December 2001.

Vol. 4 No. 12 Dec. 2006

49