One document matched: draft-ietf-l2vpn-vpls-mcast-reqts-07.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2475 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2475.xml'>
<!ENTITY rfc3809 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3809.xml'>
<!ENTITY rfc4601 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4601.xml'>
<!ENTITY rfc1112 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1112.xml'>
<!ENTITY rfc3376 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3376.xml'>
<!ENTITY rfc3973 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3973.xml'>
<!ENTITY rfc2236 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2236.xml'>
<!ENTITY rfc2710 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2710.xml'>
<!ENTITY rfc3810 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3810.xml'>
<!ENTITY rfc3488 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3488.xml'>
<!ENTITY rfc4541 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4541.xml'>
<!ENTITY rfc4607 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4607.xml'>
<!ENTITY rfc4664 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4664.xml'>
<!ENTITY rfc4665 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4665.xml'>
<!ENTITY rfc4761 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4761.xml'>
<!ENTITY rfc4762 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4762.xml'>
<!ENTITY rfc4834 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4834.xml'>
<!ENTITY rfc4875 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4875.xml'>
<!ENTITY rfc5015 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5015.xml'>
<!ENTITY I-D.ietf-mpls-ldp-p2mp PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-ldp-p2mp.xml'>
]>
<rfc category="info" ipr="trust200811" docName="draft-ietf-l2vpn-vpls-mcast-reqts-07.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact='yes'?>
<?rfc subcompact='yes'?>
<front>
<title abbrev="Multicast VPLS Requirements">
Requirements for Multicast Support in Virtual Private LAN Services
</title>
<author initials='Y.' surname="Kamite" fullname='Yuji Kamite' role="editor">
<organization abbrev="NTT Communications">
NTT Communications Corporation
</organization>
<address>
<postal>
<street>Granpark Tower</street>
<street>3-4-1 Shibaura, Minato-ku</street>
<region>Tokyo</region>
<code>108-8118</code>
<country>Japan</country>
</postal>
<email>y.kamite@ntt.com</email>
</address>
</author>
<author initials='Y.' surname="Wada" fullname='Yuichiro Wada'>
<organization abbrev="NTT">
NTT
</organization>
<address>
<postal>
<street>3-9-11 Midori-cho</street>
<street>Musashino-shi</street>
<region>Tokyo</region>
<code>180-8585</code>
<country>Japan</country>
</postal>
<email>wada.yuichiro@lab.ntt.co.jp</email>
</address>
</author>
<author initials='Y.' surname="Serbest" fullname='Yetik Serbest'>
<organization abbrev="AT&T">AT&T Labs</organization>
<address>
<postal>
<street>9505 Arboretum Blvd.</street>
<city>Austin</city> <region>TX</region>
<code>78759</code>
<country>USA</country>
</postal>
<email>yetik_serbest@labs.att.com</email>
</address>
</author>
<author initials='T.' surname='Morin' fullname='Thomas Morin'>
<organization abbrev="France Telecom">France Telecom R&D</organization>
<address>
<postal>
<street>2, avenue Pierre-Marzin</street>
<city>22307 Lannion Cedex</city>
<country>France</country>
</postal>
<email>thomas.morin@francetelecom.com</email>
</address>
</author>
<author initials='L.' surname='Fang' fullname='Luyuan Fang'>
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>300 Beaver Brook Road</street>
<city>Boxborough</city> <region>MA</region>
<code>01719</code>
<country>USA</country>
</postal>
<email>lufang@cisco.com</email>
</address>
</author>
<date day="15" month="Jan" year="2009"/>
<abstract>
<t>
This document provides functional requirements for network solutions that support
multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from
the end user and service provider standpoints.
It is intended that potential solutions will use these requirements as guidelines.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Background">
<t>
VPLS (Virtual Private LAN Service) is a provider service that emulates the
full functionality of a traditional Local Area Network (LAN). VPLS interconnects
several customer LAN segments over a packet switched network (PSN) backbone,
creating a multipoint-to-multipoint Ethernet VPN. For customers,
their remote LAN segments behave as one single LAN.
</t>
<t>
In a VPLS, the provider network emulates a learning bridge, and forwarding
takes place based on Ethernet MAC learning. Hence, a VPLS requires
MAC address learning/aging on a per PW (Pseudo Wire) basis, where forwarding decisions
treat the PW as a "bridge port".
</t>
<t>
VPLS is a Layer-2 service. However, it provides two applications
from the customer's point of view:
</t>
<t>
<list style='empty'>
<t>
- LAN Routing application: providing connectivity
between customer routers
</t>
<t>
- LAN Switching application: providing connectivity
between customer Ethernet switches
</t>
</list>
</t>
<t>
Thus, in some cases, customers across MAN/WAN have transparent
Layer-2 connectivity while their main goal is to run Layer-3
applications within their routing domain. As a result, different
requirements arise from their variety of applications.
</t>
<t>
Originally, PEs (Provider Edges) in VPLS transport broadcast/multicast Ethernet frames by
replicating all multicast/broadcast frames received from an AC to all
PW's corresponding to a particular VSI. Such a technique has the
advantage of keeping the P (Provider Router) and PE devices completely unaware of IP
multicast-specific issues. Obviously, however, it has quite a few
scalability drawbacks in terms of bandwidth consumption, which will lead to
increased cost in large-scale deployment.
</t>
<t>
Meanwhile, there is a growing need for support of multicast-based
services such as IP TV. This commercial trend makes it necessary for
most VPLS deployments to support multicast more efficiently than
before. It is also necessary as customer routers are now likely to be
running IP multicast protocols and those routers and connected to
switches that will be handling large amounts of multicast traffic.
</t>
<t>
Therefore, it is desirable to have more efficient techniques to
support IP multicast over VPLS.
</t>
</section>
<section title="Scope of this document">
<t>
This document provides functional requirements for network solutions
that support IP multicast in VPLS <xref target="RFC4761"/>
<xref target="RFC4762"/>.
It identifies requirements that MAY apply to the existing base VPLS
architecture in order to optimize IP multicast. It also complements
the generic L2 VPN requirements document <xref target="RFC4665"/>,
by specifying additional requirements specific to the
deployment of IP multicast in VPLS.
</t>
<t>
The technical specifications are outside the scope of this
document. There is no intent to either specify
solution-specific details in this document or application-specific
requirements. Also, this document does NOT aim to express
multicast-inferred requirements that are not specific to VPLS. It does NOT
aim to express any requirements for native Ethernet specifications, either.
</t>
<t>
This document is proposed as a solution guideline and a checklist of
requirements for solutions, by which we will evaluate how each solution
satisfies the requirements.
</t>
<t>
This document clarifies the needs from both VPLS customer as well as
provider standpoints and formulates the problems that should be
addressed by technical solutions while staying solution agnostic.
</t>
<t>
A technical solution and corresponding service which supports this
document's requirements are hereinafter called a "multicast VPLS".
</t>
</section>
</section>
<section title="Conventions used in this document">
<section title="Terminology">
<t>
The reader is assumed to be familiar with the terminology, reference models
and taxonomy defined in
<xref target="RFC4664"/>
and
<xref target="RFC4665"/>.
For readability purposes, we repeat some of the terms here.
</t>
<t>
Moreover, we also propose some other terms needed
when IP multicast support in VPLS is discussed.
</t>
<t>
<list style='hanging'>
<t hangText='- ASM:'>
Any Source Multicast. One of the two multicast
service models where each corresponding service can have an arbitrary number of
senders.
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='- G:'>
denotes a multicast group.
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='- MDTunnel:'>
Multicast Distribution Tunnel,
the means by which the
customer's multicast traffic will be conveyed across the SP
network. This is meant in a generic way: such tunnels can be
point-to-point, point-to-multipoint or
multipoint-to-multipoint. Although this
definition may seem to assume that distribution tunnels are
unidirectional, the wording encompasses bi-directional tunnels
as well.
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='- Multicast Channel:'>
In the multicast SSM (Source Specific Multicast) model <xref target="RFC4607"/>,
a "multicast channel" designates traffic from a specific source S to a multicast group
G. Also denominated as "(S,G)".
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='- Multicast domain:'>
An area in which multicast data is transmitted. In
this document, this term has a generic meaning which can refer to
Layer-2 and Layer-3. Generally, the Layer-3 multicast domain is
determined by the Layer-3 multicast protocol used to establish
reachability between all potential receivers in the corresponding
domain. The Layer-2 multicast domain can be the same as the Layer-2
broadcast domain (i.e., VLAN), but it may be restricted to being smaller
than the Layer-2 broadcast domain if an additional control protocol is
used.
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='- CE:'>
Customer Edge Device.
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='- PE:'>
Provider Edge.
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='- P:'>
Provider Router.
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='- S:'>
denotes a multicast source.
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='- SP:'>
Service Provider.
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='- SSM:'>
Source Specific Multicast. One of the two multicast
service models where each corresponding service relies upon the use of a
single source.
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='- U-PE/N-PE:'>
The device closest to the customer/user is called User
facing PE (U-PE) and the device closest to the core network is
called Network facing PE (N-PE).
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='- VPLS instance:'>
A service entity manageable in VPLS architecture. All CE devices participating in a
single VPLS instance appear to be on the same LAN, composing a VPN across the SP's
network.
A VPLS instance corresponds to a group of VSIs that are interconnected
using PWs (Pseudo Wires).
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='- VSI:'>
Virtual Switching Instance.
VSI is a logical entity in a PE that
maps multiple ACs (Attachment Circuits) to multiple PWs (Pseudo Wires).
The VSI is populated in much the same way as a standard bridge populates its
forwarding table.
Each PE device may have multiple VSIs, where each VSI belongs to a different
VPLS instance.
</t>
</list>
</t>
</section>
<section title="Conventions">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in
<xref target="RFC2119"/>
.
</t>
</section>
</section>
<section title="Problem Statements">
<section title="Motivation">
<t>
Today, many kinds of IP multicast services
are becoming available.
Over their Layer-2 VPN service,
particularly over VPLS, customers would often like to
operate their multicast applications to remote sites.
Also, VPN service providers using an IP-based networks
expect that such Layer-2 network
infrastructure will efficiently support multicast data traffic.
</t>
<t>
However, VPLS has a shortcoming as it relates to multicast scalability as mentioned
below because of the replication mechanisms intrinsic to
the original architecture. Accordingly, the primary goal for technical
solutions is to solve this issue partially or completely, and provide
efficient ways to support IP multicast services over VPLS.
</t>
</section>
<section title="Multicast Scalability">
<t>In VPLS, replication occurs at an ingress PE
(in H-VPLS case, at N-PE) when a CE sends (1) Broadcast,
(2) Multicast or (3) Unknown destination unicast. There are two well
known issues with this approach:
</t>
<t>Issue A: Replication to non-member site</t>
<t>
<list style='empty'>
<t>
In case (1) and (3), the upstream PE has to transmit packets to
all of the downstream PEs which belong to the common VPLS instance.
You cannot decrease the number of members, so this is
basically an inevitable situation for most VPLS deployments.
<vspace blankLines="1" />
In case (2), however, there is an issue that multicast traffic is
sent to sites with no members. Usually this is caused when
the upstream PE does not maintain downstream membership information.
The upstream PE simply floods frames to all downstream PEs, and
the downstream PEs forward them to directly connected CEs; however,
those CEs might not be the members of any multicast group. From the
perspective of customers, they might suffer from pressure on their
own resources due to unnecessary traffic. From the perspective of
SPs, they would not like wasteful over-provisioning to cover such
traffic.
</t>
</list>
</t>
<t>Issue B: Replication of PWs on shared physical path</t>
<t>
<list style='empty'>
<t>
In VPLS, a VSI associated with each VPLS instance behaves as a logical
emulated bridge which can transport Ethernet across the PSN backbone
using PWs. In principle, PWs are designed for unicast traffic.
<vspace blankLines="1" />
In all cases (1), (2) and (3), Ethernet frames are replicated on
one or more PWs that belong to that VSI. This replication is
often inefficient in terms of bandwidth usage if those PWs are
traversing shared physical links in the backbone.
<vspace blankLines="1" />
For instance, suppose there are 20 remote PEs belonging to
a particular VPLS instance, and all PWs
happen to be traversing
over the same link from one local PE
to its next-hop P. In this case,
even if a CE sends 50Mbps to the local PE, the total bandwidth
of that link will be to 1000Mbps.
<vspace blankLines="1" />
Note that while traditional 802.1D Ethernet switches
replicate broadcast/multicast flows
once at most per output interface, VPLS often needs to transmit
one or more flows duplicated over the same output interface.
<vspace blankLines="1" />
From the
perspective of customers, there is no serious issue
because they do not know what happens in the
core. However, from the
perspective of SPs, unnecessary replication brings the risk of
resource exhaustion when the number of PWs increases.
</t>
</list>
</t>
<t>
In both issues A and B, these undesirable situations will become
obvious with the wide-spread use of IP multicast applications by customers.
Naturally the problem
will become more serious as the number of sites grows.
In other words, there are concerns over the scalability of multicast in VPLS today.
</t>
</section>
<section title="Application Considerations">
<section title="Two Perspectives of the Service">
<t>
When it comes to IP multicast over VPLS, there are
two different aspects in terms of service provisioning.
They are closely related to the functional requirements from
two technical standpoints: Layer-2 and Layer-3.
</t>
<t>- Native Ethernet service aspect</t>
<t>
<list style='empty'>
<t>
This aspect mainly affects Ethernet network service operators.
Their main interest is to solve the issue that
existing VPLS deployments cannot always handle multicast/broadcast
frames efficiently.
<vspace blankLines="1" />
Today, wide-area Ethernet services are becoming
popular, and VPLS can be utilized to provide wide-area LAN
services.
As customers come to use
various kinds of content distribution applications which use
IP multicast (or other protocols which lead to multicast/broadcast
in the Ethernet layer), the total amount of traffic will
also grow. In addition, considerations of OAM, security and
other related points in multicast in view of Layer-2 are
important as well.
<vspace blankLines="1" />
In such circumstances, the native VPLS
specification would not always be satisfactory
if multicast traffic is more dominant
in total resource utilization than before.
The scalability issues mentioned in
the previous section are expected to be solved.
</t>
</list>
</t>
<t>- IP multicast service aspect</t>
<t>
<list style='empty'>
<t>
This aspect mainly affects both IP service providers
and end users.
Their main interest is to provide IP multicast
services transparently but effectively
by means of VPLS as a network infrastructure.
<vspace blankLines="1" />
SPs might expect VPLS as an access/metro
network to deliver multicast traffic (such as Triple-play
(Video, Voice, Data) and Multicast IP VPNs) in an efficient way.
</t>
</list>
</t>
</section>
</section>
</section>
<section title="General Requirements">
<t>
We assume the basic requirements for
VPLS written in
<xref target="RFC4665"/>
are fulfilled if there is no
special reference in this document.
</t>
<section title="Scope of Transport">
<section title="Traffic Types">
<section title="Multicast and Broadcast">
<t>
As described before, any solution is expected to have mechanisms
for efficient transport of IP multicast.
Multicast is related to both issues A and B (see section 3.2.); however,
broadcast is
related to issue B only because it does not need membership control.
</t>
<t>
<list style='hanging'>
<t hangText='-'>
A multicast VPLS solution SHOULD attempt to
solve both issues (A) and (B), if possible.
However, since some applications prioritize solving one issue
over the other, the solution MUST identify which issue (A or B) it
is attempting to solve.
The solution SHOULD provide a basis for evaluating how well
it solves the issue(s) it is targeting, if it is providing
an approximate solution.
</t>
</list>
</t>
</section>
<section title="Unknown Destination Unicast">
<t>
Unknown destination MAC unicast requires flooding, but its characteristics
are quite different from multicast/broadcast.
When the unicast MAC address is learned, the PE changes its forwarding
behavior from flooding over all PWs into sending over one PW.
Thereby it will require different technical studies
from multicast/broadcast,
which is out of scope of this document.
</t>
</section>
</section>
<section title="Multicast Packet Types">
<t>
Ethernet multicast is used for conveying Layer-3 multicast data.
When IP multicast is encapsulated by an Ethernet frame, the IP
multicast group address is mapped to the Ethernet destination MAC
address. In IPv4, the mapping uses the lower 23 bits of the (32bit)
IPv4 multicast address and places them as the lower 23 bits of a destination
MAC address with the fixed header of 01-00-5E in hex.
Since this mapping is ambiguous (i.e., there is a multiplicity of 1 Ethernet
address to 32 IPv4 addresses), MAC-based forwarding is not ideal for IP multicast
because some hosts might possibly receive packets they are not interested in, which
is inefficient in traffic delivery and has an impact on security.
On the other hand, if the solution tracks IP addresses rather than MAC addresses,
this concern can be prevented. The drawback of this approach is, however,
that the network administration becomes slightly more complicated.
</t>
<t>
Ethernet multicast is also used for Layer-2 control frames. For
example, BPDU (Bridge Protocol Data Unit) for IEEE 802.1D Spanning
Tree uses a multicast destination MAC address (01-80-C2-00-00-00).
Also some of IEEE 802.1ag <xref target="802.1ag"/> Connectivity Fault Management
(CFM) messages use a multicast destination MAC address dependent on
their message type and application. From the perspective of IP
multicast, however, it is necessary in VPLS to flood such control
frames to all participating CEs, without requiring any membership
controls.
</t>
<t>
As for a multicast VPLS solution, it can only use Ethernet-related
information, if you
stand by the strict application of the basic requirement:
"a L2VPN service SHOULD be
agnostic to customer's Layer 3 traffic <xref target="RFC4665"/>."
This means
no Layer-3 information should be checked for transport.
However, it is obvious
this is an impediment to solve Issue A.
</t>
<t>
Consequently, a multicast VPLS can be allowed to make
use of some Layer-3-related
supplementary information in order to improve transport efficiency.
In fact, today's LAN switch implementations often support such
approaches and snoop upper layer protocols and examine IP multicast
memberships (e.g., PIM snooping and
IGMP/MLD snooping <xref target="RFC4541"/>).
This will implicitly suggest
that VPLS may adopt similar techniques although this document does NOT
state Layer-3 snooping is mandatory.
If such an approach is taken, careful
consideration of Layer-3 state maintenance is necessary.
In addition, note that snooping approaches sometimes
have disadvantages in the system's
transparency; that is, one particular protocol's snooping solution
might hinder other (especially future) protocol's working (e.g.,
an IGMPv2-snooping switch vs. a new IGMPv3-snooping one).
Also, note that there are potential alternatives
to snooping:
<list style='hanging'>
<t hangText='-'>
Static configuration of multicast Ethernet addresses and ports/interfaces
</t>
<t hangText='-'>
Multicast control protocol based on Layer-2 technology
which signals mappings of multicast addresses to ports/interfaces,
such as GARP/GMRP<xref target="802.1D"/>, CGMP<xref target="CGMP"/> and
RGMP<xref target="RFC3488"/>.
</t>
</list>
</t>
<t>
On the basis described above, general requirements about
packet types are given as follows:
</t>
<t>
<list style='hanging'>
<t hangText='-'>
A solution SHOULD support a way to facilitate IP multicast forwarding
of the customers. It MAY observe Layer-3 information (i.e., multicast
routing protocols and state) to the degree necessary, but any information
irrelevant to multicast transport SHOULD NOT be consulted.
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='-'>
In a solution, Layer-2 control frames (e.g., BPDU, 802.1ag CFM)
SHOULD be flooded to all PE/CEs in a common VPLS instance. A
solution SHOULD NOT change or limit the flooding scope to remote
PE/CEs in terms of end-point reachability.
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='-'>
In a solution, Layer-2 frames that encapsulate Layer-3 multicast control
packets (e.g., PIM, IGMP(for IPv4), MLD(for IPv6)) MAY be flooded only to
relevant members, with the goal of limiting flooding scope.
However, Layer-2 frames that encapsulate other Layer-3 control packets
(e.g., OSPF, ISIS) SHOULD be flooded
to all PE/CEs in a VPLS instance.
</t>
</list>
</t>
</section>
<section title="MAC Learning Consideration">
<t>
In a common VPLS architecture, MAC learning is carried out by PEs based on
the incoming frame's source MAC address, independently of the destination MAC address
(i.e., regardless of whether it is unicast, multicast or broadcast).
This is the case with multicast VPLS solution's environment too.
In this document, the improvement of MAC learning scalability is beyond the scope. It will be covered in the future work.
</t>
</section>
</section>
<section title="Static Solutions">
<t>
A solution SHOULD allow static configuration
to account for various operator policies,
where the logical multicast topology does not
change dynamically
in conjunction with a customer's multicast routing.
</t>
</section>
<section title="Backward Compatibility">
<t>
A solution SHOULD be backward compatible with the existing VPLS
solution.
It SHOULD allow a case where a common VPLS instance is
composed of both PEs supporting the solution and PEs not supporting
it, and the multicast optimization (both forwarding and receiving) is achieved
between the compliant PEs.
</t>
<t>
Note again that the existing VPLS solutions already have a simple
flooding capability. Thus this backward compatibility
will give customers and SPs the improved efficiency of multicast forwarding
incrementally as the solution is deployed.
</t>
</section>
</section>
<section title="Customer Requirements">
<section title="CE-PE protocol">
<section title="Layer-2 Aspect">
<t>
A solution SHOULD allow transparent operation of
Ethernet control protocols employed by customers
(e.g. Spanning Tree Protocol
<xref target="802.1D"/>)
and their seamless operation with multicast data transport.
</t>
<t>
Solutions MAY examine Ethernet multicast control frames
for the purpose of efficient dynamic transport
(e.g. GARP/GMRP <xref target="802.1D"/>).
However, solutions MUST NOT assume all CEs are always running such
protocols (typically in the case where a CE is a router and is not aware
of Layer-2 details).
</t>
<t>
A whole Layer-2 multicast frame (whether for data or control) SHOULD
NOT be altered from a CE to CE(s)
EXCEPT for the VLAN Id field, ensuring that it is transparently transported.
If VLAN Ids are assigned by the SP,
they can be altered.
Note, however, when VLAN Ids are changed, Layer-2 protocols
may be broken in some cases, such as Multiple Spanning
Tree <xref target="802.1s"/>.
Also if the Layer-2 frame is encapsulating Layer-3 multicast
control packet (e.g., PIM/IGMP) and customers allow it to be regenerated at
PE (aka proxy: see section 5.1.2.), then
the MAC address for that frame MAY be altered to the minimum
necessary (e.g., use PE's own MAC address as a source).
</t>
<t>
</t>
</section>
<section title="Layer-3 Aspect">
<t>
Again, a solution MAY examine customer's Layer-3 multicast
protocol packets
for the purpose of efficient and dynamic transport.
If it does, supported protocols SHOULD include:
</t>
<t>
<list style='symbols'>
<t>
PIM-SM
<xref target="RFC4601"/>,
PIM-SSM
<xref target="RFC4607"/>,
bidirectional PIM
<xref target="RFC5015"/>
and PIM-DM
<xref target="RFC3973"/>
</t>
<t>
IGMP (v1<xref target="RFC1112"/>,
v2<xref target="RFC2236"/>
and v3<xref target="RFC3376"/>) (for IPv4 solutions)
</t>
<t>
Multicast Listener Discovery Protocol (MLD)
(v1<xref target="RFC2710"/> and
v2<xref target="RFC3810"/>) (for IPv6 solutions).
</t>
</list>
</t>
<t>
A solution MUST NOT require any special Layer-3 multicast protocol
packet processing by the end users. However, it MAY require some
configuration changes (e.g.,
turning explicit tracking on/off in PIM).
</t>
<t>
A whole Layer-3 multicast packet (whether for data or control), which is
encapsulated inside a Layer-2 frame, SHOULD NOT be altered from
a CE to CE(s), ensuring that it is transparently transported.
However, as for Layer-3 multicast control
(like PIM Join/Prune/Hello and IGMP Query/Report packet),
it MAY be altered to the minimum
necessary if such partial non-transparency is acceptable from
point of view of the multicast service.
Similarly, a PE MAY consume such Layer-3 multicast control packets
and regenerate an entirely new packet if partial non-transparency
is acceptable with legitimate reason for customers (aka proxy).
</t>
</section>
</section>
<section title="Multicast Domain">
<t>
As noted in Section 2.1., the term "multicast domain"
is used in a generic context for Layer-2 and Layer-3.
</t>
<t>
A solution SHOULD NOT alter customer multicast domains' boundaries.
It MUST ensure that
the provided Ethernet multicast domain always encompasses the
corresponding customer Layer-3 multicast domain.
</t>
<t>
A solution SHOULD optimize
those domains' coverage sizes, i.e., a solution SHOULD
ensure that unnecessary
traffic is not sent to CEs with no members.
Ideally, the provided
domain size will be close to that of the customer's Layer-3
multicast membership distribution;
however, it is OPTIONAL to
achieve such absolute optimality from the perspective of Layer-3.
</t>
<t>
If a customer uses VLANs and a VLAN Id as a service delimiter
(i.e., each VPLS instance is represented by a
unique customer VLAN tag carried by a frame through the UNI port),
a solution MUST support separate multicast domains per VLAN Id.
Note that if VLAN Id translation is provided (i.e.,
if a customer VLAN at one site is mapped into a different customer VLAN
at a different site),
multicast domains will be created per set of VLAN Ids which are
associated with translation.
</t>
<t>
If a customer uses VLANs but a VLAN Id is not a service delimiter (i.e.,
the VPN disregards customer VLAN Ids),
a solution MAY provide separate multicast domains
per VLAN Id. A SP is not required to
provide separate multicast domains
per VLAN IDs,
but it may be considered beneficial to do so.
</t>
<t>
A solution MAY build multicast domains based on
Ethernet MAC addresses. It MAY also build multicast domains
based on the IP addresses inside Ethernet frames.
That is, PEs in each VPLS instance might control
forwarding behavior and provide different multicast frame
reachability depending on each MAC/IP destination
address separately.
If IP multicast channels are fully
considered in a solution, the provided domain size will be closer
to actual channel reachability.
</t>
</section>
<section title="Quality of Service (QoS)">
<t>
Customers require that multicast quality of service MUST be at least on par with
what exists for unicast traffic.
Moreover, as multicast is often used to deliver high quality services such as
TV broadcast, delay/jitter/loss sensitive traffic MUST be supported
over multicast VPLS.
</t>
<t>
To accomplish this, the solution MAY have additional features to support
high QoS such as bandwidth reservation and flow admission control.
Also multicast VPLS deployment SHALL benefit from
IEEE 802.1p CoS techniques
<xref target="802.1D"/>
and
DiffServ
<xref target="RFC2475"/>
mechanisms.
</t>
<t>Moreover, multicast traffic SHOULD NOT affect the QoS that unicast
traffic receives and vice versa.
That is, separation of multicast and unicast
traffic in terms of QoS is necessary.
</t>
</section>
<section title="SLA Parameters Measurement ">
<t>
Since SLA parameters are part of the service sold to customers,
they simply want to verify their application performance
by measuring the parameters SP(s) provide.
</t>
<t>
Multicast specific characteristics that may be monitored are, for
instance, multicast statistics per stream (e.g. total/incoming/outgoing/dropped
traffic by period of time), one-way delay, jitter and
group join/leave delay (time to start receiving traffic from
a multicast group across the VPN since join/leave was issued).
An operator may also wish to compare the difference in one-way delay
for a solitary multicast group/stream from a single, source PE to multiple receiver PEs.
</t>
<t>
A solution SHOULD provide these parameters with Ethernet
multicast group level granularity. (For example, multicast MAC address
will be one of those entries for classifying flows with statistics,
delay and so on.) However, if a solution is aimed at IP multicast
transport efficiency, it MAY support IP multicast level
granularity. (For example, multicast IP address/channel will be
entries for latency time.)
</t>
<t>
In order to monitor them, standard interfaces for statistics gathering
SHOULD also be provided (e.g., standard SNMP MIB Modules).
</t>
</section>
<section title="Security">
<t>
A solution MUST provide customers with architectures that
give the same level of security both for unicast and
multicast.
</t>
<section title="Isolation from Unicast">
<t>
Solutions SHOULD NOT affect any forwarding information base, throughput or
resiliency etc. of unicast frames; that is, they SHOULD provide
isolation from unicast.
</t>
</section>
<section title="Access Control">
<t>
A solution MAY filter multicast traffic inside a VPLS, upon the
request of an individual customer, (for example, MAC/VLAN filtering,
IP multicast channel filtering, etc.).
</t>
</section>
<section title="Policing and Shaping on Multicast">
<t>
A solution SHOULD support policing and shaping multicast traffic
on a per customer basis and on a per AC (Attachment Circuit) basis.
This is intended to
prevent multicast traffic from exhausting resources for unicast
inside a common customer's VPN. This might also be beneficial for
QoS separation (see section 5.3).
</t>
</section>
</section>
<section title="Access Connectivity">
<t>
First and foremost various physical connectivity
types described in
<xref target="RFC4665"/>
MUST be supported.
</t>
</section>
<section title="Multi-Homing">
<t>
A multicast VPLS MUST allow a situation
in which a CE is dual-homed to two different SPs via diverse access networks --
one is supporting multicast VPLS but the other is not supporting
it, (because it is an existing VPLS or 802.1Q/QinQ network).
</t>
</section>
<section title="Protection and Restoration">
<t>
A multicast VPLS infrastructure SHOULD allow redundant paths
to assure high availability.
</t>
<t>
Multicast forwarding restoration time MUST NOT be greater than the
time it takes a customer's Layer-3 multicast protocols to detect a
failure in the VPLS infrastructure. For
example, if a customer uses PIM with default configuration, hello
hold timer is 105 seconds, and solutions are required to restore a
failure no later than this period. To achieve this, a solution
might need to support providing alternative multicast paths.
</t>
<t>
Moreover, if multicast forwarding was not successfully
restored (e.g., in case of no redundant paths),
a solution MAY raise alarms to provide outage notification to customers
before such a hold timer expires.
</t>
</section>
<section title="Minimum MTU">
<t>
Multicast applications are often sensitive to packet fragmentation
and reassembly, so the requirement to avoid fragmentation
might be stronger than the existing VPLS solution.
</t>
<t>
A solution SHOULD provide customers with enough committed minimum MTU
(i.e., service MTU) for multicast Ethernet frames to ensure that
IP fragmentation between
customer sites never occurs. It MAY give different MTU sizes to
multicast and unicast.
</t>
</section>
<section title="Frame Reordering Prevention">
<t>
A solution SHOULD attempt to prevent frame reordering when delivering customer
multicast traffic. Likewise, for unicast and unknown unicast
traffic, it SHOULD attempt not to increase the likelihood of reordering compared
with existing VPLS solutions.
</t>
<t>
It is to be noted that delivery of out-of-order frames is not
avoidable in certain cases. Specifically if
a solution adopts some MDTunnels (see section 6.2.1)
and dynamically selects them for optimized delivery
(e.g., switching from one aggregate tree to another),
end-to-end data delivery is prone to be out-of-order.
This fact can be considered a trade-off between
bandwidth optimization and network stability. Therefore,
such a solution is expected to promote awareness about
this kind of drawback.
</t>
</section>
<section title="Fate-Sharing between Unicast and Multicast">
<t>
In native Ethernet, multicast and unicast connectivity are often
managed together. For instance, 802.1ag CFM Continuity Check
message is forwarded by multicast as a periodic
heartbeat, but it is supposed to check the "whole" traffic continuity
regardless of unicast or multicast, at the same time. Hence, the
aliveness of unicast and multicast is naturally coupled (i.e., fate-shared)
in this customer's environment.
</t>
<t>
A multicast VPLS solution may decouple the path that a customer's
unicast and multicast traffic follow through a SP's backbone, in
order to provide the most optimal path for multicast data traffic.
This may cause concern among some multicast VPLS customers who desire
that, during a failure in the SP's network, both unicast and
multicast traffic fail concurrently.
</t>
<t>
Therefore, there will be an additional requirement that makes both
unicast and multicast connectivity coupled. This means that if either one of them have a
failure, the other is also disabled. If one of the services (either unicast or multicast)
becomes operational, the other is also activated simultaneously.
</t>
<t>
<list style='hanging'>
<t hangText='-'>
It SHOULD be identified if the solution can provide customers with
fate-sharing between unicast and multicast connectivity for their
LAN switching application. It MAY have a configurable mechanism
for SPs to provide that on behalf of customers, e.g., aliveness
synchronization, but its use is OPTIONAL.
</t>
</list>
</t>
<t>
This policy will benefit customers.
Some customers would like to detect failure soon at CE side and restore full
connectivity by switching over to their backup line,
rather than to keep poor half connectivity (i.e., either unicast or multicast being in fail).
Even if either unicast or multicast is kept alive, it is just disadvantageous
to the customer's application protocols which need both traffic.
Fate-sharing policy contributes to preventing such a complicated situation.
</t>
<t>
Note that how serious this issue is depends on each customer's stance
in Ethernet operation. If all CEs are IP routers i.e.,
if VPLS is provided for LAN routing application, the customer
might not care about it because both unicast and multicast connectivity
is assured
in IP layer. If the CE routers are running an IGP (e.g., OSPF/IS-IS)
and a multicast routing protocol (e.g., PIM), then aliveness of both the unicast
and multicast paths will be detected by the CEs. This does not guarantee
that unicast and multicast traffic are to follow the same path in the
SP's backbone network, but does mitigate this issue to some degree.
</t>
</section>
</section>
<section title="Service Provider Network Requirements">
<section title="Scalability">
<t>
The existing VPLS architecture has major
advantages in scalability. For example,
P-routers are free from maintaining customers' information
because customer traffic is encapsulated in PSN tunnels.
Also a PW's split-horizon technique can prevent
loops, making PE routers free from maintaining complicated
spanning trees.
</t>
<t>
However, a multicast VPLS needs additional scalability considerations
related to its expected enhanced mechanisms.
<xref target="RFC3809"/>
lists common L2VPN sizing and scalability requirements and
metrics, which are applicable in multicast VPLS too. Accordingly,
this section deals with specific requirements related to scalability.
</t>
<section title="Trade-off of Optimality and State Resource">
<t>
A solution needs to improve the scalability
of multicast as is shown in section 3:
</t>
<t>
<list style='empty'>
<t>Issue A: Replication to non-member site.</t>
<t>Issue B: Replication of PWs on shared physical path.</t>
</list>
</t>
<t>
For both issues, the optimization of physical resources
(i.e. link bandwidth usage and router duplication
performance) will
become a major goal. However, there is a trade-off between
optimality and state resource consumption.
</t>
<t>
In order to solve Issue A, a PE might have to
maintain multicast group information for CEs which was not
kept in the existing VPLS solutions. This will
present scalability concerns about
state resources (memory, CPU, etc.) and their maintenance complexity.
</t>
<t>
In order to solve Issue B, PE and P routers might have to
have knowledge of additional membership information for remote PEs,
and possibly additional tree topology information,
when they are using point-to-multipoint techniques
(PIM tree, P2MP-LSP, etc.).
</t>
<t>
Consequently, the scalability evaluation of multicast VPLS solutions
needs a careful trade-off analysis between bandwidth optimality
and state resource consumption.
</t>
</section>
<section title="Key Metrics for Scalability">
<t>
<list style='empty'>
<t>
(Note: This part has a number of similar characteristics to
requirements for Layer 3 Multicast VPN
<xref target="RFC4834"/>.)
</t>
</list>
</t>
<t>
A multicast VPLS solution MUST be designed to scale well
with an increase in the number of any of the following metrics:
</t>
<t>
<list style='hanging'>
<t hangText='-'>the number of PEs</t>
<t hangText='-'>the number of VPLS instances (total and per PE)</t>
<t hangText='-'>the number of PEs and sites in any VPLS instance</t>
<t hangText='-'>the number of client VLAN Ids</t>
<t hangText='-'>the number of client Layer-2 MAC multicast groups</t>
<t hangText='-'>
the number of client Layer-3 multicast channels
(groups or source-groups)
</t>
<t hangText='-'>the number of PWs and PSN Tunnels (MDTunnels) (total and per PE)</t>
</list>
</t>
<t>
Each multicast VPLS solution SHALL document its scalability
characteristics in quantitative terms.
A solution SHOULD quantify the amount of
state that a PE and a P device has to support.
</t>
<t>The scalability characteristics SHOULD include:</t>
<t>
<list style='hanging'>
<t hangText='-'>
the processing resources required by
the control plane in managing PWs
(neighborhood or session maintenance messages,
keepalives, timers, etc.)
</t>
<t hangText='-'>
the processing resources required by
the control plane in managing PSN tunnels
</t>
<t hangText='-'>the memory resources needed for the control plane</t>
<t hangText='-'>
the amount of protocol information transmitted to manage
a multicast VPLS (e.g. signaling throughput)
</t>
<t hangText='-'>
the amount of Layer-2/Layer-3 multicast information
a P/PE router consumes (e.g. traffic rate of join/leave, keepalives etc.)
</t>
<t hangText='-'>
the number of multicast IP addresses used (if IP multicast
in ASM mode is proposed as a multicast distribution tunnel)
</t>
<t hangText='-'>
other particular elements inherent to each solution that
impact scalability
</t>
</list>
</t>
<t>
Another metric for scalability is operational complexity.
Operations will naturally become more complicated if the number of managed
objects (e.g., multicast groups) increases, or the topology changes occur more frequently.
A solution SHOULD note the factors which lead to additional operational complexity.
</t>
</section>
</section>
<section title="Tunneling Requirements">
<section title="Tunneling Technologies">
<t>
A MDTunnel denotes a multicast distribution tunnel. This is
a generic term for tunneling where
customer multicast traffic is carried over a provider's network.
In the L2VPN service context, it will correspond to a PSN
tunnel.
</t>
<t>
A solution SHOULD be able to use a range of tunneling technologies,
including point-to-point (unicast oriented) and
point-to-multipoint/multipoint-to-multipoint (multicast oriented).
For example, today there are many kinds of
protocols for tunneling such as L2TP, IP,
(including multicast IP trees), MPLS (including P2MP-LSP
<xref target="RFC4875"/> and P2MP/MP2MP-LSP
<xref target="I-D.ietf-mpls-ldp-p2mp"/>
), etc.
</t>
<t>
Note that which variant, point-to-point, point-to-multipoint
or multipoint-to-multipoint, is used
depends largely on
the trade-offs mentioned above and the targeted network
and applications.
Therefore, this document does not mandate
any specific protocols. A solution, however, SHOULD state reasonable
criteria if it adopts a specific kind of tunneling protocol.
</t>
</section>
<section title="MTU of MDTunnel">
<t>
From the view of a SP, it is not acceptable to have fragmentation/reassembly
so often while packets are traversing a MDTunnel. Therefore, a solution
SHOULD support a method that provides the minimum path MTU of the
MDTunnel in order to accommodate the service MTU.
</t>
</section>
</section>
<section title="Robustness">
<t>
Multicast VPLS solutions SHOULD avoid single points of failures
or propose technical solutions that make it possible to implement a
failover mechanism.
</t>
</section>
<section title="Discovering Related Information">
<t>
The operation of a multicast VPLS solution SHALL be as light as
possible and providing automatic configuration and discovery SHOULD
be considered a high priority.
</t>
<t>
Therefore, in addition to the L2VPN discovery requirements in
<xref target="RFC4665"/>,
a multicast VPLS solution SHOULD provide a method that
dynamically allows multicast membership information to be discovered
by PEs if the solution supports (A), as defined in section 3.2.
This means, a PE needs to discover multicast membership
(e.g., join group addresses) that is controlled
dynamically from the sites connected to that PE.
In addition, a PE needs to discover such information automatically
from other remote PEs as well in order to limit flooding scope
across the backbone.
</t>
</section>
<section title="Operation, Administration and Maintenance">
<section title="Activation">
<t>
The activation of multicast enhancement in a solution MUST be possible:
</t>
<t>
<list style='symbols'>
<t>with a VPLS instance granularity</t>
<t>
with an Attachment Circuit granularity (i.e.,
with a PE-CE Ethernet port granularity, or with a VLAN Id granularity
when it is a service delimiter)
</t>
</list>
</t>
<t>
Also it SHOULD be possible:
</t>
<t>
<list style='symbols'>
<t>with a CE granularity
(when multiple CEs of a same VPN are associated with
a common VPLS instance)
</t>
<t>with a distinction between multicast reception and emission</t>
<t>with a multicast MAC address granularity</t>
<t>with a customer IP multicast group and/or channel granularity (when
Layer-3 information is consulted)</t>
</list>
</t>
<t>
Also it MAY be possible:
</t>
<t>
<list style='symbols'>
<t>with a VLAN Id granularity when it is not a service delimiter</t>
</list>
</t>
</section>
<section title="Testing">
<t>
A solution MUST provide a mechanism for testing multicast data
connectivity and verifying the associated information. Examples that
SHOULD be supported which are specific to multicast are:
</t>
<t>
<list style='hanging'>
<t hangText='-'>Testing connectivity per multicast MAC address</t>
<t hangText='-'>Testing connectivity per multicast Layer-3 group/channel</t>
<t hangText='-'>Verifying data plane and control plane integrity (e.g. PW, MDTunnel)</t>
<t hangText='-'>Verifying multicast membership-relevant
information (e.g. multicast MAC-addresses/PW-ports associations,
Layer-3 group associations)
</t>
</list>
</t>
<t>
Operators usually want to test if an end-to-end multicast
user's connectivity is OK before and after activation.
Such end-to-end multicast connectivity checking
SHOULD enable the end-to-end testing of the data path
used by that customer's multicast data packets.
Specifically, end-to-end checking will have CE-to-CE path test
and PE-to-PE path test. A solution MUST support PE-to-PE path test and MAY
support CE-to-CE path test.
</t>
<t>
Also operators will want to make use of a testing mechanism
for diagnosis and troubleshooting.
In particular, a solution SHOULD be able to monitor information
describing how client multicast traffic is carried over the SP
network. Note that if a solution supports frequent dynamic membership
changes with optimized transport, troubleshooting within the SP's network will
tend to be difficult.
</t>
</section>
<section title="Performance Management">
<t>
Mechanisms to monitor multicast specific parameters and statistics
MUST be offered to the SP.
</t>
<t>
<list style='empty'>
<t>
(Note: This part has a number of similar characteristics to
requirements for Layer 3 Multicast VPN
<xref target="RFC4834"/>.)
</t>
</list>
</t>
<t>A solution MUST provide SPs with access to:</t>
<t>
<list style='hanging'>
<t hangText='-'>
Multicast traffic statistics (total traffic forwarded, incoming,
outgoing, dropped, etc., by period of time)
</t>
</list>
</t>
<t>A solution SHOULD provide access to:</t>
<t>
<list style='hanging'>
<t hangText='-'>
Information about a customer's multicast resource usage (the amount
of multicast state and throughput)
</t>
<t hangText='-'>
Performance information related to multicast traffic usage, e.g.,
one-way delay, jitter, loss,
delay variations (the difference in one-way delay for a solitary multicast
group/stream from a single, source PE to multiple receiver PEs) etc.
</t>
<t hangText='-'>Alarms when limits are reached on such resources</t>
<t hangText='-'>
Statistics on decisions related to how client traffic is carried
on MDTunnels (e.g. "How much traffic was switched onto a multicast tree
dedicated to such groups or channels")
</t>
<t hangText='-'>
Statistics on parameters that could help the provider to
evaluate its optimality/state trade-off
</t>
</list>
</t>
<t>
All or part of this information SHOULD be made available through
standardized SNMP MIB Modules (Management Information Base).
</t>
</section>
<section title="Fault Management">
<t>
A multicast VPLS solution needs to
consider those management steps taken by SPs below:
</t>
<t>
<list style='symbols'>
<t>
Fault detection
<list style='empty'>
<t>
A solution MUST provide tools that detect
group membership/reachability failure and
traffic looping for multicast transport.
It is anticipated that such tools are
coordinated with the testing mechanisms mentioned in 6.5.2.
<vspace blankLines="1" />
In particular, such mechanisms SHOULD be able to detect a
multicast failure quickly, (on par with unicast cases). It
SHOULD also avoid situations where multicast
traffic has been
in a failure state for a relatively long time while unicast
traffic remains operational. If such a situation were to
occur, it would end up causing problems with customer
applications that depend on a combination of unicast and
multicast forwarding.
<vspace blankLines="1" />
With multicast, there may be many receivers associated with a
particular mulitcast stream/group. As the number of receivers
increases, the number of places (typically nearest the
receivers) required to detect a fault will increase
proportionately. This raises concerns over the scalability of
fault detection in large multicast deployments. Consequently, a
fault detection solution SHOULD scale well; in particular, a
solution should consider key metrics for scalability as
described in section 6.1.2.
</t>
</list>
</t>
</list>
</t>
<t>
<list style='symbols'>
<t>
Fault notification
<list style='empty'>
<t>
A solution MUST also provide fault notification and trouble
tracking mechanisms. (e.g. SNMP-trap and syslog.)
<vspace blankLines="1" />
In case of multicast, one point of failure often affects a
number of downstream routers/receivers that might
be able to raise a notification.
Hence notification messages MAY be summarized or
compressed for operators' ease of management.
</t>
</list>
</t>
</list>
</t>
<t>
<list style='symbols'>
<t>
Fault isolation
<list style='empty'>
<t>
A solution MUST provide
diagnostic/troubleshooting tools for multicast as well.
Also it is anticipated that such tools are
coordinated with the testing mechanisms mentioned in 6.5.2.
<vspace blankLines="1" />
In particular, a solution needs to correctly identify the
area inside a multicast group impacted by the failure.
A solution SHOULD be able to diagnose if an entire multicast
group is faulty or if some specific destinations are still alive.
</t>
</list>
</t>
</list>
</t>
</section>
</section>
<section title="Security">
<section title="Security Threat Analysis">
<t>
In multicast VPLS, there is a concern that one or more customer nodes
(presumably untrusted) might cause multicast-related attacks to the
SP network. There is a danger that it might compromise some components which belong to
the whole system.
</t>
<t>
This subsection states possible security threats relevant to the system
and which are protected against and which are not.
</t>
<t>
General security consideration about a base VPLS (as part of L2VPNs)
is referred to <xref target="RFC4665"/>. Following is the
threat analysis list which is inherent to multicast VPLS.
</t>
<t>
<list style='hanging'>
<t hangText="(a)">
Attack by huge amount of multicast control packets.
<vspace blankLines="0" />
There is a threat that a CE joins too many multicast groups
and causes Denial of Service (DoS).
This is caused by sending a large number of packets join/prune messages in short time
and/or putting a large variety of group addresses in join/prune messages.
This attack will waste PE's control resources (e.g., CPU, memory) which examine
customer control messages (for solving issue A in section 3.2.) and
it will not continue expected services for other trusted customers.
<vspace blankLines="1" />
</t>
<t hangText="(b)">
Attack by invalid/malformed multicast control packets.
<vspace blankLines="0" />
There is a threat that a CE sends invalid or malformed control packets
that might corrupt PE, which will cause DoS attack.
In particular, a CE might be spoofing legitimate
source/group IP multicast addresses in such control packets (in PIM, IGMP etc.)
and source/destination MAC addresses as Layer-2 frame.
<vspace blankLines="1" />
</t>
<t hangText="(c)">
Attack by rapid state change of multicast.
<vspace blankLines="0" />
If a malicious CE changes multicast state by sending control packets in an extremely
short period, this might affect PE's control resources (e.g., CPU, memory) to follow
such state changes. Besides, it might also affect PE/P's control resources if MDTunnel
inside the core is dynamically created in conjunction with customer's multicast group.
<vspace blankLines="1" />
</t>
<t hangText="(d)">
Attack by high volume of multicast/broadcast data traffic.
<vspace blankLines="0" />
A malicious CE might send very high volume of multicast and/or broadcast data to a PE.
If that PE does not provide any safeguards, it will cause excessive replication
in SP network
and the bandwidth resources for other trusted customers might be exhausted.
<vspace blankLines="1" />
</t>
<t hangText="(e)">
Attack by high volume of unknown destination unicast data traffic.
<vspace blankLines="0" />
A malicious CE can send a high volume of unknown unicast to a PE.
Generally according to VPLS architecture, that PE must flood such unknown traffic to
all correspond PEs in the same VPN. A variety of unknown destinations
and huge amount of
such frames might cause excess traffic in SP network unless there is an appropriate
safeguard provided.
</t>
</list>
</t>
</section>
<section title="Security Requirements">
<t>
Based on the analysis in the previous subsection, the security requirements
from the SP's perspective are shown as follows.
</t>
<t>
A SP network MUST
be invulnerable to malformed or maliciously constructed customer traffic.
This applies to both multicast data packets and multicast control packets.
</t>
<t>
Moreover, because multicast, broadcast, and unknown-unicast need more
resources than unicast, a SP network MUST have safeguards against
unwanted or malicious multicast traffic. This applies to both multicast
data packets and multicast control packets.
</t>
<t>
Specifically, a multicast VPLS solution SHOULD have
mechanisms to protect a SP network from:
</t>
<t>
<list style='hanging'>
<t hangText='(1)'>invalid multicast MAC addresses</t>
<t hangText='(2)'>invalid multicast IP addresses</t>
<t hangText='(3)'>malformed Ethernet multicast control protocol frames</t>
<t hangText='(4)'>malformed IP multicast control protocol packets</t>
<t hangText='(5)'>
high volumes of
<list style='symbols'>
<t>valid/invalid customer control packets</t>
<t>valid/invalid customer data packets (broadcast/multicast/unknown-unicast)</t>
</list>
</t>
</list>
</t>
<t>Depending each solution's actual approach to tackle with issue A and B or both (see section 3.2.),
there are relationships to be highlighted about each item's importance listed above.
First off, protection against (3) and (4) becomes significantly important if
a solution supports solving issue A, and PEs are processing customer's Ethernet/IP multicast control
messages from CE. Moreover protection against (2) should also be much focused because PIM/IGMP snooping
will usually require that PE's data forwarding be based on IP addresses.
By contrast, however, if a solution is
solving only issue B, not A, then PEs might never process customer's multicast control messages at all,
and they do not perform IP address-based forwarding, but does native Ethernet forwarding. If so,
there is relatively less danger about (2)(3)(4) compared to the first case.
</t>
<t>The following are a few additional guidelines in detail.</t>
<t>
<list style='empty'>
<t>
For protecting against threat (a),
a solution SHOULD support to impose some bounds on the quantity of state used by
a VPN to be imposed in order to prevent state resource exhaustion
(i.e., lack of memory, CPU etc.).
In this case, the bounds MUST
be configurable per VPN basis, not total of various VPNs so that
SP can isolate the resorce waste that is caused by any malicious customer.
</t>
</list>
</t>
<t>
<list style='empty'>
<t>
For protecting against threat (d) and (e),
a solution SHOULD support to perform traffic policing to limit the
unwanted data traffic shown above. In this case, while policing
MAY be configurable to the sum of unicast, multicast, broadcast
and unknown unicast traffic, it SHOULD also be configurable to each
such type of traffic individually in
order to prevent physical resource exhaustion (i.e., lack of
bandwidth and degradation of throughput). If the policing limit is configured
on total traffic only, there will be a concern that
one customer's huge multicast might close other irrelevant unicast traffic.
If it can be configured individually, this concern will be avoided.
Moreover, such a policing mechanism MUST
be configurable per VPN basis, not total of various VPNs to isolate
malicious customer's traffic from others.
</t>
</list>
</t>
<t>
<list style='empty'>
<t>
For protecting against threat (c),
a solution SHOULD be able to limit frequent changes of group membership by customers.
For example, PEs might support a
dampening mechanism that throttles their multicast state changes
if the customers are changing too excessively. Also
if MDTunnel is provided being tightly coupled to dynamic changes of
customer's multicast domain, it is also effective to delay
building the tunnel when customer's state is changed frequently.
</t>
</list>
</t>
<t>
<list style='empty'>
<t>
Protecting against threat (b) might not be an easy task.
Generally, checking the legitimacy of customer's IP multicast control packets
will eventually require the authentication between PE and CE in Layer-3;
however, L2VPN (including VPLS) by its nature does not usually assume
Layer-3-based security mechanism supported at PE-CE level.
</t>
<t>
The ramification of this fact is that there remains possibility
that a PE's control plain might be badly affected
by corrupted multicast control packets that the PE is examining.
Hence each PE implementation
will need to make an effort to minimize this impact from malicious customers
and isolate it from other trusted customers as much as possible.
</t>
<t>
Nevertheless, it is possible to mitigate this threat to some degree.
For example,
a PE MAY support a filter mechanism about MAC and IP addresses in
Layer-2/Layer-3 header and a filter mechanism about source/group addresses
in the multicast join/prune
messages. This will help a PE to validate customers' control messages,
to a certain extent.
</t>
</list>
</t>
</section>
</section>
<section title="Hierarchical VPLS support">
<t>
A VPLS multicast solution SHOULD allow a
hierarchical VPLS (H-VPLS)
<xref target="RFC4762"/> service model.
In other words, a solution is
expected to operate seamlessly with
existing hub and spoke PW connectivity.
</t>
<t>
Note that it is also important
to take into account the case of redundant spoke
connections between U-PEs and N-PEs.
</t>
</section>
<section title="L2VPN Wholesale">
<t>
A solution MUST allow a situation where
one SP is offering L2VPN services to another SP.
One example here is a wholesale model where one VPLS interconnects
other SPs' VPLS or 802.1D network islands.
For customer SP, their multicast forwarding can be optimized by
making use of multicast VPLS in the wholesaler SP.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
Security concerns and requirements for a base VPLS solution
are described in
<xref target="RFC4665"/>.
</t>
<t>
In addition, there are security considerations specific to multicast VPLS.
Thus a set of security issues have been identified that MUST be addressed
when considering the design and deployment of multicast VPLS.
Such issues have been described in Section 5.5 and 6.6.
</t>
<t>
In particular, security requirements from the view of customers are shown in Section 5.5.
Security requirements from the view of providers are shown in Section 6.6.
Section 6.6.1 conducts security threat analysis about the provider's whole system.
Section 6.6.2 explains how each threat can be addressed or mitigated.
</t>
</section>
<section title="IANA Considerations">
<t>
This document has no actions for IANA.
</t>
</section>
<section title="Acknowledgments">
<t>
The authors thank the contributors of
<xref target="RFC4834"/>
since the structure and content of this document were,
for some sections, largely inspired by <xref target="RFC4834"/>.
</t>
<t>
The authors also thank Yuichi Ikejiri,
Jerry Ash, Bill Fenner, Vach Kompella, Shane Amante, Ben Niven-Jenkins and Venu Hemige
for their valuable reviews and feedbacks.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc4665;
</references>
<references title="Informative References">
&rfc2475;
&rfc3809;
&rfc4601;
&rfc1112;
&rfc2236;
&rfc3488;
&rfc3376;
&rfc3973;
&rfc2710;
&rfc3810;
&rfc4541;
&rfc4607;
&rfc4664;
&rfc4761;
&rfc4762;
&rfc4834;
&rfc5015;
&rfc4875;
&I-D.ietf-mpls-ldp-p2mp;
<reference anchor="802.1D">
<front>
<title>
Part 3: Media Access Control (MAC) Bridges
</title>
<author>
<organization abbrev='IEEE Std 802.1D-1998'>
ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998
Edition (Revision and redesignation of ISO/IEC
10038:98)
</organization>
</author>
<date year="1998" />
</front>
<seriesInfo name='ISO/IEC' value='15802-3:' />
</reference>
<reference anchor="802.1ag">
<front>
<title>
Virtual Bridge Local Area Networks: Connectivity
Fault Management (Work in Progress)
</title>
<author>
<organization abbrev='IEEE'>
IEEE
</organization>
</author>
<date year="2007" />
</front>
</reference>
<reference anchor="802.1s">
<front>
<title>
Virtual Bridged Local Area Networks- Amendment 3: Multiple Spanning Trees
</title>
<author>
<organization abbrev='IEEE Std 802.1s-2002'>
IEEE Std 802.1s-2002
</organization>
</author>
<date year="2002" />
</front>
</reference>
<reference anchor="CGMP">
<front>
<title>
Cisco Group Management Protocol (CGMP)
</title>
<author initials="D." surname="Farinacci" fullname="Dino Farinacci">
<organization />
</author>
<author initials="A." surname="Tweedly" fullname="Alex Tweedly">
<organization />
</author>
<author initials="T." surname="Speakman" fullname="Tony Speakman">
<organization />
</author>
<date year="1996/1997"/>
</front>
<seriesInfo name="ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt" value=""/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 20:32:33 |