< draft-sdry-bmwg-mvpnscale-01.txt   draft-sdry-bmwg-mvpnscale-02.txt >
Network Working Group S. Dry Network Working Group S. Dry
F. Calabria F. Calabria
I.Y Fung I.Y Fung
Internet Draft Cisco Internet Draft Cisco
M. Napierala M. Napierala
AT&T AT&T
Y. Kamite Y. Kamite
NTT Corporation NTT Corporation
Expires: August 2007 February 23, 2007 Expires: February 2008 August 16, 2007
Multicast VPN Scalability Benchmarking Multicast VPN Scalability Benchmarking
draft-sdry-bmwg-mvpnscale-01.txt draft-sdry-bmwg-mvpnscale-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
This document may only be posted in an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 23, 2007. This Internet-Draft will expire on February 16, 2008.
Abstract Abstract
Multicast VPN (MVPN) is a service deployed by VPN service providers Multicast VPN (MVPN) is a service deployed by VPN service providers
to enable their customers to use IP multicast applications over VPNs. to enable their customers to use IP multicast applications over VPNs.
With the increased popularity the scalability of deploying such a With the increased popularity the scalability of deploying such a
service is becoming of a great interest. This document defines service is becoming of a great interest. This document defines
standard metric and test methodology for characterizing and comparing standard metric and test methodology for characterizing and comparing
control plane MVPN scalability of Provider Edge (PE) devices that control plane MVPN scalability of Provider Edge (PE) devices that
implement MVPN service. implement MVPN service.
skipping to change at page 2, line 33 skipping to change at page 2, line 33
6.4 Data Traffic Characteristics............................11 6.4 Data Traffic Characteristics............................11
6.5 Test Apparatus Considerations...........................11 6.5 Test Apparatus Considerations...........................11
6.6 Considerations for distributed architecture platforms...12 6.6 Considerations for distributed architecture platforms...12
7 Test Categories, Stimulus and Execution Methodology...........12 7 Test Categories, Stimulus and Execution Methodology...........12
7.1 Steady State Testing Execution Methodology..............13 7.1 Steady State Testing Execution Methodology..............13
7.2 Failure Recovery Testing Execution Methodology..........14 7.2 Failure Recovery Testing Execution Methodology..........14
8 Results Content and Reporting Format..........................15 8 Results Content and Reporting Format..........................15
8.1 Steady State Testing....................................15 8.1 Steady State Testing....................................15
8.2 Failure Recovery Testing................................16 8.2 Failure Recovery Testing................................16
9 Test Cases....................................................17 9 Test Cases....................................................17
9.1 "Empty" MVPNs Scale.....................................18 9.1 ''Empty'' MVPNs Scale.....................................18
9.2 PIM Enabled VPN C-Interfaces Scale......................20 9.2 PIM Enabled VPN C-Interfaces Scale......................20
9.3 PIM Neighborships Scale.................................22 9.3 PIM Neighborships Scale.................................22
9.4 Default MDT's (MI-PMSI's) PIM P-Instance Mroutes Scale..25 9.4 Default MDT's (MI-PMSI's) PIM P-Instance Mroutes Scale..25
9.5 PIM C-instances Mroutes Scale...........................27 9.5 PIM C-instances Mroutes Scale...........................27
9.6 PIM C-Instances OIF Scale...............................30 9.6 PIM C-Instances OIF Scale...............................30
9.7 Joined S-PMSI (Data MDT) Scale..........................32 9.7 Joined S-PMSI (Data MDT) Scale..........................32
9.8 Sourced S-PMSI (Data MDT) Scale.........................35 9.8 Sourced S-PMSI (Data MDT) Scale.........................35
9.9 Data MDT (S-PMSI) Reuse.................................37 9.9 Data MDT (S-PMSI) Reuse.................................37
9.10 PIM C-instances J/P Suppression Effectiveness...........39 9.10 PIM C-instances J/P Suppression Effectiveness...........39
9.11 Additional Tests and Considerations for Devices Lacking 9.11 Additional Tests and Considerations for Devices Lacking
"Efficient" Join/Prune Suppression............................42 ''Efficient'' Join/Prune Suppression............................42
9.12 Scale of mVPNs spanning large number of PEs.............43 9.12 Scale of mVPNs spanning large number of PEs.............43
9.13 Scale of mVPNs with larger amount of state..............46 9.13 Scale of mVPNs with larger amount of state..............46
9.14 Scale of "average" size mVPNs...........................48 9.14 Scale of ''average'' size mVPNs...........................48
9.15 S-PMSI Switching Delay..................................50 9.15 S-PMSI Switching Delay..................................50
9.16 Convergence of C-Instance PIM Joins.....................51 9.16 Convergence of C-Instance PIM Joins.....................51
9.17 Effect of Co-locating C-RPs on a PE.....................53 9.17 Effect of Co-locating C-RPs on a PE.....................53
10 Security Considerations....................................55 10 Security Considerations....................................55
11 IANA Considerations........................................55 11 IANA Considerations........................................55
12 Acknowledgments............................................55 12 Acknowledgments............................................55
13 References.................................................56 13 References.................................................56
13.1 Normative References....................................56 13.1 Normative References....................................56
13.2 Informative References..................................56 13.2 Informative References..................................56
Author's Addresses...............................................57 Author's Addresses...............................................57
skipping to change at page 4, line 17 skipping to change at page 4, line 17
may not necessarily be the same as recommended design choice for a may not necessarily be the same as recommended design choice for a
realistic deployment. realistic deployment.
o MVPN is a service that is never deployed in isolation as it o MVPN is a service that is never deployed in isolation as it
requires underlying unicast VPN offering. Typically SPs add MVPN requires underlying unicast VPN offering. Typically SPs add MVPN
service on PE devices that are already deployed and are providing service on PE devices that are already deployed and are providing
a large number of other services such as unicast L3VPNs, L2VPNs, a large number of other services such as unicast L3VPNs, L2VPNs,
internet access, etc. Therefore, when considering MVPN scalability internet access, etc. Therefore, when considering MVPN scalability
in realistic deployments one needs to take into consideration the in realistic deployments one needs to take into consideration the
level to which PE resources are already utilized and the available level to which PE resources are already utilized and the available
headroom amount remaining. In this document it will be assumed headroom amount remaining. In this document it will be assumed
that MVPN service is deployed as an addition of a "minimized" that MVPN service is deployed as an addition of a ''minimized''
unicast control plane. unicast control plane.
o MVPN Scalability of a PE device is different when the system is o MVPN Scalability of a PE device is different when the system is
subjected to different stimuli. For example overall scalability subjected to different stimuli. For example overall scalability
achieved in steady state can be typically higher than when the achieved in steady state can be typically higher than when the
system is subjected to a network and/or device specific failures. system is subjected to a network and/or device specific failures.
In this document a limited set of mandatory test stimuli will be In this document a limited set of mandatory test stimuli will be
defined. defined.
2 Document Scope 2 Document Scope
In IETF currently there are multiple proposals on architectures and In IETF currently there are multiple proposals on architectures and
protocols for implementing MVPN service, as documented in [L3VPN- protocols for implementing MVPN service, as documented in [L3VPN-
MCAST]. The scope of this document is on benchmarking MVPN MCAST]. The scope of this document is on benchmarking MVPN
scalability for the MVPN architecture described in [L3VPN-MCAST] scalability for the MVPN architecture described in [L3VPN-MCAST]
which uses PIM protocol for both PE-PE transmission of C-Multicast which uses PIM protocol for both PE-PE transmission of C-Multicast
routing information and to create 'tunnels' that instantiate routing information and to create 'tunnels' that instantiate
Multidirectional Inclusive P-Multicast Service Interfaces (MI-PMSIs) Multidirectional Inclusive P-Multicast Service Interfaces (MI-PMSIs)
and Selective P-Multicast Service Interfaces (S-PMSIs). The same and Selective P-Multicast Service Interfaces (S-PMSIs). The same
architecture is also described in [ROSEN-8] which is obsoleted by architecture is also described in [ROSEN-8] which is obsoleted by
[L3VPN-MCAST]. In the rest of the document this architecture will be [L3VPN-MCAST]. In the rest of the document this architecture will be
referred to as a "ROSEN-8" architecture. referred to as a ''ROSEN-8'' architecture.
In addition, test methodology and a good portion of the test cases In addition, test methodology and a good portion of the test cases
from this document can be used to assess a great deal but not all of from this document can be used to assess a great deal but not all of
scalability aspects of other MVPN architectures from [L3VPN-MCAST]. scalability aspects of other MVPN architectures from [L3VPN-MCAST].
Thus, it can easily be used as a base for any future supplemental Thus, it can easily be used as a base for any future supplemental
benchmarking documents addressing other MVPN architectures. We benchmarking documents addressing other MVPN architectures. We
explicitly identified text applicable to all architectures from explicitly identified text applicable to all architectures from
[L3VPN-MCAST]. [L3VPN-MCAST].
Scope of this document is to address comparison between different Scope of this document is to address comparison between different
skipping to change at page 5, line 47 skipping to change at page 5, line 47
Note that the deployment of MVPN also consumes resources on P devices Note that the deployment of MVPN also consumes resources on P devices
in support of creation and maintenance of PMSIs / MDTs (Multicast in support of creation and maintenance of PMSIs / MDTs (Multicast
Distribution Trees). But, since MVPN functionality does not reside on Distribution Trees). But, since MVPN functionality does not reside on
P and CE routers, they are beyond the scope of this document. P and CE routers, they are beyond the scope of this document.
3 Terminology 3 Terminology
DUT (Device Under Test) term will be used interchangeably with MVPN DUT (Device Under Test) term will be used interchangeably with MVPN
PE device. PE device.
We will use term "MVPN architecture" to describe any specific subset We will use term ''MVPN architecture'' to describe any specific subset
of protocols and procedures from [L3VPN-MCAST] that can enable MVPN of protocols and procedures from [L3VPN-MCAST] that can enable MVPN
functionality on PE device. In contrast, we will use term "MVPN functionality on PE device. In contrast, we will use term ''MVPN
implementations" to describe practical implementations of such "MVPN implementations'' to describe practical implementations of such ''MVPN
architectures". architectures''.
VPN related terms used in this document are defined in RFC4364 and VPN related terms used in this document are defined in RFC4364 and
RFC2547bis. MVPN related terms used in this document are defined in RFC2547bis. MVPN related terms used in this document are defined in
[L3VPN-MCAST]. [L3VPN-MCAST].
PIM (Protocol Independent Multicast) related terms are defined in PIM (Protocol Independent Multicast) related terms are defined in
RFC4601. RFC4601.
For the reader's convenience, here is review of some key terms used For the reader's convenience, here is review of some key terms used
in this document: in this document:
skipping to change at page 7, line 13 skipping to change at page 7, line 13
interchangeably with S-PMSI. interchangeably with S-PMSI.
ASM (Any Source Multicast): Multicast service model in which a ASM (Any Source Multicast): Multicast service model in which a
receiver subscribes to a multicast group to receive traffic sent to receiver subscribes to a multicast group to receive traffic sent to
the group by any source. the group by any source.
SSM (Source Specific Multicast): Multicast service model in which a SSM (Source Specific Multicast): Multicast service model in which a
receiver subscribes to a multicast group to receive traffic sent to receiver subscribes to a multicast group to receive traffic sent to
the group by the specific source. the group by the specific source.
Mroute: Multicast route. Term "state" will used interchangeable with Mroute: Multicast route. Term ''state'' will used interchangeable with
"mroute" and "multicast route". ''mroute'' and ''multicast route''.
"ROSEN-8" architecture: architecture described in [L3VPN-MCAST] which ''ROSEN-8'' architecture: architecture described in [L3VPN-MCAST] which
uses PIM protocol for both PE-PE Transmission of C-Multicast Routing uses PIM protocol for both PE-PE Transmission of C-Multicast Routing
and to create 'tunnels' that instantiate Multidirectional Inclusive and to create 'tunnels' that instantiate Multidirectional Inclusive
P-Multicast Service Interfaces (MI-PMSIs) and Selective P-Multicast P-Multicast Service Interfaces (MI-PMSIs) and Selective P-Multicast
Service Interfaces (S-PMSIs). This is a same as architecture Service Interfaces (S-PMSIs). This is a same as architecture
described in [ROSEN-8]. described in [ROSEN-8].
4 Key Words to Reflect Requirements 4 Key Words to Reflect Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[Br97]. RFC 2119 defines the use of these key words to help make the [Br97]. RFC 2119 defines the use of these key words to help make the
intent of standards track documents as clear as possible. While this intent of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards track document uses these keywords, this document is not a standards track
5 MVPN Metric Definition 5 MVPN Metric Definition
MVPN control plane scalability of PE device can not be described as a MVPN control plane scalability of PE device can not be described as a
single parameter but it requires a set of variables. We call such a single parameter but it requires a set of variables. We call such a
set "MVPN Metric" and define it further in this section. set ''MVPN Metric'' and define it further in this section.
When providing scalability capabilities of a PE device one MUST When providing scalability capabilities of a PE device one MUST
provide values for all of the MVPN metric variables that were used provide values for all of the MVPN metric variables that were used
during the test. For example, one should never claim that a PE device during the test. For example, one should never claim that a PE device
supports X number of MVPNs without disclosing the values of other supports X number of MVPNs without disclosing the values of other
MVPN Metric variables. MVPN Metric variables.
The MVPN Metric is defined as a tuple of the following 14 variables: The MVPN Metric is defined as a tuple of the following 14 variables:
Variables Applicable to all MVPN architectures Variables Applicable to all MVPN architectures
skipping to change at page 8, line 26 skipping to change at page 8, line 26
created by PIM C-instances. created by PIM C-instances.
7. Num_SPMSI_Src: Total number of data MDTs (S-PMSIs) across all mVPNs 7. Num_SPMSI_Src: Total number of data MDTs (S-PMSIs) across all mVPNs
on DUT that are sourced by DUT. on DUT that are sourced by DUT.
8. Num_SPMSI_Rx: Total number of data MDTs (S-PMSIs)across all mVPNs 8. Num_SPMSI_Rx: Total number of data MDTs (S-PMSIs)across all mVPNs
on DUT for which DUT is a receiver. on DUT for which DUT is a receiver.
9. Num_SPMSI_SrcFlows: Total number of C-instance (S,G) flows across 9. Num_SPMSI_SrcFlows: Total number of C-instance (S,G) flows across
all mVPNs on DUT that are mapped to Num_SPMSI_Src. all mVPNs on DUT that are mapped to Num_SPMSI_Src.
10. Num_SPMSI_RxFlows: Total number of C-instance (S,G) flows 10. Num_SPMSI_RxFlows: Total number of C-instance (S,G) flows
across all mVPNs on DUT that are mapped to Num_SPMSI_Rx. across all mVPNs on DUT that are mapped to Num_SPMSI_Rx.
Additional variables applicable to "ROSEN-8" architecture: Additional variables applicable to ''ROSEN-8'' architecture:
1. Num_PIM_MI_PMSI_neigh: Total number of PIM neighbors in PIM C- 1. Num_PIM_MI_PMSI_neigh: Total number of PIM neighbors in PIM C-
instances across all mVPNs on DUT established over MI-PMSIs. instances across all mVPNs on DUT established over MI-PMSIs.
2. Num_*G_P: Total number of (*,G) multicast routes on DUT capable of 2. Num_*G_P: Total number of (*,G) multicast routes on DUT capable of
forwarding and created by PIM P-instance on DUT. forwarding and created by PIM P-instance on DUT.
3. Num_SG_P: Total number of (S,G) multicast routes on DUT capable of 3. Num_SG_P: Total number of (S,G) multicast routes on DUT capable of
forwarding and created by PIM P-instance. forwarding and created by PIM P-instance.
4. Num_OIF_P: Total number of OIFs (outgoing interfaces) on DUT 4. Num_OIF_P: Total number of OIFs (outgoing interfaces) on DUT
across all multicast routes created by PIM P-instance. across all multicast routes created by PIM P-instance.
skipping to change at page 9, line 35 skipping to change at page 9, line 35
Figure 1. Test Topology 1 Figure 1. Test Topology 1
Legend: Legend:
D1 (DUT's C-facing interface): DUT's interface that connects to D1 (DUT's C-facing interface): DUT's interface that connects to
customer premise router (C-router). customer premise router (C-router).
D2 (DUT's P-facing interface): DUT's interface that connects to SP's D2 (DUT's P-facing interface): DUT's interface that connects to SP's
core router (P-router). core router (P-router).
RR/P (Route Reflector/P-router) - single router that will be RR/P (Route Reflector/P-router): single router that will be
performing roles of both P-router and route reflector performing roles of both P-router and route reflector
PE2 - Will also be referred to as "Remote PE" and is the router PE2: Will also be referred to as Remote PE and is the router
performing PE functionality to assist with evaluation of DUT PE performing PE functionality to assist with evaluation of DUT PE
router. router.
6.2 Unicast Control Plane Setup 6.2 Unicast Control Plane Setup
All P facing interfaces MUST use OSPF as IGP. This requirement is All P facing interfaces MUST use OSPF as IGP. This requirement is
made to provide a standard way to compare end to end convergence made to provide a standard way to compare end to end convergence
times which depend on the underlying unicast protocol. Only a minimum times which depend on the underlying unicast protocol. Only a minimum
number of IGP routes required to establish connectivity should be number of IGP routes required to establish connectivity should be
seen on the DUT. seen on the DUT.
skipping to change at page 10, line 44 skipping to change at page 10, line 44
physically directly connected to DUT (port A1 in Figures 1 and 2) not physically directly connected to DUT (port A1 in Figures 1 and 2) not
to use IGMP protocol to emulate multicast receivers. Instead PIM to use IGMP protocol to emulate multicast receivers. Instead PIM
protocol must be used, i.e. the DUT should not be the last hop protocol must be used, i.e. the DUT should not be the last hop
router. router.
As an exception to previous paragraph it may exist specific network As an exception to previous paragraph it may exist specific network
design requirement to deploy IGMP receivers connected directly to the design requirement to deploy IGMP receivers connected directly to the
DUT in which case test results MUST specify number of C-interfaces DUT in which case test results MUST specify number of C-interfaces
with IGMP receivers. Regardless the IGMP protocol variant to be with IGMP receivers. Regardless the IGMP protocol variant to be
deployed (IGMPV2 / V3); receivers MUST be emulated by the test deployed (IGMPV2 / V3); receivers MUST be emulated by the test
apparatus and NOT defined on the DUT in the form of static groups / apparatus and NOT defined on the DUT in the form of static group
joins. Test apparatus MUST be capable to emulate an IGMP Host or th Querier and set a maximum Timer Interval between messages of 1/10 reports. Test apparatus MUST be capable to emulate an IGMP Host or
of a second Querier and set a maximum Timer Interval between messages of 1/10th
of a second.
6.4 Data Traffic Characteristics 6.4 Data Traffic Characteristics
For every C-instance multicast route there MUST be traffic flow For every C-instance multicast route there MUST be traffic flow
associated with it and forwarded by DUT. associated with it and forwarded by DUT.
All C-instance flows SHOULD be transmitted with the same traffic rate All C-instance flows SHOULD be transmitted with the same traffic rate
and packet size. and packet size.
As the focus of this document is on the control plane scalability and As the focus of this document is on the control plane scalability and
not on forwarding performance the data rate and packet size of not on forwarding performance the data rate and packet size of
traffic flows can be chosen by user but it MUST be reported in the traffic flows can be chosen by user but it MUST be reported in the
test results. However it is suggested to use 10% of "idle system" test results. However it is suggested to use 10% of ''idle system''
throughput [RFC1242] so that it can be easily detected if hardware throughput [RFC1242] so that it can be easily detected if hardware
forwarding platforms start forwarding in software and at the same forwarding platforms start forwarding in software and at the same
time in case of software forwarding platforms there will be enough time in case of software forwarding platforms there will be enough
processor headroom left for control plane scaling. By "idle system" processor headroom left for control plane scaling. By ''idle system''
we refer to system with all of MVPN metric variables minimized and we refer to system with all of MVPN metric variables minimized and
single VPN traffic flow in each direction. single VPN traffic flow in each direction.
As an additional requirement, the reader of this document may also be As an additional requirement, the reader of this document may also be
interested in analyzing the "impact" that high traffic rate may have interested in analyzing the ''impact'' that high traffic rate may have
on the control plane. This would be of interest mostly for software on the control plane. This would be of interest mostly for software
forwarding platforms. For this specific requirement additional test forwarding platforms. For this specific requirement additional test
cases SHOULD be performed increasing the rate of multicast traffic to cases SHOULD be performed increasing the rate of multicast traffic to
20%, 50% and 90% of "idle system" throughput [RFC1242]. 20%, 50% and 90% of ''idle system'' throughput [RFC1242].
6.5 Test Apparatus Considerations 6.5 Test Apparatus Considerations
Different test tools must generate PIM protocol control messages in a Different test tools must generate PIM protocol control messages in a
consistent way since they are directly connected to the DUT. consistent way since they are directly connected to the DUT.
The following MUST be implemented on all PIM sessions on the test The following MUST be implemented on all PIM sessions on the test
apparatus: apparatus:
1) PIM Join/Prune aggregation MUST be utilized and set such that 80 1) PIM Join/Prune aggregation MUST be utilized and set such that 80
skipping to change at page 13, line 24 skipping to change at page 13, line 24
seconds. All convergence times should be measured from the time seconds. All convergence times should be measured from the time
cable is physically re-inserted (Tf). cable is physically re-inserted (Tf).
Since the test execution methodology is similar for all test cases we Since the test execution methodology is similar for all test cases we
will describe it here for both steady state and failure recovery will describe it here for both steady state and failure recovery
testing. Any deviation from this will be specified per test case in testing. Any deviation from this will be specified per test case in
section 9. section 9.
Multiple iterations of each test are required to determine maximum Multiple iterations of each test are required to determine maximum
value for certain set of variables. A single iteration will be value for certain set of variables. A single iteration will be
referred to as a "Test Case Instance". referred to as a ''Test Case Instance''.
7.1 Steady State Testing Execution Methodology 7.1 Steady State Testing Execution Methodology
The following test execution procedure MUST be used for all Test Case The following test execution procedure MUST be used for all Test Case
Instances during steady state testing of each test case defined in Instances during steady state testing of each test case defined in
section 9 of this document: section 9 of this document:
1) Ensure the testbed is setup according to Test Setup instructions 1) Ensure the testbed is setup according to Test Setup instructions
of individual test case of individual test case
skipping to change at page 15, line 38 skipping to change at page 15, line 38
in steps 1-6 above in steps 1-6 above
The number of Test Case Instances per test case is left to The number of Test Case Instances per test case is left to
tester's discretion. However, it is DESIRABLE to have results for tester's discretion. However, it is DESIRABLE to have results for
at least 5 test case instances. Having a range of values will help at least 5 test case instances. Having a range of values will help
in variable's characterization. The characterization of a variable in variable's characterization. The characterization of a variable
cannot be achieved with only one test case instance result. cannot be achieved with only one test case instance result.
8 Results Content and Reporting Format 8 Results Content and Reporting Format
Note that everything in this section except for "MI-PMSI PIM Note that everything in this section except for ''MI-PMSI PIM
neighborhsip convergence time" is applicable to all MVPN neighborhsip convergence time'' is applicable to all MVPN
architectures defined in [L3VPN-MCAST]. architectures defined in [L3VPN-MCAST].
8.1 Steady State Testing 8.1 Steady State Testing
For steady state portion of testing for each test case the following For steady state portion of testing for each test case the following
results MUST be included in the test case report: results MUST be included in the test case report:
1. Maximum value achieved for variables requested to be varied in 1. Maximum value achieved for variables requested to be varied in
individual test case individual test case
skipping to change at page 17, line 14 skipping to change at page 17, line 14
It is DESIRABLE to include: It is DESIRABLE to include:
1. A graph from all test tool ports showing transmitted and received 1. A graph from all test tool ports showing transmitted and received
packet rate starting from 60 seconds prior to failure action to 60 packet rate starting from 60 seconds prior to failure action to 60
seconds after all multicast flows had recovered to the traffic rate seconds after all multicast flows had recovered to the traffic rate
they had prior to the failure. they had prior to the failure.
2. The best case MI-PMSI PIM neighborship convergence time: time 2. The best case MI-PMSI PIM neighborship convergence time: time
interval from instance Tf to instance when the first C-instance PIM interval from instance Tf to instance when the first C-instance PIM
neighbor across one of MI-PMSIs comes up on both DUT and neighbor across one of MI-PMSIs comes up on both DUT and
neighboring device (i.e. "bi-directional" neighborships are neighboring device (i.e. ''bi-directional'' neighborships are
established). established).
3. The worst case MI-PMSI PIM neighborship convergence time: time 3. The worst case MI-PMSI PIM neighborship convergence time: time
interval from instance Tf to instance when all expected C-instance interval from instance Tf to instance when all expected C-instance
PIM neighbors across one of MI-PMSIs comes up on both DUT and PIM neighbors across one of MI-PMSIs comes up on both DUT and
neighboring device (i.e. "bi-directional" neighborships are neighboring device (i.e. ''bi-directional'' neighborships are
established). established).
9 Test Cases 9 Test Cases
There are 16 test cases defined in this section. All test cases There are 16 test cases defined in this section. All test cases
except for 9.3, 9.4 and 9.10 can be used for any MVPN architecture except for 9.3, 9.4 and 9.10 can be used for any MVPN architecture
from [L3VPN-MCAST]. However, as noted in section 2, architectures from [L3VPN-MCAST]. However, as noted in section 2, architectures
other than "ROSEN-8" might require additional test cases that are other than ''ROSEN-8'' might require additional test cases that are
beyond scope of this document. As [L3VPN-MCAST] specifies use of S- beyond scope of this document. As [L3VPN-MCAST] specifies use of S-
PMSIs as optional, test cases 9.7-9.9 can be omitted for implementers PMSIs as optional, test cases 9.7-9.9 can be omitted for implementers
that don't support S-PMSIs. For such implementers test cases 9.12-17 that don't support S-PMSIs. For such implementers test cases 9.12-17
SHOULD still be executed but without use of S-PMSIs and the exception SHOULD still be executed but without use of S-PMSIs and the exception
MUST be documented in the test report. MUST be documented in the test report.
In Test Setup portion of each test case section "P-instance Multicast In Test Setup portion of each test case section ''P-instance Multicast
Configuration" is not applicable to all MVPN architectures from Configuration'' is not applicable to all MVPN architectures from
[L3VPN-MCAST] but only to those using PIM protocol to create [L3VPN-MCAST] but only to those using PIM protocol to create
'tunnels' that instantiate MI-PMSI (such as "ROSEN-8" architecture). 'tunnels' that instantiate MI-PMSI (such as ''ROSEN-8'' architecture).
All other portions of Test Setup are applicable to all MVPN All other portions of Test Setup are applicable to all MVPN
architectures. architectures.
Note that following relationships exist between "Multicast Control Note that following relationships exist between ''Multicast Control
Plane Profile" variables in "Test Setup" of each test case in section Plane Profile'' variables in ''Test Setup'' of each test case in section
9 and metric defined in section 5: 9 and metric defined in section 5:
a. Number of MVPNs configured on DUT = Num_mVPN a. Number of MVPNs configured on DUT = Num_mVPN
b. Number of PIM VPN C-interfaces = Num_MC_C_ints/Num_mVPN b. Number of PIM VPN C-interfaces = Num_MC_C_ints/Num_mVPN
c. Number of remote PEs = Num_PIM_MI_PMSI_neigh/Num_mVPN c. Number of remote PEs = Num_PIM_MI_PMSI_neigh/Num_mVPN
d. Num_*G_C = Num_mVPN *((Number of C-instance multicast groups in d. Num_*G_C = Num_mVPN *((Number of C-instance multicast groups in
encap direction) + (Number of C-instance multicast groups in encap direction) + (Number of C-instance multicast groups in
decap direction)) decap direction))
e. Num_SG_C = Num_mVPN * ((Number of C-instance sources per group e. Num_SG_C = Num_mVPN * ((Number of C-instance sources per group
in encap direction)*(Number of C-instance multicast groups in in encap direction)*(Number of C-instance multicast groups in
skipping to change at page 18, line 28 skipping to change at page 18, line 28
direction)) direction))
g. Number of data MDTs (S-PMSIs) sourced from DUT = g. Number of data MDTs (S-PMSIs) sourced from DUT =
Num_SPMSI_Src/Num_mVPN Num_SPMSI_Src/Num_mVPN
h. Number of data MDTs (S-PMSIs) with receivers behind DUT = h. Number of data MDTs (S-PMSIs) with receivers behind DUT =
Num_SPMSI_Rx/Num_mVPN Num_SPMSI_Rx/Num_mVPN
i. Number of C-instance (S,G) flows using sourced data MDTs (S- i. Number of C-instance (S,G) flows using sourced data MDTs (S-
PMSIs) = Num_SPMSI_SrcFlows/Num_mVPN PMSIs) = Num_SPMSI_SrcFlows/Num_mVPN
j. Number of C-instance (S,G) flows using received data MDTs (S- j. Number of C-instance (S,G) flows using received data MDTs (S-
PMSIs) = Num_SPMSI_RxFlows/Num_mVPN PMSIs) = Num_SPMSI_RxFlows/Num_mVPN
9.1"Empty" MVPNs Scale 9.1''Empty'' MVPNs Scale
Test Objective: Test Objective:
To determine maximum number of MVPN instances that can be To determine maximum number of MVPN instances that can be
configured and operational on the MVPN PE router. Note that we configured and operational on the MVPN PE router. Note that we
refer here to mVPNs as "empty" as amount of PIM neighborships, refer here to mVPNs as ''empty'' as amount of PIM neighborships,
interfaces, C-instances multicast routes and SI-PMSIs associated interfaces, C-instances multicast routes and SI-PMSIs associated
with given mVPN is negligible or zero in this test case. with given mVPN is negligible or zero in this test case.
Metric Variables Relationships: Metric Variables Relationships:
Num_mVPN=Num_MC_C_ints=Num_PIM_C_neigh=Num_PIM_MI_PMSI_Neigh Num_mVPN=Num_MC_C_ints=Num_PIM_C_neigh=Num_PIM_MI_PMSI_Neigh
Num_*G_C=Num_SG_C=2*Num_mVPN Num_*G_C=Num_SG_C=2*Num_mVPN
Num_OIF_C=4*Num_mVPN Num_OIF_C=4*Num_mVPN
skipping to change at page 20, line 15 skipping to change at page 20, line 15
Execute number of test case instances where in each test case Execute number of test case instances where in each test case
instance number of configured mVPNs is varied with the goal of instance number of configured mVPNs is varied with the goal of
finding maximum number of mVPNs that can be configured and finding maximum number of mVPNs that can be configured and
operational on DUT. Configured mVPN will be considered operational operational on DUT. Configured mVPN will be considered operational
if it satisfies all of following: if it satisfies all of following:
o Tunnel interface associated with this mVPN is operational o Tunnel interface associated with this mVPN is operational
o Default MDT (MI-PMSI) associated with this mVPN is built o Default MDT (MI-PMSI) associated with this mVPN is built
correctly according to core transport protocol rules (PIM for correctly according to core transport protocol rules (PIM for
"ROSEN-8" architecture) ''ROSEN-8'' architecture)
o On both DUT and Remote PE there is at least one PIM neighbor on o On both DUT and Remote PE there is at least one PIM neighbor on
MI-PMSI. This condition is specific to MVPN architectures from MI-PMSI. This condition is specific to MVPN architectures from
[L3VPN-MCAST] that use PIM as PE-PE signaling protocol, such as [L3VPN-MCAST] that use PIM as PE-PE signaling protocol, such as
"ROSEN-8". ''ROSEN-8''.
o There is at least one PIM neighbor on respective DUT's L3VPN C- o There is at least one PIM neighbor on respective DUT's L3VPN C-
interface. interface.
o All traffic flows are being received on ALL expected ports o All traffic flows are being received on ALL expected ports
without any drops. without any drops.
For each test case instance perform steps 1-8 from section 7.1. and For each test case instance perform steps 1-8 from section 7.1. and
1-7 from section 7.2 for all mandatory stimuli in section 7. 1-7 from section 7.2 for all mandatory stimuli in section 7.
skipping to change at page 22, line 24 skipping to change at page 22, line 24
Following are steps to execute this test case: Following are steps to execute this test case:
1. Configure 100 mVPNs on DUT and PE2. Execute number of test case 1. Configure 100 mVPNs on DUT and PE2. Execute number of test case
instances where in each test case instance number of PIM enabled instances where in each test case instance number of PIM enabled
VPN C-interfaces per mVPN is varied with the goal of finding VPN C-interfaces per mVPN is varied with the goal of finding
maximum number of PIM enabled VPN C-interfaces that can be maximum number of PIM enabled VPN C-interfaces that can be
configured and operational on DUT. Configured VPN C-interface will configured and operational on DUT. Configured VPN C-interface will
be considered operational if there is at least one bidirectional be considered operational if there is at least one bidirectional
PIM neighbor in VPN C-instance on configured C-interface. PIM neighbor in VPN C-instance on configured C-interface.
2. Repeat step 1 for 100*I mVPNs where "i=2…N" where N is integer 2. Repeat step 1 for 100*I mVPNs where ''i=2…N'' where N is integer
value for which either maximum number of PIM enabled VPN C- value for which either maximum number of PIM enabled VPN C-
interfaces per mVPN becomes smaller than one or maximum number of interfaces per mVPN becomes smaller than one or maximum number of
mVPNs found in test case 8.1 is reached. mVPNs found in test case 8.1 is reached.
Note that in this test case there SHOULD NOT be any multicast C- Note that in this test case there SHOULD NOT be any multicast C-
instance traffic sources or receivers thus one MUST modify test instance traffic sources or receivers thus one MUST modify test
execution procedure from 7.1 and 7.2. For each test case instance execution procedure from 7.1 and 7.2. For each test case instance
perform steps 1-3,7 from section 7.1. and 1-2,5-7 from section 7.2 perform steps 1-3,7 from section 7.1. and 1-2,5-7 from section 7.2
for all mandatory stimuli in section 7. for all mandatory stimuli in section 7.
skipping to change at page 24, line 39 skipping to change at page 24, line 39
Test will consist of finding maximum number of C-instance PIM Test will consist of finding maximum number of C-instance PIM
neighborships across MDTs by varying average number of PEs per mVPN neighborships across MDTs by varying average number of PEs per mVPN
for set of fixed values of number of mVPNs. Procedure is as for set of fixed values of number of mVPNs. Procedure is as
follows: follows:
1. Configure 100 mVPNs on DUT. Execute number of test case 1. Configure 100 mVPNs on DUT. Execute number of test case
instances where in each test case instance number of PE routers instances where in each test case instance number of PE routers
belonging to each mVPN is varied until maximum number of such belonging to each mVPN is varied until maximum number of such
PE's is found. All mVPNs should have same number of PE routers. PE's is found. All mVPNs should have same number of PE routers.
2. Repeat step 1 for 100*I mVPNs where "i=2…N" where N is integer 2. Repeat step 1 for 100*I mVPNs where ''i=2…N'' where N is integer
value for which either maximum number of PEs per mVPN becomes value for which either maximum number of PEs per mVPN becomes
smaller than one or maximum number of mVPNs found in test case 9.1 smaller than one or maximum number of mVPNs found in test case 9.1
is reached. is reached.
For each test case instance perform steps 1-8 from section 7.1. and For each test case instance perform steps 1-8 from section 7.1. and
1-7 from section 7.2 for all mandatory stimuli in section 7. 1-7 from section 7.2 for all mandatory stimuli in section 7.
Test Result Report: Test Result Report:
Data listed in 8.1 and 8.2 MUST be reported in tabular format for Data listed in 8.1 and 8.2 MUST be reported in tabular format for
skipping to change at page 29, line 6 skipping to change at page 29, line 6
Test Execution Procedure: Test Execution Procedure:
Total number of C-instance PIM mroutes is proportional to product Total number of C-instance PIM mroutes is proportional to product
of number of mVPNs DUT belongs to and average number of C-instance of number of mVPNs DUT belongs to and average number of C-instance
PIM mroutes per mVPN. There are four distinct C-instance mroute PIM mroutes per mVPN. There are four distinct C-instance mroute
types that depending on implementation might be utilizing platform types that depending on implementation might be utilizing platform
resources in different way: (S,G) mroute with MDT Tunnel interface resources in different way: (S,G) mroute with MDT Tunnel interface
in OIL (Outgoing Interface List); (*,G) mroute with MDT Tunnel in OIL (Outgoing Interface List); (*,G) mroute with MDT Tunnel
interface in OIL; (S,G) mroute with MDT Tunnel interface as IIF interface in OIL; (S,G) mroute with MDT Tunnel interface as IIF
(Incoming Interface) and (*,G) mroute with MDT Tunnel interface as (Incoming Interface) and (*,G) mroute with MDT Tunnel interface as
IIF. We will refer to mroute with MDT Tunnel in OIL as "encap IIF. We will refer to mroute with MDT Tunnel in OIL as ''encap
mroute" and to one with MDT Tunnel as IIF as "decap mroute". mroute'' and to one with MDT Tunnel as IIF as ''decap mroute''.
In order to simplify testing we will assume a fixed number of S per In order to simplify testing we will assume a fixed number of S per
each G and thus will not exploit impact ratio of (S,G) to (*,G) each G and thus will not exploit impact ratio of (S,G) to (*,G)
mroutes has on platform resources. However we will address couple mroutes has on platform resources. However we will address couple
of scenarios with respect to ratio of encapsulation to of scenarios with respect to ratio of encapsulation to
decapsulation C-instance mroutes. decapsulation C-instance mroutes.
Note that size of OIL can have significant impact on platform Note that size of OIL can have significant impact on platform
resources and will be addressed in a separate test case: 9.6. resources and will be addressed in a separate test case: 9.6.
In addition depending on implementation it is possible that total In addition depending on implementation it is possible that total
number of C-instance mroutes that platform can support depends on number of C-instance mroutes that platform can support depends on
distribution of mroutes over number of mVPNs. For example, it is distribution of mroutes over number of mVPNs. For example, it is
skipping to change at page 29, line 39 skipping to change at page 29, line 39
mVPN for set of fixed values of number of mVPNs. Procedure is as mVPN for set of fixed values of number of mVPNs. Procedure is as
follows: follows:
1. On DUT and PE2 configure 100 mVPNs. Setup environment such that 1. On DUT and PE2 configure 100 mVPNs. Setup environment such that
all PIM C-instance mroutes are in encap direction. Execute all PIM C-instance mroutes are in encap direction. Execute
number of test case instances using steps 1-7 in section 7.1 number of test case instances using steps 1-7 in section 7.1
where in each test case instance number of C-instance PIM groups where in each test case instance number of C-instance PIM groups
is varied until maximum number of C-instance PIM mroutes is is varied until maximum number of C-instance PIM mroutes is
found. found.
2. Repeat step 1 for 100*I mVPNs where "i=2…N" where N is integer 2. Repeat step 1 for 100*I mVPNs where ''i=2…N'' where N is integer
value for which either maximum number of C-instance PIM mroutes per value for which either maximum number of C-instance PIM mroutes per
mVPN becomes smaller than one or maximum number of mVPNs found in mVPN becomes smaller than one or maximum number of mVPNs found in
test case 9.1 is reached. test case 9.1 is reached.
3. Repeat steps 1 and 2 for two more cases of ratios of encap:decap 3. Repeat steps 1 and 2 for two more cases of ratios of encap:decap
C-instance mroutes: 100% mroutes are in decap direction; C-instance mroutes: 100% mroutes are in decap direction;
10%encap+90%decap. 10%encap+90%decap.
For each test case instance perform steps 1-8 from section 7.1. and For each test case instance perform steps 1-8 from section 7.1. and
1-7 from section 7.2 for all mandatory stimuli in section 7. 1-7 from section 7.2 for all mandatory stimuli in section 7.
skipping to change at page 34, line 24 skipping to change at page 34, line 24
test procedure test procedure
m. Number of C-instance (S,G) flows using sourced data MDTs m. Number of C-instance (S,G) flows using sourced data MDTs
(S-PMSIs):0 (S-PMSIs):0
n. Number of C-instance (S,G) flows using received data MDTs n. Number of C-instance (S,G) flows using received data MDTs
(S-PMSIs):varies (S-PMSIs):varies
Test Execution Procedure: Test Execution Procedure:
Test will consist of varying number of data MDTs (S-PMSIs) for Test will consist of varying number of data MDTs (S-PMSIs) for
flows that have receivers behind DUT (refer to those data MDTs (S- flows that have receivers behind DUT (refer to those data MDTs (S-
PMSI) as "received data MDTs"). During all test case instances PMSI) as ''received data MDTs''). During all test case instances
total number of C-instance PIM mroutes MUST remain constant and total number of C-instance PIM mroutes MUST remain constant and
will be [Smax/4] rounded to the first lower integer. We will vary will be [Smax/4] rounded to the first lower integer. We will vary
total number of received data MDTs (S-PMSIs) by varying number of total number of received data MDTs (S-PMSIs) by varying number of
mVPNs configured to use data MDTs (S-PMSIs) at the remote PE that mVPNs configured to use data MDTs (S-PMSIs) at the remote PE that
has sources behind it, while number of data MDTs (S-PMSIs) per has sources behind it, while number of data MDTs (S-PMSIs) per
mVPNs will be same for all mVPNs that use them. If given mVPN is mVPNs will be same for all mVPNs that use them. If given mVPN is
using data MDTs (S-PMSIs) in particular test case instance number using data MDTs (S-PMSIs) in particular test case instance number
of them should be Dvpn=[Smax/(4*Vmax)] rounded to first lower value of them should be Dvpn=[Smax/(4*Vmax)] rounded to first lower value
that can be represented as 2^I where I is an integer. Note that that can be represented as 2^I where I is an integer. Note that
number of data MDTs (S-PMSIs) configured and sourced by DUT MUST be number of data MDTs (S-PMSIs) configured and sourced by DUT MUST be
skipping to change at page 39, line 19 skipping to change at page 39, line 19
mroutes and data MDTs (S-PMSIs) constant. By doing this one can mroutes and data MDTs (S-PMSIs) constant. By doing this one can
assess impact of data MDT reuse. assess impact of data MDT reuse.
Procedure is as follows: Procedure is as follows:
1. Configure test apparatus such that number of flows using data 1. Configure test apparatus such that number of flows using data
MDTs (S-PMSIs) is the same as number of data MDTs (S-PMSIs), MDTs (S-PMSIs) is the same as number of data MDTs (S-PMSIs),
i.e. there is no data MDT reuse by multiple traffic flows. i.e. there is no data MDT reuse by multiple traffic flows.
Execute steps 1-7 in section 7.1 and 1-8 in section 7.2 Execute steps 1-7 in section 7.1 and 1-8 in section 7.2
2. Repeat step 1 for 10*I flows where "i=2…N" where N is integer 2. Repeat step 1 for 10*I flows where ''i=2…N'' where N is integer
value for which either maximum number of flows mapped to data value for which either maximum number of flows mapped to data
MDT (S-PMSI) is reached or number of flows becomes equal to MDT (S-PMSI) is reached or number of flows becomes equal to
number of (S,G) C-instance mroutes. number of (S,G) C-instance mroutes.
For each test case instance perform steps 1-8 from section 7.1. and For each test case instance perform steps 1-8 from section 7.1. and
1-7 from section 7.2 for all mandatory stimuli in section 7. 1-7 from section 7.2 for all mandatory stimuli in section 7.
Test Result Report: Test Result Report:
Data listed in 8.1 and 8.2 MUST be reported in tabular format for Data listed in 8.1 and 8.2 MUST be reported in tabular format for
skipping to change at page 39, line 43 skipping to change at page 39, line 43
Test Objective: Test Objective:
MI-PMSI functions as a broadcast network and standard PIM LAN (Local MI-PMSI functions as a broadcast network and standard PIM LAN (Local
Area Network) procedures, including PIM J/P Suppression, can be used. Area Network) procedures, including PIM J/P Suppression, can be used.
Depending on distribution of C-instance sources, RPs and receivers in Depending on distribution of C-instance sources, RPs and receivers in
MVPN network capability to perform J/P Suppression can have great MVPN network capability to perform J/P Suppression can have great
impact on overall scale capabilities of PE devices. In particular impact on overall scale capabilities of PE devices. In particular
largest impact is on scale capabilities of PE router whose attached largest impact is on scale capabilities of PE router whose attached
customers source large number of multicast flows or host large number customers source large number of multicast flows or host large number
of RPs (refer to such PE as "source" PE)in the network with large of RPs (refer to such PE as ''source'' PE)in the network with large
number of PE routers with receivers for those flows. However function number of PE routers with receivers for those flows. However function
of PIM J/P Suppression is performed by all PE devices that have of PIM J/P Suppression is performed by all PE devices that have
receivers behind them (refer to such PE as "receiving" PE). Goal of receivers behind them (refer to such PE as ''receiving'' PE). Goal of
this test case is to assess capability of "receiving" PE to perform this test case is to assess capability of ''receiving'' PE to perform
J/P suppression for large amount of C-instance multicast routes. J/P suppression for large amount of C-instance multicast routes.
Metric Variables Relationships: Metric Variables Relationships:
Num_PIM_MI_PMSI_Neigh = 2*Num_mVPN Num_PIM_MI_PMSI_Neigh = 2*Num_mVPN
Num_MC_C_ints = Num_PIM_C_neigh = Num_mVPN Num_MC_C_ints = Num_PIM_C_neigh = Num_mVPN
(Num_*G_C + Num_SG_C)>> Num_mVPN (Num_*G_C + Num_SG_C)>> Num_mVPN
skipping to change at page 42, line 8 skipping to change at page 42, line 8
Test Execution Procedure: Test Execution Procedure:
For maximum number of C-instances multicast routes obtained in test For maximum number of C-instances multicast routes obtained in test
case 9.5 for 100 mVPNs and 100% mroutes in decap direction perform case 9.5 for 100 mVPNs and 100% mroutes in decap direction perform
following: following:
1) Establish all PIM session required to emulate defined 1) Establish all PIM session required to emulate defined
topology topology
2) Perform all C-instance PIM joins from "Rx2" (test 2) Perform all C-instance PIM joins from ''Rx2'' (test
apparatus port B5 in topology diagram) apparatus port B5 in topology diagram)
3) Start all traffic from "Src" (test apparatus port R1 in 3) Start all traffic from ''Src'' (test apparatus port R1 in
topology diagram) and wait until steady state is topology diagram) and wait until steady state is
achieved. achieved.
4) On C-instance PIM session (established over MI-PMSI) of 4) On C-instance PIM session (established over MI-PMSI) of
test apparatus port "Src" (B2) measure number of J/P PDUs test apparatus port ''Src'' (B2) measure number of J/P PDUs
received in 10 minute (J1) interval and calculate rate of received in 10 minute (J1) interval and calculate rate of
J/P PDUs as JR1=J1/(60*10) J/P PDUs as JR1=J1/(60*10)
5) Perform all C-instance PIM joins from test apparatus port 5) Perform all C-instance PIM joins from test apparatus port
"Rx1" (R1) and wait until steady state is achieved on ''Rx1'' (R1) and wait until steady state is achieved on
DUT. DUT.
6) On C-instance PIM session (established over MI-PMSI) of 6) On C-instance PIM session (established over MI-PMSI) of
test apparatus port "Src" (B2) measure number of J/P PDUs test apparatus port ''Src'' (B2) measure number of J/P PDUs
received in 10 minute (J2) interval and calculate rate of received in 10 minute (J2) interval and calculate rate of
J/P PDUs as JR2=J2/(60*10) J/P PDUs as JR2=J2/(60*10)
7) If JR2 < 1.2*JR1 we can conclude that DUT is suppressing 7) If JR2 < 1.2*JR1 we can conclude that DUT is suppressing
J/P messages successfully. J/P messages successfully.
Repeat steps 1-7, for maximum number of C-instances multicast routes Repeat steps 1-7, for maximum number of C-instances multicast routes
obtained in test case 9.5 for maximum number of mVPN and 100% state obtained in test case 9.5 for maximum number of mVPN and 100% state
in decap direction. in decap direction.
Note that no failure recovery testing is required in this test case. Note that no failure recovery testing is required in this test case.
Test Result Report: Test Result Report:
Data listed in 8.1 MUST be reported in tabular format for all test Data listed in 8.1 MUST be reported in tabular format for all test
case instances. In addition rates JR1 and JR2 MUST be reported. case instances. In addition rates JR1 and JR2 MUST be reported.
Optionally one can report absolute numbers or rates of number of Optionally one can report absolute numbers or rates of number of
PIM J/P PDUs transmitted by DUT and PE3 (test apparatus port B5). PIM J/P PDUs transmitted by DUT and PE3 (test apparatus port B5).
9.11 Additional Tests and Considerations for Devices Lacking "Efficient" 9.11 Additional Tests and Considerations for Devices Lacking ''Efficient''
Join/Prune Suppression Join/Prune Suppression
If 9.10 revealed that device does not perform J/P suppression, repeat If 9.10 revealed that device does not perform J/P suppression, repeat
test case 9.5 where for all groups in encapsulation direction, J/P test case 9.5 where for all groups in encapsulation direction, J/P
messages are sent from more than one remote PE router, i.e. number of messages are sent from more than one remote PE router, i.e. number of
remote PE routers with receivers becomes additional variable. One remote PE routers with receivers becomes additional variable. One
MUST execute test for at least 3 values of number of remote PE MUST execute test for at least 3 values of number of remote PE
routers with receivers. It is suggested to chose values such that routers with receivers. It is suggested to chose values such that
product of number of PE routers with receivers and number of mVPNs is product of number of PE routers with receivers and number of mVPNs is
50% of maximum number of PIM neighbors over MI-PMSIs achieved in test 50% of maximum number of PIM neighbors over MI-PMSIs achieved in test
skipping to change at page 43, line 21 skipping to change at page 43, line 21
In addition, in test cases 9.12-9.17, test apparatus MUST be In addition, in test cases 9.12-9.17, test apparatus MUST be
configured such that all remote PEs are sending J/P message for any configured such that all remote PEs are sending J/P message for any
given C-instance encapsulation group. On contrary if 9.10 revealed given C-instance encapsulation group. On contrary if 9.10 revealed
that DUT platform efficiently performs J/P suppression, test that DUT platform efficiently performs J/P suppression, test
apparatus MUST be configured such that only one remote PE is sending apparatus MUST be configured such that only one remote PE is sending
J/P message for any given C-instance encapsulation group. J/P message for any given C-instance encapsulation group.
Note that PIM Join/Prune suppression is relevant only for MVPN Note that PIM Join/Prune suppression is relevant only for MVPN
architectures from [L3VPN-MCAST] that utilize PIM as PE-to-PE architectures from [L3VPN-MCAST] that utilize PIM as PE-to-PE
signaling such as "ROSEN-8" architecture. However, even if other signaling such as ''ROSEN-8'' architecture. However, even if other
PE-to-PE signaling methods are to be used for exchanging C-instance PE-to-PE signaling methods are to be used for exchanging C-instance
PIM messages, the testing of C-instance PIM Join/Prune message rate PIM messages, the testing of C-instance PIM Join/Prune message rate
is still relevant. For example, if BGP is used as PE-PE signaling is still relevant. For example, if BGP is used as PE-PE signaling
distributing C-instance multicast routes , the rate of PIM messages distributing C-instance multicast routes , the rate of PIM messages
and its impact on PE depends on whether Route reflector to PE mroute and its impact on PE depends on whether Route reflector to PE mroute
filtering is implemented. In addition, when BGP is used as PE-PE filtering is implemented. In addition, when BGP is used as PE-PE
signaling mechanism, the impact on Route Reflectors has to be also signaling mechanism, the impact on Route Reflectors has to be also
measured but is beyond scope of this document. measured but is beyond scope of this document.
9.12 Scale of mVPNs spanning large number of PEs 9.12 Scale of mVPNs spanning large number of PEs
skipping to change at page 44, line 23 skipping to change at page 44, line 23
Num_OIF_C = Num_mVPN = 60 * Num_mVPN Num_OIF_C = Num_mVPN = 60 * Num_mVPN
Num_SPMSI_Rx = 8*Num_mVPN Num_SPMSI_Rx = 8*Num_mVPN
Num_SPMSI_Src = 2*Num_mVPN Num_SPMSI_Src = 2*Num_mVPN
Num_SPMSI_RxFlows = 18*Num_mVPN Num_SPMSI_RxFlows = 18*Num_mVPN
Num_SPMSI_SrcFlows = 2*Num_mVPN Num_SPMSI_SrcFlows = 2*Num_mVPN
Num_SG_P, Num_*G_P - depends on PIM protocol variant used for MI- Num_SG_P, Num_*G_P - depends on PIM protocol variant used for
PMSIs MI-PMSIs
Test Setup: Test Setup:
Following test setup MUST be performed prior to executing this test Following test setup MUST be performed prior to executing this test
case case
1. Topology: Reference Topology #1 1. Topology: Reference Topology #1
2. P-instance Multicast Configuration: 2. P-instance Multicast Configuration:
a. Protocol for Default MDT groups: varies a. Protocol for Default MDT groups: varies
b. RP location for Default MDT groups: P router b. RP location for Default MDT groups: P router
skipping to change at page 46, line 40 skipping to change at page 46, line 40
Num_OIF_C = Num_mVPN = 600 * Num_mVPN Num_OIF_C = Num_mVPN = 600 * Num_mVPN
Num_SPMSI_Rx = 8*Num_mVPN Num_SPMSI_Rx = 8*Num_mVPN
Num_SPMSI_Src = 2*Num_mVPN Num_SPMSI_Src = 2*Num_mVPN
Num_SPMSI_RxFlows = 225*Num_mVPN Num_SPMSI_RxFlows = 225*Num_mVPN
Num_SPMSI_SrcFlows = 25*Num_mVPN Num_SPMSI_SrcFlows = 25*Num_mVPN
Num_SG_P, Num_*G_P - depends on PIM protocol variant used for MI- Num_SG_P, Num_*G_P - depends on PIM protocol variant used for
PMSIs MI-PMSIs
Test Setup: Test Setup:
Following test setup MUST be performed prior to executing this test Following test setup MUST be performed prior to executing this test
case case
1. Topology: Reference Topology #1 1. Topology: Reference Topology #1
2. P-instance Multicast Configuration: 2. P-instance Multicast Configuration:
a. Protocol for Default MDT groups: varies a. Protocol for Default MDT groups: varies
b. RP location for Default MDT groups: P router b. RP location for Default MDT groups: P router
skipping to change at page 48, line 21 skipping to change at page 48, line 21
For each test case instance perform steps 1-8 from section 7.1. and For each test case instance perform steps 1-8 from section 7.1. and
1-7 from section 7.2 for all mandatory stimuli in section 7. 1-7 from section 7.2 for all mandatory stimuli in section 7.
Test Result Report: Test Result Report:
Data listed in 8.1 and 8.2 MUST be reported in tabular format for Data listed in 8.1 and 8.2 MUST be reported in tabular format for
at least maximum value of number of mVPNs achieved. It is DESIRED at least maximum value of number of mVPNs achieved. It is DESIRED
to include the same data for at least 5 different values of number to include the same data for at least 5 different values of number
of mVPNs (i.e. for at least 5 test case instances). of mVPNs (i.e. for at least 5 test case instances).
9.14 Scale of "average" size mVPNs 9.14 Scale of ''average'' size mVPNs
Test Objective: Test Objective:
As we noted mVPN scale is multidimensional and depends on number of As we noted mVPN scale is multidimensional and depends on number of
variables. While test cases 9.1-9.11 focused on only one or two variables. While test cases 9.1-9.11 focused on only one or two
variables at the time while minimizing impact of all others, they variables at the time while minimizing impact of all others, they
don't give good representation of platform capabilities in more don't give good representation of platform capabilities in more
realistic deployment scenarios where none of variables are realistic deployment scenarios where none of variables are
minimized. While test cases 9.12 and 9.13 assess two more extreme minimized. While test cases 9.12 and 9.13 assess two more extreme
cases with respect to number of PE routers and mVPN routes, cases with respect to number of PE routers and mVPN routes,
skipping to change at page 49, line 8 skipping to change at page 49, line 8
Num_OIF_C = Num_mVPN = 200 * Num_mVPN Num_OIF_C = Num_mVPN = 200 * Num_mVPN
Num_SPMSI_Rx = 8*Num_mVPN Num_SPMSI_Rx = 8*Num_mVPN
Num_SPMSI_Src = 2*Num_mVPN Num_SPMSI_Src = 2*Num_mVPN
Num_SPMSI_RxFlows = 72*Num_mVPN Num_SPMSI_RxFlows = 72*Num_mVPN
Num_SPMSI_SrcFlows = 8*Num_mVPN Num_SPMSI_SrcFlows = 8*Num_mVPN
Num_SG_P, Num_*G_P - depends on PIM protocol variant used for MI- Num_SG_P, Num_*G_P - depends on PIM protocol variant used for
PMSIs MI-PMSIs
Test Setup: Test Setup:
Following test setup MUST be performed prior to executing this test Following test setup MUST be performed prior to executing this test
case case
1. Topology: Reference Topology #1 1. Topology: Reference Topology #1
2. P-instance Multicast Configuration: 2. P-instance Multicast Configuration:
a. Protocol for Default MDT groups: varies a. Protocol for Default MDT groups: varies
b. RP location for Default MDT groups: P router b. RP location for Default MDT groups: P router
skipping to change at page 53, line 36 skipping to change at page 53, line 36
Num_OIF_C = Num_mVPN = 200 * Num_mVPN Num_OIF_C = Num_mVPN = 200 * Num_mVPN
Num_SPMSI_Rx = 8*Num_mVPN Num_SPMSI_Rx = 8*Num_mVPN
Num_SPMSI_Src = 2*Num_mVPN Num_SPMSI_Src = 2*Num_mVPN
Num_SPMSI_RxFlows = 72*Num_mVPN Num_SPMSI_RxFlows = 72*Num_mVPN
Num_SPMSI_SrcFlows = 8*Num_mVPN Num_SPMSI_SrcFlows = 8*Num_mVPN
Num_SG_P, Num_*G_P - depends on PIM protocol variant used for MI- Num_SG_P, Num_*G_P -depends on PIM protocol variant used for
PMSIs MI-PMSIs
Test Setup: Test Setup:
Following test setup MUST be performed prior to executing this test Following test setup MUST be performed prior to executing this test
case case
1.Topology: Reference Topology #1 1.Topology: Reference Topology #1
2.P-instance Multicast Configuration: 2.P-instance Multicast Configuration:
a. Protocol for Default MDT groups: PIM-SM (ASM) a. Protocol for Default MDT groups: PIM-SM (ASM)
b. RP location for Default MDT groups: P router b. RP location for Default MDT groups: P router
skipping to change at page 55, line 9 skipping to change at page 55, line 9
instance number of configured mVPNs is varied with the goal of instance number of configured mVPNs is varied with the goal of
finding maximum number of mVPNs that platform can support in this finding maximum number of mVPNs that platform can support in this
environment. mVPN instance here includes C-instance state, OIFs, environment. mVPN instance here includes C-instance state, OIFs,
PIM neighborships and data MDTs (S-PMSIs) as specified by Test PIM neighborships and data MDTs (S-PMSIs) as specified by Test
Setup. Setup.
For each test case instance perform following steps: For each test case instance perform following steps:
a. Steps 1-4 from section 7.1. a. Steps 1-4 from section 7.1.
b. Send PIM Register messages from all "source" test apparatus b. Send PIM Register messages from all ''source'' test apparatus
ports ports
c. Test apparatus should verify that correct (S,G) PIM Join c. Test apparatus should verify that correct (S,G) PIM Join
messages had been received by "source" test apparatus port. messages had been received by ''source'' test apparatus port.
In reaction to receipt of (S,G) joins, source test In reaction to receipt of (S,G) joins, source test
apparatus ports should start transmitting multicast traffic apparatus ports should start transmitting multicast traffic
to appropriate multicast groups and start sending Data- to appropriate multicast groups and start sending Data-
header Registers [RFC4601]. header Registers [RFC4601].
d. Steps 6-8 from section 7.1. d. Steps 6-8 from section 7.1.
For all mandatory stimuli defined in section 7 perform following For all mandatory stimuli defined in section 7 perform following
steps: steps:
skipping to change at page 56, line 12 skipping to change at page 56, line 12
We would like to thank Aamer Akhter, Arjen Boers, Yiqun Cai, Min Li, We would like to thank Aamer Akhter, Arjen Boers, Yiqun Cai, Min Li,
Amal Maalouf, Mike McBride, Ciprian Popoviciu, Dan Williston, Rajiv Amal Maalouf, Mike McBride, Ciprian Popoviciu, Dan Williston, Rajiv
Asati and Thomas Morin for their valuable feedback on content of this Asati and Thomas Morin for their valuable feedback on content of this
draft. We would like to thank Nick Satsia for his support with test draft. We would like to thank Nick Satsia for his support with test
verification of this draft. verification of this draft.
13 References 13 References
13.1 Normative References 13.1 Normative References
[MVPN-REQ] T. Morin, Ed., "Requirements for Multicast in L3 Provider- [MVPN-REQ] T. Morin, Ed., ''Requirements for Multicast in L3 Provider-
Provisioned VPNs", draft-ietf-l3vpn-ppvpn-mcast-reqts-09.txt Provisioned VPNs'', draft-ietf-l3vpn-ppvpn-mcast-reqts-09.txt
[L3VPN-MCAST] E. Rosen, R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", [L3VPN-MCAST] E. Rosen, R. Aggarwal, ''Multicast in MPLS/BGP IP VPNs'',
draft-ietf-l3vpn-2547bis-mcast-03.txt draft-ietf-l3vpn-2547bis-mcast-03.txt
[RFC4364] E.Rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private Networks [RFC4364] E.Rosen, Y. Rekhter, ''BGP/MPLS IP Virtual Private Networks
(VPNs)" (VPNs)''
[RFC4601] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol [RFC4601] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, ''Protocol
Independent Multicast - Sparse Mode (PIM-SM):Protocol Specification" Independent Multicast - Sparse Mode (PIM-SM):Protocol Specification''
13.2 Informative References 13.2 Informative References
[ROSEN-8] E. Rosen, Y. Cai, I. Wijnands, "Multicast in MPLS/BGP IP [ROSEN-8] E. Rosen, Y. Cai, I. Wijnands, "Multicast in MPLS/BGP IP
VPNs", draft-rosen-vpn-mcast-08.txt VPNs", draft-rosen-vpn-mcast-08.txt
[MVPN-BCP] Y. Cai, M. McBride, C. Hall, M. Napierala, "Multicast VPN [MVPN-BCP] Y. Cai, M. McBride, C. Hall, M. Napierala, ''Multicast VPN
Deployment Recommendations", draft-ycai-mboned-mvpn-deploy-00.txt Deployment Recommendations'', draft-ycai-mboned-mvpn-deploy-00.txt
Author's Addresses Author's Addresses
Silvija A. Dry Silvija A. Dry
Cisco Cisco
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
sdry@cisco.com sdry@cisco.com
Fernando Calabria Fernando Calabria
Cisco Cisco
skipping to change at page 58, line 19 skipping to change at page 58, line 19
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are This document and the information contained herein are provided on
provided on an "AS IS" basis and THE CONTRIBUTOR, THE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED FOR A PARTICULAR PURPOSE.
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 64 change blocks. 
95 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/