One document matched: draft-kamite-l2vpn-vpms-frmwk-requirements-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc4665 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4665.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4664 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4664.xml'>
<!ENTITY rfc4026 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4026.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 I-D.jounay-pwe3-p2mp-pw-requirements PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-jounay-pwe3-p2mp-pw-requirements-01.xml'>
<!ENTITY I-D.ietf-l2vpn-vpls-mcast PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-l2vpn-vpls-mcast-04.xml'>
]>
<rfc category="info" ipr="full3978" docName="draft-kamite-l2vpn-vpms-frmwk-requirements-01.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="VPMS Framework and Requirements">
Framework and Requirements for Virtual Private Multicast Service (VPMS)
</title>
<author initials='Y.' surname="Kamite" fullname='Yuji Kamite'>
<organization abbrev="NTT Communications">
NTT Communications Corporation
</organization>
<address>
<postal>
<street>Tokyo Opera City Tower</street>
<street>3-20-2 Nishi Shinjuku, Shinjuku-ku</street>
<region>Tokyo</region>
<code>163-1421</code>
<country>Japan</country>
</postal>
<email>y.kamite@ntt.com</email>
</address>
</author>
<author initials='F.' surname="Jounay" fullname='Frederic Jounay'>
<organization abbrev="France Telecom">
France Telecom
</organization>
<address>
<postal>
<street>2, avenue Pierre-Marzin</street>
<street>22307 Lannion Cedex</street>
<country>France</country>
</postal>
<email>frederic.jounay@orange-ftgroup.com</email>
</address>
</author>
<author initials='B.' surname="Niven-Jenkins" fullname='Ben Niven-Jenkins'>
<organization abbrev="BT">
BT
</organization>
<address>
<postal>
<street>208 Callisto House, Adastral Park</street>
<street>Ipswich, IP5 3RE</street>
<country>UK</country>
</postal>
<email>benjamin.niven-jenkins@bt.com</email>
</address>
</author>
<date day="14" month="July" year="2008"/>
<abstract>
<t>
This document provides a framework and service level requirements for
Virtual Private Multicast Service (VPMS).
VPMS is defined as a Layer 2 VPN service that provides
point-to-multipoint
connectivity for a variety of Layer 2 link layers across an IP or
MPLS-enabled PSN.
This document outlines architectural service models of VPMS
and states generic and high level requirements.
This is intended to aid in developing protocols and
mechanisms to support VPMS.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Problem Statement">
<t>
<xref target="RFC4664"/> describes different types of
Provider Provisioned Layer 2 VPNs (L2 PPVPNs, or L2VPNs);
Some of them are widely deployed today, such as
Virtual Private Wire Service (VPWS) and
Virtual Private LAN Service (VPLS).
A VPWS is a VPN service that supplies a
Layer 2 (L2) point-to-point service.
A VPLS is an L2 service that emulates Ethernet LAN service across
a Wide Area Network (WAN).
</t>
<t>
For some use cases described hereafter, there are
P2MP (point-to-multipoint) type services for Layer 2
traffic. However, there is no straightforward way to realize them
based on the existing L2VPN specifications.
</t>
<t>
In a VPWS, a SP can set up point-to-point connectivity
per a pair of CEs but it is impossible to
replicate traffic for point-to-multipoint services
in the SP's network side.
Even though a SP can build multiple PWs independently
and make the CEs to replicate traffic
over them, it is considered an inconvenient way for the customer
and a waste of bandwidth resources.
</t>
<t>
In a VPLS, SPs can naturally offer multipoint connectivity across
their backbone. Although it is seemingly applicable
for point-to-multipoint service as well, there remains
extra work for SPs to filter unnecessary traffic between
irrelevant sites (i.e., from a receiver PE to another receiver PE)
because VPLS provides full-mesh multipoint-to-multipoint
connectivity between CEs. Moreover, VPLS's MAC-based
learning/forwarding operation is considered
unnecessary for some scenarios particularly if customers
just want to have simple unidirectional point-to-multipoint service,
or if they require non-Ethernet Layer 2 connectivity.
</t>
<t>
Consequently, There is a real need for a solution
that natively provides point-to-multipoint service in L2VPN.
</t>
</section>
<section title="Scope of This Document">
<t>
VPMS is defined as a Layer 2 service that provides point-to-multipoint
connectivity for a variety of Layer2 link layers across an IP or
MPLS-enabled PSN. VPMS is categorized as a form of
provider-provisioned Layer 2 Virtual Private Networks (L2VPN).
</t>
<t>
This document introduces a new service framework, reference
model and functional requirements for
VPMS within the context of L2VPN, on top of the existing
framework <xref target="RFC4664"/> and requirements
<xref target="RFC4665"/>.
It is intended to show a proper reference to introduce VPMS and
a checklist of requirements
that will provide a consistent way to evaluate how well each
solution satisfies the requirements.
</t>
<t>
The technical specifications are outside the scope of this
document. There is no intent to specify
solution-specific details.
</t>
<t>
This document provides requirements from both the Service Provider's
and the Customer's point of view.
</t>
</section>
</section>
<section title="Conventions used in this document">
<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 title="Terminology">
<t>
The content of this document makes use of the terminology defined in
<xref target="RFC4026"/>.
For readability purposes, we list some of the terms here
in addition to some specific terms used in this document.
</t>
<section title="Acronyms">
<t>
<list style='hanging'>
<t hangText='P2P:'>
Point-to-Point
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='P2MP:'>
Point-to-Multipoint
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='PW:'>
Pseudowire
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='VPMS:'>
Virtual Private Multicast Service
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='PE/CE:'>
Provider/Customer Edge
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='P:'>
Provider Router
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='AC:'>
Attachment Circuit
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='PSN:'>
Packet Switched Network
</t>
</list>
</t>
<t>
<list style='hanging'>
<t hangText='SP:'>
Service Provider
</t>
</list>
</t>
</section>
</section>
<section title="Use Cases">
<section title="Ethernet Use Case">
<t>
For multicast traffic delivery, there is a requirement to deliver a
unidirectional P2MP service in addition to the existing P2P service.
The demand is growing to provide private services which support
Ethernet traffic duplication, for various applications such as
IP-based delivery of TV
broadcasting, content delivery networks, etc. Moreover, many digital
audio/video devices (e.g., MPEG-TS, HD-SDI) that supports Ethernet
interfaces are becoming available, which will make Ethernet
P2MP service more common. Also there are some applications that
naturally suited to static transport of VPMS. For example, MPEG-TS/IP/
Ethernet in DVB-H is typically static broadcast without any signaling
in the upstream direction. VPMS could be a possible solution to
provide these kinds of networking connectivity over PSNs.
</t>
<t>
Currently VPLS [RFC4761][RFC4762] is able to give P2MP-type
replication for Ethernet traffic. Native VPLS already supports this
capability via a full mesh of PWs, and an extension to optimize
replication is also proposed [I-D.ietf-l2vpn-vpls-mcast] as an
additional feature. However, VPLS by nature requires MAC-based
learning and forwarding, which might not be needed in some cases by
particular users. Generally, video distribution applications use unidirectional P2MP traffic, but may not always require any added
expense of MAC address management. In addition, VPLS is a service
that essentially provides any-to-any connectivity between all CEs in
a L2VPN as it emulates a LAN service. However, if only P2MP
connectivity is required, the traffic between different receivers is not always
needed, and traffic from receiver to sender is not always needed,
either. In these cases, VPMS is a service that provides much simpler
operation.
</t>
<t>
Note that VPMS provides single coverage of receiver membership; that
is, there is no distinct differentiation about multiple multicast
groups. All traffic from a particular Attachment Circuit (AC) will
flow toward the same remote receivers, even if the destination MAC
address is changed. Basically in VPMS, destination MAC addresses are
not used for forwarding, which is significantly different from VPLS.
If MAC-based forwarding is preferred (i.e., multicast/unicast
differentiation of MAC address), VPLS should be chosen rather than
VPMS.
</t>
</section>
<section title="ATM-based Use Case">
<t>
A use case of ATM-based service in VPMS could be to offer the
capability for
service providers to support IP multicast wholesale services over
ATM
in case the wholesale customer relies on ATM infrastructure. The
P2MP support alleviates the constraint in terms of replication for ATM to
support IP multicast services.
</t>
<t>
Another use case of VPMS for ATM is for audio/video stream
applications. Today many digital TV broadcasting networks adopt ATM-
based distribution systems with point-to-multipoint PVPs/PVCs. The
transport network supports replicating ATM cells in transit nodes to
efficiently deliver programs to multiple terminals. For migrating
such ATM-based networks onto IP/MPLS-based networks, VPMS is considered to be
a candidate solution.
</t>
</section>
<section title="TDM-based Use Case">
<t>
Today the existing VPWS already supports TDM emulation services
(SAToP, CESoPSN or TDMoIP). It is a Layer 1 service, not Layer 2
service; however, a common architecture is being used since they are
all packet-based emulations over a SP's network. VPMS is also considered to be a solution for such TDM applications that require
point-to-multipoint topology.
</t>
<t>
In a PSN environment, the existing VPWS allows support for 2G/3G
mobile backhauling (e.g. TDM traffic for GSM's Abis interface, ATM
traffic for Release 99 UMTS's Iub interface). Currently, the
Mobile backhauling architecture is always built as a star topology
between the 2G/3G controller (e.g. BSC or RNC) and the 2G/3G Base
Stations (BTS or NodeB). Therefore VPWSes (P2P services) are used
between each Base Station and their corresponding controller and
nothing more is required.
</t>
<t>
As far as synchronization in a PSN environment is concerned,
different mechanisms can be considered to provide frequency and phase
clock required in the 2G/3G Mobile environment to guarantee mobile
handover and strict QoS. One of them consists of using Adaptive
Clock Distribution and Recovery. With this method a Master element
distributes a reference clock at protocol level by regularly sending
TDM PW packets (SAToP, CESoPSN or TDMoIP) to Slave elements. This
process is based on the fact that the volume of transmitted data
arrival is considered as an indication of the source frequency that
could be used by the Slave element to recover the source clock
frequency. Consequently, with the current methods, the PE connected
to the Master must setup and maintain as many VPWS (P2P) as their are
Slave elements, and the Master has to replicate the traffic. A
better solution to deliver the clock frequency would be to use a VPMS
which supports P2MP traffic. This may scale better than P2P
services (VPWS) with regards to the forwarding plane at the Master
since the traffic is no longer replicated to individual VPWSes (P2P)
but only to the AC associated to the VPMS (P2MP). It may ease the
provisioning process since only one source endpoint must be
configured at the Ingress PE. This alleviated provisioning process
would simplify the introduction of new Base
Stations. The main gain would be to avoid replication on the Master
and hence save bandwidth consumed by the synchronization traffic
which typically requires the highest level of QoS. This kind of
traffic will be competing with equivalent QOS traffic like VoIP, which
is why it is significant to save the slightest bandwidth.
</t>
</section>
</section>
<section title="Reference Model">
<t>
The VPMS reference model is shown in Figure 1.
</t>
<figure>
<artwork><![CDATA[
+-----+ AC1 AC2 +-----+
| CE1 |>---+ ------------------------ +--->| CE2 |
+-----+ | | | | +-----+
VPMS A | +------+ VPMS A +------+ | VPMS A
Sender +->|......>...+.......... >......|>-+ Receiver
| VPMS | . | VPMS |
| PE1 | . VPMS B | PE2 |
+-<|......<.. . ....+.....<......|<-+
| +------+ . . +------+ |
+-----+ | | . . | | +-----+
| CE4 |<---+ |Routed . . | +---| CE3 |
+-----+ AC4 |Backbone. . | AC3 +-----+
VPMS B | . . | VPMS B
Receiver | +-v-----v-+ | Sender
------| . . |-------
| . VPMS. |
| . PE3 . |
+---------+
v v
| |
AC5| |AC6
v v
+-----+ +-----+
| CE5 | | CE6 |
+-----+ +-----+
VPMS A VPMS B
Receiver Receiver
Figure 1: Reference Model for VPMS
]]></artwork>
</figure>
<t>
A single VPMS instance provides
isolated service reachability domains to each customer.
One VPMS instance corresponds to a unique unidirectional
point-to-multipoint service.
In Figure 1, there are two VPMS instances shown,
VPMS A and VPMS B. In principle, there is no traffic exchange
allowed between these different instances.
</t>
<t>
In a VPMS, a single CE-PE connection is used for transmitting frames
for delivery to multiple remote CEs, with point-to-multipoint duplication.
The SP's network (PE as well as P) has a role to duplicate frames so that
The traffic source does not need to send multiple frames to individual
receivers.
</t>
<t>
In a VPMS, there are two types of CE, senders and receivers.
A sender CE can send out traffic
as a source into a VPMS instance. A receiver CE can receive traffic
from a sender site, but cannot receive from other receiver CEs.
A sender CE itself does not have capability of receiving traffic.
</t>
<t>
Like VPWS, an Attachment Circuit (AC) is provided to accommodate CEs
in a VPMS. In a VPMS, an AC attached to a VPMS MUST be configured as
"sender" or "receiver" not both. That is, any AC is associated with
the role of either sending side (Tx) or receiving side (Rx) from the
view of the CE. Thus every AC deals with unidirectional traffic flows.
In Figure 1, AC1 and AC3 are configured as senders while AC2,
AC4, AC5 and AC6 are configured as receivers. CE1 could send traffic to
VPMS A via AC1, but it could also receive traffic from VPMS B if
another AC is connected to CE1.
</t>
<t>
Basically there is a
one-to-one mapping between an attachment circuit and
each customer's P2MP topology.
A unique VPMS instance corresponds to each topology.
For example, all traffic from CE1 to PE1 (thorough AC1) is mapped to
VPMS A's topology (to CE2 and CE5).
</t>
<t>
In the context of VPMS, one "VPN" is a specific set of sites that
have been configured to allow communication, composed of one
or more sets of VPMS instances. The customer's administrative
policies may allow sender and receiver CEs to be overlapped by multiple
VPMS instances (for details, see Section 6.1. as an example). A VPN
will be finally defined by those VPMS instance sets. In short, VPMS
is defined as a common point-to-multipoint (P2MP) delivery
topology, and the customer's administrative policy will determine the
real VPN domain in the broad sense by picking up one or more VPMS
instances.
</t>
<t>
In a VPMS, PEs will be connected using PW technology which may
include P2MP traffic optimization. P2MP traffic optimization will
provide the benefit of traffic replication for high bandwidth efficiency.
The sender CE has only to transmit one stream towards the PE, it does not have to replicate traffic. The backbone side is a IP or MPLS-enabled routed PSN.
</t>
<t>
VPMS can support various Layer 2 protocol services
such as Ethernet, ATM, etc.
</t>
</section>
<section title="Customer Requirements">
<section title="Service Topology">
<section title="Point-to-Multipoint Support">
<t>
A solution MUST support unidirectional point-to-multipoint
connectivity from a sender to multiple receivers.
A sender CE is assured to send traffic to one or more receiver CEs.
Receiver CEs include not only the CEs which are located at remote sites,
but also the local CEs which are connected to the same sender-side PE.
If there is only one receiver in the instance, it is considered equivalent to
unidirectional point-to-point traffic.
</t>
</section>
<section title="Multiple Source Support">
<t>
A solution MUST support multiple sender topologies in one VPMS
instance, where a common receiver group is reachable from two or more
senders. This means that a solution needs to support having multiple
P2MP topologies in the backbone whose roots are located apart in a
common service. In other words, each P2MP topology MUST only have a single sender, however multiple P2MP topologies can be grouped together into a single VPMS instance.
For example, in Figure 2, traffic from sender CE1
and CE2 both reach receivers CE3 and CE4 while CE1, CE2, CE3 and CE4
all are associated with a single service. This topology is useful
for increasing service reliability by redundant sources. Note that
every receiver has only to have one AC connected to each PE to
receive traffic. (in Figure 2, AC3 and AC4 respectively). Thus a
solution will also need to support protection and restoration
mechanism combining these multiple P2MP topologies. (See section 6.4
too).
</t>
<figure>
<artwork><![CDATA[
+-----+ AC1 AC2+-----+
| CE1 |>-+ ---------------------------- +-<| CE2 |
+-----+ | | | | +-----+
VPMS A | +------+ +------+ | VPMS A
Sender +->|......>.. .............+..<......|<-+ Sender
Tx | VPMS | . . . | VPMS | Tx
| PE 1 | . . . | PE 2 |
| | . . . | |
+------+ . . . +------+
| . . . |
| +.. . ...... . |
| . . . . |
| . . . . |
| +-v----v-+ +-v----v-+ |
---| . . |---| . . |---
VPMS| . . | | . . |VPMS
PE 3| . | | . |PE 4
+--------+ +--------+
v v
AC3| |AC4
v v
+-----+ +-----+
| CE3 | | CE4 |
+-----+ +-----+
VPMS A VPMS A
Receiver Receiver
Figure 2: Multiple source support
]]></artwork>
</figure>
</section>
<section title="Reverse Traffic Support">
<t>
There are cases where a reverse traffic flow is necessary. A sender CE
might sometimes want to receive traffic from a receiver CE.
There are some usage scenarios for this, such as stream monitoring through a
loopback mechanism, control channels which need feedback communication
etc. The simplest way to accomplish this is to provide different
VPMS instances for reverse traffic, i.e. a sender CE is a receiver
of another VPMS instance.
</t>
<t>
Figure 3 illustrates this kind of reverse traffic scenario,
where CE1 is configured as a sender in VPMS A and a receiver
in VPMS B. VPMS B is used for reverse traffic.
Note that a closed single
network here is composed of two VPMS instances. In operational
terms, CE1 and CE4 belong to the same closed "VPN" by
administrative policy (e.g., CE1,
CE2, CE3 and CE4 are the devices in one enterprise's intranet
network).
</t>
<t>
Such bi-directional instances can be easily created if two distinct
ACs are provisioned for sending and receiving exclusively (e.g., if
VLAN id in dot1Q tagged frame is a service delimiter, different VLAN
ids are uniquely allocated for Tx and Rx). This approach is
acceptable if a receiver CE device can change Layer 2 interface
appropriately in data transmitting and receiving.
</t>
<t>
Meanwhile it is also true that this might be considered a limitation
in some deployment scenarios. If a CE is an IP router or Ethernet
bridge, reverse traffic is normally expected to be received on the
same interface as forward traffic on the receiver CE. (i.e., the same VLAN id is to be
used for reverse traffic if the AC supports dot1Q tagged frames.)
</t>
<t>
Therefore, in a VPMS solution,
both of the two type of ACs, sending (Tx) and receiving (Rx),
SHOULD be allowed to be placed in the same physical/virtual
circuit.
In Figure 3, suppose
AC5 of VPMS A is provisioned as {VLAN id = 100, direction= Rx}.
It is expected that operators can provision AC6 of VPMS B
in the same physical port as
{VLAN id = 100, direction = Tx} or as
{VLAN id = 101, direction = Tx}.
That is, the combination between VLAN id and the flow direction
is now considered to be a service delimiter.
</t>
<t>
Note, in most implementations of VPWS today, every AC is always
considered bidirectional and a unique Layer 2 header/circuit (ATM
VPI/VCI, an Ethernet port, a VLAN etc.) is considered the service
delimiter. In contrast in VPMS, every AC is considered
unidirectional and traffic direction is an additional element to
identify a unique AC.
</t>
<figure>
<artwork><![CDATA[
+-----+ <-- Rx VPMS B
+ CE1 +<----------------+
+-----+--------------+ |
VPMS A Sender --> Tx VPMS A| |
VPMS B Receiver AC1 v ^ AC2
+----------+ VPMS
| . . | PE1
| . ... |
-------| . . |--------
| +-v------^-+ |
| . . |
| + . |
+------+ . . . . +------+
+-<|......<.. . .. . ......>..... |>-+
| | VPMS | . . | VPMS | |
AC3| | PE2 | . . | PE3 | |AC4
| +------+ . . +------+ |
+-----+ | | . . | | +-----+
| CE2 |<--+ | Routed . . | +-->| CE3 |
+-----+ <-- | Backbone. . | --> +-----+
VPMS A Rx | +-v------^-+ | Rx VPMS A
Receiver -------| . . |-------- Receiver
| . ... |
| . . | VPMS
+----------+ PE4
AC5v ^AC6
| | <-- Tx VPMS B +-----+
| +----------------<| CE4 |
+------------------->+-----+
--> Rx VPMS A VPMS A Receiver
VPMS B Sender
Figure 3: Reverse traffic support
]]></artwork>
</figure>
</section>
</section>
<section title="Transparency">
<t>
A solution is intended to provide Layer 2 protocol transparency.
Transparency SHOULD be honoured per VPMS instance basis.
In other words, Layer 2 traffic can be transparently transported
from a sender CE to receiver CEs in a given instance. Note, however,
if service delimiting fields (VLAN Id in Ethernet, VPI/VCI in ATM,
DLCI in FR etc.) are assigned by SP, they are not transparent. It
depends on SP’s choice if they are assigned at each AC. Hence it
could be that some of receiver CEs are getting traffic with different
delimiting fields than the other receiver CEs.
</t>
<t>
VPMS solution SHOULD NOT require any special packet processing by the
end users (CEs).
</t>
</section>
<section title="Quality of Service (QoS)">
<t>
A customer may require that the VPMS service provide the guaranteed QoS.
In particular, for real time applications which are considered common
in point-to-multipoint delivery, delay and loss sensitive traffic
MUST be supported. The solution SHOULD provide native QoS techniques
for service class differentiation,
such as IEEE 802.1p CoS for Ethernet.
</t>
<t>
For bandwidth committed services (e.g., ATM CBR),
a solution SHOULD guarantee end-to-end bandwidth.
It MAY provide flow admission control mechanisms to achieve that.
</t>
</section>
<section title="Protection and Restoration">
<t>
A solution MUST provide protection and restoration mechanism
for end-to-end services.
</t>
<t>
A solution MUST allow dual-homed redundant access from a CE to
multiple PEs. Additionally, a solution SHOULD provide
protection mechanism between the different PEs to which a CE is attached. This is because
when an ingress PE node fails whole traffic delivery will fail unless
a backup sender PE is provided, even in case of dual-homed access.
Similarly, if an egress PE node fails, traffic toward that CE is never
received unless a backup egress PE is provided. Figure 4 is an example for this access topology.
</t>
<t>
When dual-homed access to sender PEs is provided, a sender CE MAY
transmit just a single copy of the traffic to either one of the two sender PEs, or it MAY
transmit a copy of the traffic to both the PEs simultaneously. The latter
scenario is usually applicable when a source device has only a simple
forwarding capability without any switchover functionality. Note
that it consumes more resources at CE-PE than in the single copy case. In the
dual traffic case, the backup ingress PE SHOULD be able to
filter unnecessary traffic under normal conditions. Also in either case,
single traffic or dual traffic, the protection mechanism of ingress
PEs described in the previous paragraph will be necessary to handle
the traffic appropriately.
</t>
<t>
In the case of dual-homed access to receiver PEs, a receiver CE MAY
receive a single copy of the traffic from either one of the two sender PEs, or receive
a copy of the traffic from both PEs simultaneously. It might be needed to
support switchover mechanism between egress PEs in failure. The dual
traffic approach is applicable if CE has fast switchover capability
as a receiver, but note that additional traffic resources are always
consumed at PE-CE.
</t>
<figure>
<artwork><![CDATA[
+-----+
+ CE1 +--------------+
+-----+ \
VPMS A | |
Sender | v AC1
(dual-homed)| +----+
| -----|VPMS|--------
| | | PE1| |
\ | +----+ |
\ AC2 +----+ +----+ AC4
+------>|VPMS| |VPMS|------------+
| PE2| Routed | PE3| \
+----+ Backbone +----+\ |
AC3 / | | \ AC5 v
+-----+ / | | \ +-----+
+ CE2 +<-+ | | \ | CE3 |
+-----+ | +----+ | \ +-----+
VPMS A ----|VPMS|--------- \ VPMS A
Receiver | PE4| | Receiver
+----+ |
| AC6 v
\ +-----+
+--------------->| CE4 |
+-----+
VPMS A
Receiver
(dual-homed)
Figure 4: Dual homing support
]]></artwork>
</figure>
</section>
<section title="Security">
<t>
The basic security requirement raised in
Section 6.5 of <xref target="RFC4665"/>
also applies to VPMS.
</t>
<t>
In addition, a VPMS solution MAY have the mechanisms to activate the
appropriate filtering capabilities (for example, MAC/VLAN filtering
etc.), and it MAY be added with the filtering control mechanism
between particular sender/receiver sites inside a VPMS instance. For
example, in Figure 1, filtering can be added such that traffic
from CE1 to CE4 and CE5 is allowed but traffic from CE1 to CE6 is
filtered.
</t>
</section>
<section title="Reordering Prevention">
<t>
A solution SHOULD prevent Layer 2 frame reordering when
delivering customer
traffic under normal conditions.
</t>
</section>
<section title="Failure reporting">
<t>
A solution MAY provide information to the customer about
failures. For example, if there is a loss of connectivity toward
some of the receiver CEs, it is reported to the sender CE.
</t>
</section>
</section>
<section title="Service Provider Network Requirements">
<section title="Scalability">
<t>
A VPMS 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 (per VPMS instance and total in a SP network)</t>
<t hangText='-'>the number of VPMS instances (per PE and total)</t>
<t hangText='-'>the number of sender CEs (per PE, VPMS instance and total)</t>
<t hangText='-'>the number of receiver CEs (per PE, VPMS instance and total)</t>
</list>
</t>
<t>
A VPMS 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='-'>
other particular elements inherent to each solution that
impact scalability
</t>
</list>
</t>
</section>
<section title="Pseudo Wire Signaling and PSN Tunneling">
<t>
A VPMS solution SHOULD provide an efficient replication that can
contribute to reducing the bandwidth resource required for VPMS in a SP's network. For
supporting optimized replication, it is expected to take advantage of
PW mechanisms that are capable of P2MP traffic. However, the detailed
discussion of this type of PW is out of scope of this document.
Specific requirements for such a PW extension is discussed in
<xref target="I-D.jounay-pwe3-p2mp-pw-requirements"/>.
</t>
<t>
This document does not raise any specific requirements for
particular PSN tunneling schemes (point-to-point, point-to-multipoint and
multipoint-to-multipoint) that is applied only to VPMS.
Requirements for PSN tunnels used by P2MP PWs is discussed in
<xref target="I-D.jounay-pwe3-p2mp-pw-requirements"/>.
The type of
PSN tunnel used will be dependent on individual deployment scenarios
(e.g., which PSN protocol is available now in the core and how much
network resources operators will want to optimize).
</t>
</section>
<section title="Discovering VPMS Related Information">
<t>
A solution SHOULD support auto-discovery methods that dynamically
allow VPMS information to be discovered by the PEs to minimize the
amount of configuration the SP must perform.
</t>
<t>
All of the requirements on discovery described in
Section 7.3 of <xref target="RFC4665"/>
SHOULD be satisfied in VPMS as well.
</t>
<t>
Auto-discovery will help operators' initial configuration of
adding a new VPN (i.e., VPMS instance),
adding/deleting new sender/receiver, and so on.
</t>
<t>
The information related to remote sites will be as follows:
</t>
<t>
<list style='hanging'>
<t hangText='-'>
Information to identify the VPMS instance
</t>
<t hangText='-'>
PE router ID / IP address as location information
</t>
<t hangText='-'>
Information to identify Attachment Circuits
and their associated group information to
compose a unique service (i.e., VPMS instance).
</t>
<t hangText='-'>
CE role in each VPMS (Sender and/or Receiver)
</t>
<t hangText='-'>
SP-related information (AS number, etc. for an inter-provider case)
</t>
</list>
</t>
<t>
(Needs discussion, including showing example scenario.)
</t>
</section>
<section title="Activation and Deactivation">
<t>
This section raises generic requirements for handling related
information about remote sites after the initial provisioning to ease the
total operation of VPMS.
</t>
<t>
A solution SHOULD provide a way to
activate/deactivate the administrative status of each CE/AC.
After initial provisioning,
a SP might change connectivity configuration
between particular CEs inside a single VPMS instance
for operational reasons. This feature will be beneficial to
help such a scenario.
</t>
<t>
For example, in Figure 5,
CE1, CE3, CE4 and CE5 (and their ACs) are initially provisioned
for VPMS A. CE2 is not provisioned for any VPMSes. In VPMS A, CE1 is
a sender and CE3, CE4 and CE5 are receivers.
Traffic will usually flow from CE1 to all
receivers, CE3, CE4 and CE5. However, for maintenance operation,
application's request (e.g., stream program has changed) or some other reasons,
CE4 needs to
be set as administratively deactivated. Then it becomes necessary to
turn off traffic from PE4 to CE4. This operation
must be appropriately distinguished from failure cases.
</t>
<t>
When deactivating a particular site, backbone PSN/PW resources (e.g.,
admission control of PSN tunnel) MAY be released for that particular
direction in order to provide that bandwidth to other services. In
Figure 5, CE3 is now administratively activated and receiving traffic.
However, if CE3 comes to be administratively deactivated, and if
RSVP-TE (including P2P and/or P2MP) is used for backbone PSN, then TE
reserved resources from PE1 to PE3 may be released.
</t>
<t>
In addition, a solution SHOULD allow single-sided activation
operation at a sender PE. In some scenarios, operators prefer
centralized operation. This is often considered natural for one-way
digital audio/video distribution applications: SPs often want to
complete their service delivery by a single operation at one source
PE, not by multiple operations at many receiver PEs. Figure 5
illustrates this scenario, where a SP only has to do single-sided
operation at PE1 (source) to administratively activate/deactivate
various connections from AC1 to AC3, AC4 and/or AC5. It is not
needed to perform operations on PE3 and PE4 directly.
</t>
<figure>
<artwork><![CDATA[
+-----+ AC1
+ CE1 +----------------+
+-----+ |
VPMS A Sender |
(sending now) v
+----+
-----|VPMS|--------
| | PE1| |
| +----+ |
+----+ +----+
|VPMS| |VPMS|
| PE2| Routed | PE3|
+----+ Backbone +----+
AC2 / | | \ AC3
+-----+ / | | \ +-----+
+ CE2 +<-+ | | +->| CE3 |
+-----+ | +----+ | +-----+
(not provisioned) ----|VPMS|--------- VPMS A Receiver
| PE4| (receiving now)
+----+
AC5 / \ AC4
+-----+ / \ +-----+
+ CE5 +<----------+ +---------------->| CE4 |
+-----+ +-----+
VPMS A Receiver VPMS A Receiver
(receiving now) (not receiving)
CE1/AC1: Administratively activated
CE2/AC2: No VPMS provisioned
CE3/AC3: Administratively activated
CE4/AC4: Administratively deactivated
CE5/AC5: Administratively activated
Figure 5: Site activation and deactivation
]]></artwork>
</figure>
</section>
<section title="Inter-AS support">
<t>
A solution SHOULD support inter-AS scenarios, where there is more
than one provider providing a common VPMS instance and VPN. More
specifically, it is necessary to consider the case where some of the
PEs that compose one VPMS belong to several different ASes.
</t>
</section>
<section title="Operation, Administration and Maintenance">
<t>
TBD (for further study for next revision)
</t>
</section>
<section title="Security">
<t>
TBD (for further study for next revision)
</t>
</section>
</section>
<section title="Security Considerations">
<t>
Security consideration will be covered by section 6.5. and section 7.7.
(This is for further study for next revision.)
</t>
</section>
<section title="IANA Considerations">
<t>
This document has no actions for IANA.
</t>
</section>
<section title="Acknowledgments">
<t>
Many thanks to Ichiro Fukuda, Kazuhiro Fujihara, Ukyo Yamaguchi and Kensuke Shindome for their valuable review and feedback.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc4026;
</references>
<references title="Informative References">
&rfc4664;
&rfc4665;
&rfc4761;
&rfc4762;
&I-D.jounay-pwe3-p2mp-pw-requirements;
&I-D.ietf-l2vpn-vpls-mcast;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 22:36:17 |