An Evaluation of IPv6 Multicast Router in JGN IPv6 Networks
Yukiji Mikamo
TAO Okayama Interoperability& Evaluation Laboratory
Ouchida 675, Teleport Okayama
Okayama-shi, Okayama, 701-0165 Japan
Hisayoshi Hayashi
Hitachi, Ltd., IP Network Division
Horiyamashita 1, Hadano-shi
Kanagawa, 259-1392 Japan

Satoshi Katsuno
TAO Tokyo Research & Operation Center
Otemachi 1-8-1 KDDI Otemachi Bldg.
Chiyoda-ku, Tokyo, 100-0004 Japan
Takashi Miyake
Kurashiki University of Science and the Arts
Nishinoura 2640, Tsurajima-cho
Kurashiki-shi, Okayama, 712-8505 Japan

Kazumasa Kobayashi
Kurashiki University of Science and the Arts
Nishinoura 2640, Tsurajima-cho
Kurashiki-shi, Okayama, 712-8505 Japan

Abstract

Hiroshi Esaki
The University of Tokyo
Hongo 7-3-1 Bunkyo-ku
Tokyo, 113–8656 Japan

hardware-based transaction circuit. Thus led ultimately to
successes in multicast.
To verify its interoperability means that multicast can berealized from among different network organizations, while
new services, which appear, are expected to act as part ofthe social infrastructure in the future.

This paper describes an evaluation of IPv6 multicast
routers. The JGN IPv6 project has performed various evaluations and verifications of IPv6 routers. Seven (7) typesof routers from six vendors were tested, for which PIM-SM
was employed as an IPv6 multicast protocol for the evaluation. The evaluated items include PIM-SM interoperability,
as well as detour, RP and BSR behavior. Several tests were
performed on ATM and Ethernet connections. Detailed results of these verifications are shown in this report. No fatal
problem were found and only a few minor issues occurred
while conducting these evaluations.

2. Research Details
2.1. Router’s IPv6 compatibility
The Telecommunication Advancement Organization ofJapan (TAO) [8] has evaluated IPv6 [3] routers on their performance and functionality based on their interoperability.
The targets of the evaluation are focused on basic communication, performance, unicast routing protocols and mandatory functions as in IPv4.
At present, the verification of OSPFv3 [2] routing protocol has been completed, and construction of a backbone
network using routers possessed by the JGNv6 [6] project
can be realized. The deployment of OSPFv3 in JGNv6 network is coming to fruition.

1. Introduction
Multicasting is becoming more necessary and importantin broadband environments. During IPv4, the multicast was
implemented in many routers, yet it was not widely used
due mainly to the implementation of IGMP snooping function in connected switches, problems in network bandwidth
used, as well as insufficient performance in multicast packet
transaction of the routers themselves. Thus, its interoperability was not criticized.
In current IPv6 environments, the bandwidth problem does not exist, while problems in transaction efficiency were solved by improving performance by using a

3. IPv6 Multicast Implementation Status
3.1. Evaluation Data
The evaluated items are as follows:13.2. Implementation status

Geo
1

The evaluated routers are possessed by TAO, or introduced by router vendors. Some of the routers introduced in
JGNv6 did not support IPv6 multicast. In thses instances,
the router’s successors were employed for the evaluation.
The status of implementation is as shown in the following
table:

1
M20

GR
1

3

10

40

2

30

20

GSR

Vendor
Cisco
Systems

IX
1

1
Juniper
Networks
HitachiNEC
Fujitsu
Furukawa

7206
Figure 1. Example of OSPFv3 Evaluation Network Structure.

(1) Unicast Routing: OSPFv3(2) Multicast Group Management: MLD [4](3) Multicast Routing: PIM-SM [5](4) Multicast Group Address: ff18::xy
The reasons why PIM-SM was selected in the evaluation of IPv6 multicast were that there was no other choice
when scalability in large-scale networks were considered,
while PIM-SM was implemented by router vendors aheadof other protocols. This protocol is standard in current IPv6
multicast.
Despite this, some vendors only implement PIMSSM [1], which is an extension of PIM-SM. A specific example is Juniper’s M20 router. Yet it does not support unicast tunnel function between the DR (Designated Router)and RP (Rendezvous Point) in PIM-SM. It works when therouter is neither a RP nor source DR, thus the evaluation
was performed under this condition. The versions of router
software that were employed in the evaluation are shown in
the following table:

Name
GSR12406

Static-RP°

7206VXR°

M20°

GR2000-6H
IX5030
GeoStream R920
FITELnet-G20

×
°
°
°

BSR
4
Special IOS
4Special IOS
×
PIM-SSM°°°°3.3. Evaluated items
The following items were selected as mandatory functions for IPv6 multicast evaluated items:(1) Basic evaluation of PIM-SM interoperability(2) PIM-SM / OSPFv3 detour function behavior(3) Evaluation of RP behavior(4) Evaluation of BSR behavior
Items (1) to (3) were evaluated in ATM point-to-pointconnection topology (Figure 2), while item (4) was evaluated in an Ethernet broadcast environment (Figure 3) in considering actual operations on JGNv6 networks. Furukawa’s
FITELnet-G20, which does not have an ATM interface, wasconnected via GSR12406 in ATM point-to-point connection
topology.

4. Results of Interoperability Evaluation
4.1. Evaluation in ATM connection (1) — (3)Vendor
Cisco
Systems
Juniper
Networks
HITACHINEC
FUJITSU
Furukawa

Name
GSR12406
7206VXR(NPE3000)
M20

Router OS
IOS 12.0(26)S Patch Ver.
IOS 12.3(2)GR2000-6H
IX5030
GeoStream
R920
FITELnetG20

S-9181-61 07-03-/C
7.6.20
E10V03L50C09

4.1.1. Connection topology of basic evaluation in PIMSM interoperability
Firstly, basic connections in PIM-SM were evaluated before the evaluation of each function. The reason to perform
this evaluation is that there were no known examinations of
PIM-SM evaluation with so many types of routers such as
those used in this evaluation, while the software brought by
vendors included special versions.
The specific connection topology is shown in Figure 4.
Interoperability of all routers can be evaluated in the simplest fashion, by employing GR2000-6H, as described in

JUNOS6.0 R1.5

v01.322

name::1 3 f f e:5::1M20
::1
16
::1
:4

::1

64

/6
::
61
0:
00

:4
16

:/

4
: /6
5:
:6
00
40
16
:
:5
fe

fe:

51

6:

40

00

:7

3:

::1
:/6

3ffe:516:4000:71::/64
: 40

00

:6

8: :

/6

::1

::2

::2

::1

3f

:5
fe
3f

4:

3f

::2

4

GSR

::2

3ff

e: 5

16

:4

0
00

:6

7:

::2

GSR

GR

::2

IX

ID:10.1.0.1
Subnet:*:4001::/48

::4
M20

ID:10.0.0.5
Subnet:*:4008::/48

::5
GR

4

4.1.1.1 PIM-Hello Option Compatibility Point-to-point
addresses of ATM interfaces are originally link-local addresses. However, in this evaluation, global addresses wereassigned, while PIM-Hello option compatibility and its behavior were confirmed [7]. Though it was found that M20
did not perform the PIM Hello option, it ignored the option
and no problem was discovered in its communication.

ID:10.0.0.3
Subnet:*:4004::/48

::3
7206

4 ::1
::17206:/6

ID:10.0.0.2
Subnet:*:4005::/48::2

3 ffe : 51 6 : 4 0 00: 6 9 : : / 6 4

:7

4

64

00

/6

:/

40

::

:
66

6:

::1

62

0:

16

51

64

ID:10.0.0.4
Subnet:*:4007::/48

::1

::1

0:

00

e: 5

fe:

64
::2

::1

00

:4

3ff

3f

::/

:4

16

::2

63

16

3 ffe : 5 1 6 : 4 000 : 6 0 : : / 6 4

:5

::2

IX::2 ::2

* =3ffe:516** =3ffe:516:4000
0:

:5

fe

3 ffe : 51 6 : 4 0 00: 7 2 : : / 6 4

::2

00

fe

3ffe:516:4000:70::/64

3f

::1

::/

4

: 64

::2

Geo
::1

1

00

3f

5
e:
3 ff
::2
::2

Subnet0
6: 4

the implementation status section, which cannot be a staticRP, as RP, BSR, and source.
DVcommXP by Fatware and DVTS by WIDE project
were employed in all evaluations.

ID:Router ID
Subnet:*:400Y::/48
loopback :*:80::x::xID:10.0.0.6
Subnet:*:4006::/48

::6
Geo

ID:10.0.0.7
Subnet:*:4009::/48

::7
G20

G20

Figure 2. Network Topology of the Evaluationin ATM Connection

::x
name

Aug 28 16:17:38 PIM Hello Unknown option: 65001
16:24:25.503754 Out fe80::2a0:a5ff:fe3d:1b42 >ff02::d: pim v2 Hello (Hold-time 1m45s)(OLD-DRPriority: 1) [class 0xc0][hliml]

ID:Router ID
Subnet:*:400Y::/48
loopback :*:80::x

PIM-Hello does not have any option in M20.

* =3ffe:516** =3ffe:516:4000

area0

3ffe:516:4000:90::x/64(X = router ID)

::1
GSR

1

2

Geo

IX

5

7

GR

G20

ID:10.0.0.2
Subnet:*:4005::/48::2
IX

ID:10.0.0.3
Subnet:*:4004::/48::3

3 ff e: 51 6 : 4 0 01 : : / 4 8

3f fe: 5 1 6 : 40 0 2 : : / 48

3 ff e: 51 6 : 4 0 05 : : / 4 8

3 ff e: 51 6 : 4 0 06 : : / 4 8

7206

area0

area0

area0

area0

ID:10.0.0.4
Subnet:*:4007::/48

::4
M20

::5
GR

::6
Geo

::7
G20

Aug 28 16:25:28 PIM at-0/0/0.61 SENT 3ffe:516:40
00:61::1 -> ff02::d V2 Hello hold 105 T-bit LAN
prune 500 ms override 2000 ms pri 1 sum 0x957f
len 26

ID:10.1.0.1
Subnet:*:4001::/48
ID:10.0.0.5
Subnet:*:4008::/48
ID:10.0.0.6
Subnet:*:4006::/48
ID:10.0.0.7
Subnet:*:4009::/48

4.1.1.2 Evaluation results of basic interoperability Received messages in multicast clients under each router wereconfirmed. No problem were discovered in basic interoperability.

Figure 3. Network Topology of the Evaluationin Ethernet Connection

4.1.2. PIM-SM / OSPFv3 detour function behavior
M20

C

One of the important PIM-SIM functions is multicast packet
communication via the shortest path. This function was
evaluated by detouring unicast route by OSPFv3, while
IPv6 backbone was assumed.
ATM links were interrupted in numerical order, as shownin Figure 5. The router in which the route change occurred
was confirmed to have received packets in the shortest path.
To change routes immediately when interfaces go down, its
logical interfaces were interrupted in software methods together with an opposite side router simultaneously.

RP BSR
C

Geo

GR

S

C

IX

7206

C

GSR

G20

C

C

S

SourceC

Client4.1.2.1 Evaluation results of detour function The time
between the selection of the shortest path and receipt of
packets are as shown in Table 1.
Except for GeoStream, when each router received “Join”
messages from the lower reaches, rerouting was performed
and they were replicated into required interfaces. It was

Figure 4. Connection Topology of Basic Evaluation

3

Table 1. Selection of Shortest Path and Receipt of Packets

PPPP

M20 GR 7200 GSR G20 IX

PPPP
GR-GEO shut down
GR-IX shut down
GR-GSR shut down
GR-7200 shut down
IX-M20 shut down
M20-7200 shut down
M20-GSR shut downGeo-7200 shut down
IX-7200 shut down
Geo-GSR shut down

7

C

GR

2

8

3

5

-

8
32
-

120 over-

GEO’s specification for MLD-

C

RP BSR

S

C

Geo

C

C

IX

S

GR

4

6
2

IX

11
9
8

RP BSR
1

10

C

7
7
155
×
-

M20

6

1

Geo

-

Notes

C

M20
5

-

Geo

4

8
9

9
10

7

GSR

G20

7206

3

C
S

SourceC

Client

C

GSR

C

G20

C

S

SourceC

ClientFigure 5. Connection Topology of Basic Interoperability Evaluation

Figure 6. Connection Topology when GSR
and 7206 Were Eliminatedfound that GeoStream waited query interval time beforechanging its PIM-Join target of in the specification.

and IX, while the same phenomenon was found to occur.
To solve this problem, connection topology was changed
and GSR and 7206 were eliminated (Figure 6), and it was
confirmed to work between IX and GeoStream. The problem was found between GSR and 7206.
The problem in special router software with BSR function was found, though contact with the vendors.
When router software in GSR and 7206 was changed toa previous one, no problem was found. Then, the evaluation

4.1.2.2 Evaluation items in detour function There are
two items to be considered. The first is that GeoStream
takes a long time to redistribute packets as it suppresses its
load when encapsulation is performed. Yet, other routers
does not show such phenomenon thus the problem was with
GeoStream. This phenomenon was indicated to the router
vendor that they were asked to consider it as such.
The second item is that when the link 9 in Figure 5 wasinterrupted, IX did not receive assumed packets, which werereplicated from GSR. This appears to be the following phenomenon between 7206 and IX:

Table 2. Results when GSR and 7206 Were
Eliminated.
```
```
```
M20 GR G20 IX Geo```
GR-M20 shut down
4
5
GR-M20 no shut down000

• 7206:PIM Register Stop → IX:does not receive messages
However, it worked without any problems as GSR and
7206, GSR did not find PIM-Join from IX between GSR
4

Relocation

Relocation
M20

C

RP BSR
C

Geo

GR

S

C

IX

7206

C

RP

BSR
Geo

S

G20

GR

S
C

GSR

IX

G20

S
C

S
C

C

C
S

SourceC

ClientS

SourceC

ClientC

Figure 7. Evaluation of RP Function
Figure 8. BSR Function Verification
was continued with the software without the BSR function.
BSR and RP were switched by managing their priorities. For BSR, a larger value takes high priority, while asmaller value takes high priority for RP candidates. However, GeoStream cannot set RP priorities at present so its
loopback address was set to the smallest value.

4.1.3. Evaluation of RP behavior
Each router’s behavior as RP was evaluated. For M20,
which performs PIM-SM, as described above, the evaluations were performed where RP and DR, being neither RP
nor source RP.
The evaluation process is shown in Figure 7. RP, BSR
and Source were relocated under each router, while instances where RP is not source were also evaluated. Though
this is not an ideal environment, such situations often occur
in actual networks.

4.2.1.1 Evaluation results of BSR function and problems
Evaluation results of all matches are shown in Table 4.
As shown in this table, GR were rarely evaluated. Problems were found when the source was placed under otherrouters. For this topology, GR can create correct (G, R)
when GR was RP, BSR itself, and the source was underit, yet, when the source is under other routers, it cannot
send (G, R) properly. This phenomenon occerred only when
multiple PIM routers and multiple sources existed in a single broadcast network. Vendors were asked to investigate
this phenomenon.

4.1.3.1 Evaluation results of RP behavior The results ofthe evaluation are shown in Table 3.
As shown in Table 3, when IX was RP and source wasunder GSR or 7206, replication did not work. The reason for this phenomenon was found to be that IX submitted“Register-Stop” without (S,G) and GSR did not send packets. It was found that the problem depended on how thevendor implemented this, thus the vendor was requested tomake improvements.

5. Discussion
As some routers do not have RP and BSR functions, anoverall summary cannot be presented in terms of IPv6 PIMSM interoperability. However, concerning routers that implemented the functions, very few problems were located.
At the practical operation level, there is sufficient performance for use by locating the RP, BSR and source in theproper locations. This can be used more efficiently if multicast applications that use smaller bandwidths are employed.
This evaluation was affected by bandwidth problems due toan over 30 Mbit/s DV stream. No problems should exist
when all backbone routers are connected to high-speed circuits. However, if one of the routers is connected via a low
speed circuit, it is sometimes flooded by relays from route

4.2. Evaluation in Ethernet connection(4)4.2.1. Evaluation topology of BSR function
The BSR function was evaluated for GeoStream, IX, GR
and G20, which implemented this function. By evaluatingeach router’s match concerning RP and BSR, BSR problems
that occur due to matching each router were clarified.
Each group source was added under each router. As aresult, four multicast groups existed in the network, which
BSR and RP handled.
5

RP
M20
M20
Geo

Source
M20
×
Geo

M20
1
−
3

GR
1
−
3

Geo
IX
IX

IX
IX
GSR

4
1
−

4
1
−

Geo

GSR

−

−

GSR
GSR
G20
G20
7200
7200

GSR
G20
G20
7200
7200
Geo

1
1
1
1
1
1

1
1
1
1
1
1

IX

7200

−

−

GSR

7200

Table 3. Evaluation Results of RP Behavior
7200 GSR G20 IX Geo Notes
1
1
1
1
1
−
−
−
−
−
M20 doesn’t support RP 6= source
3
3
3
3
3
As a specification for joining simultaneously, it waits
a certain period
4
4
5
4
4
Bit rate of DVTS is limited to 20 Mbit/s due to OC/3
1
1
1
1
1
Bit rate of DVTS is limited to 20 Mbit/s due to OC/3
−
−
−
−
−
The first test did not work. This phenomenon was
confirmed twice. This was not due to the interoperability of PIM-SM, but that the NEC IX submits
register-stop without creating (S,G).
−
−
−
−
−
The problem did not occurr in the second test. Packet
flow was shown to be normal. The vendor said it
might be due to an internal problem in GEO when
it was evaluated.
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Bit rate of DVTS is limited to 20 Mbit/s due to OC/3
1
1
1
1
1
Bit rate of DVTS is limited to 20 Mbit/s due to OC/3
1
1
1
1
1
Each router performed under 2000 pps. Block noiseoccurred because the bandwidth usage was 22 Mbit/s.
−
−
−
−
−
The same problem as IX-GSR, Geo-GSR occurred.
Routers except for local 7200 could not connect.
Not measured
was found, or where there was an encapsulated relay to RP.
Hardware-based transactions are primarily employed, thus
performance issues may be disappear over time.

Table 4. Results of BSR Evaluation
PP RP
GR
IX
Geo
G20
PP
BSR
P
P
GR
°
−
−
−
IX
−
°
°
°
Geo
−
°
°
°
G20
−
°
°
°

PP

However, the routers in JGNv6 project might be solved
by making requests to vendors on performance problems.
Consideration is needed when other routers are employed.
In conclusion, the necessity of interoperability evaluationsof different routers is realized. The evaluation of interoperability cannot be performed entirely in the vendor’s laboratory alone. For example, some problems were discovered
when a vendor brought a draft code to implement a new
function, and their new codes were tested in their internal
environment. The problem were revealed only during particular interfaces. Such problems are hard to find in theirlaboratory alone because some interfaces are normally unavailable there.

changes. In this evaluation, 155 Mbit/s ATM circuits were
flooded. This fact should be considered when actual networks are designed.
The evaluation results are fed back to each vendor.
Router software version upgrades were requested to solve
each problem.

6. Conclusion

In the future, IPv6 multicast will be deployed in JGN
IPv6 networks. Evaluations of multicast will be performedin real operating environments. In tested environments, nounicast traffic coexisted, thus unpredictable phenomenon
might not occur. During IPv4, multicast was used in isolated networks; however, it will work as an infrastructure
suitable to a ubiquitous society during IPv6.

One issue which caused concern was performance. For
unicast performance, no problem was located in the various evaluation tests for target routers. However, somerouters were expected to have performance problems in
IPv6 multicast transactions. In practice, software-based relays were limited to temporary cases, when no route table
6

Acknowledgements
We sincerely thank the persons who related with thisJGN IPv6 project in Telecommunications Advancement Organizations of Japan (TAO). Also, we thanks to the Ministryof Public Management, Home Affairs, Posts and Telecommunications, who gave us the opportunity to be involved in
the construction of the JGN IPv6 network. We would also
like to take this opportunity to thank the network engineers
who took part in the operation of the JGN IPv6 network fortheir cooperation.

References[1] B. Cain and H. Holbrook. Source-specific multicast for IP.
IETF draft-ietf-ssm-arch-03.txt, May 2003.
[2] R. Coltun, D. Ferguson, and J. Moy. OSPF for IPv6. IETF
RFC 2470, Dec. 1999.
[3] S. Deering and R. Hinden. Internet protocol version 6(IPv6)
specification. IETF RFC 2460, Dec. 1999.
[4] S. E. Deering, W. C. Fenner, and B. Haberman. Multicast listner discovery (MLD) for IPv6. IETF RFC 2710, Oct. 1999.
[5] B. Fenner, M. Handley, B. Holbrook, and I. Kouvelas. Protocol indepemdent multicast - sparse mode (PIM-SM): Protocol
specification (revised). IETF draft-ietf-pim-sm-v2-new-07.txt,
Mar. 2003.
[6] K. Kobayashi, S. Katsuno, K. Nakamura, Y. Mikamo,
H. Hayashi, A. Machizawa, and H. Esaki. JGN IPv6 network.
In Proceedings of The 2003 International Symposium on Applications and the Internet (SAINT) Workshop, Orlando, FL,
Jan.27-31 2003.
[7] S. Suzuki and T. Jinmei. PIM upstream detection among
multiple addresses. IETF draft-suz-pim-upstream-detection00.txt, Feb. 2003.
[8] TAO.
Japan Gigabit Network home page.
http://www.jgn.tao.go.jp/.

7