Network Working Group Y. Kamite
Internet-Draft NTT Communications
Intended status: Informational F. Jounay
Expires: January 15, 2009 France Telecom
B. Niven-Jenkins
BT
July 14, 2008
Framework and Requirements for Virtual Private Multicast Service (VPMS)
draft-kamite-l2vpn-vpms-frmwk-requirements-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009.
Abstract
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.
Kamite, et al. Expires January 15, 2009 [Page 1]
Internet-Draft VPMS Framework and Requirements July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope of This Document . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Ethernet Use Case . . . . . . . . . . . . . . . . . . . . 5
4.2. ATM-based Use Case . . . . . . . . . . . . . . . . . . . . 5
4.3. TDM-based Use Case . . . . . . . . . . . . . . . . . . . . 6
5. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 7
6. Customer Requirements . . . . . . . . . . . . . . . . . . . . 9
6.1. Service Topology . . . . . . . . . . . . . . . . . . . . . 9
6.1.1. Point-to-Multipoint Support . . . . . . . . . . . . . 9
6.1.2. Multiple Source Support . . . . . . . . . . . . . . . 9
6.1.3. Reverse Traffic Support . . . . . . . . . . . . . . . 10
6.2. Transparency . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . . 13
6.4. Protection and Restoration . . . . . . . . . . . . . . . . 13
6.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.6. Reordering Prevention . . . . . . . . . . . . . . . . . . 14
6.7. Failure reporting . . . . . . . . . . . . . . . . . . . . 15
7. Service Provider Network Requirements . . . . . . . . . . . . 15
7.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Pseudo Wire Signaling and PSN Tunneling . . . . . . . . . 15
7.3. Discovering VPMS Related Information . . . . . . . . . . . 16
7.4. Activation and Deactivation . . . . . . . . . . . . . . . 16
7.5. Inter-AS support . . . . . . . . . . . . . . . . . . . . . 18
7.6. Operation, Administration and Maintenance . . . . . . . . 18
7.7. Security . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Kamite, et al. Expires January 15, 2009 [Page 2]
Internet-Draft VPMS Framework and Requirements July 2008
1. Introduction
1.1. Problem Statement
[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).
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.
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.
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.
Consequently, There is a real need for a solution that natively
provides point-to-multipoint service in L2VPN.
1.2. Scope of This Document
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).
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 [RFC4664] and requirements [RFC4665]. It
is intended to show a proper reference to introduce VPMS and a
Kamite, et al. Expires January 15, 2009 [Page 3]
Internet-Draft VPMS Framework and Requirements July 2008
checklist of requirements that will provide a consistent way to
evaluate how well each solution satisfies the requirements.
The technical specifications are outside the scope of this document.
There is no intent to specify solution-specific details.
This document provides requirements from both the Service Provider's
and the Customer's point of view.
2. Conventions used in this document
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 [RFC2119] .
3. Terminology
The content of this document makes use of the terminology defined in
[RFC4026]. For readability purposes, we list some of the terms here
in addition to some specific terms used in this document.
3.1. Acronyms
P2P: Point-to-Point
P2MP: Point-to-Multipoint
PW: Pseudowire
VPMS: Virtual Private Multicast Service
PE/CE: Provider/Customer Edge
P: Provider Router
AC: Attachment Circuit
PSN: Packet Switched Network
SP: Service Provider
4. Use Cases
Kamite, et al. Expires January 15, 2009 [Page 4]
Internet-Draft VPMS Framework and Requirements July 2008
4.1. Ethernet Use Case
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.
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.
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.
4.2. ATM-based Use Case
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
Kamite, et al. Expires January 15, 2009 [Page 5]
Internet-Draft VPMS Framework and Requirements July 2008
of replication for ATM to support IP multicast services.
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.
4.3. TDM-based Use Case
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.
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.
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
Kamite, et al. Expires January 15, 2009 [Page 6]
Internet-Draft VPMS Framework and Requirements July 2008
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.
5. Reference Model
The VPMS reference model is shown in Figure 1.
+-----+ 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
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
Kamite, et al. Expires January 15, 2009 [Page 7]
Internet-Draft VPMS Framework and Requirements July 2008
no traffic exchange allowed between these different instances.
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.
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.
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.
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).
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.
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.
VPMS can support various Layer 2 protocol services such as Ethernet,
ATM, etc.
Kamite, et al. Expires January 15, 2009 [Page 8]
Internet-Draft VPMS Framework and Requirements July 2008
6. Customer Requirements
6.1. Service Topology
6.1.1. Point-to-Multipoint Support
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.
6.1.2. Multiple Source Support
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).
Kamite, et al. Expires January 15, 2009 [Page 9]
Internet-Draft VPMS Framework and Requirements July 2008
+-----+ 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
6.1.3. Reverse Traffic Support
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.
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).
Kamite, et al. Expires January 15, 2009 [Page 10]
Internet-Draft VPMS Framework and Requirements July 2008
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.
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.)
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.
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.
Kamite, et al. Expires January 15, 2009 [Page 11]
Internet-Draft VPMS Framework and Requirements July 2008
+-----+ <-- 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
6.2. Transparency
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.
VPMS solution SHOULD NOT require any special packet processing by the
end users (CEs).
Kamite, et al. Expires January 15, 2009 [Page 12]
Internet-Draft VPMS Framework and Requirements July 2008
6.3. Quality of Service (QoS)
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.
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.
6.4. Protection and Restoration
A solution MUST provide protection and restoration mechanism for end-
to-end services.
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.
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.
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.
Kamite, et al. Expires January 15, 2009 [Page 13]
Internet-Draft VPMS Framework and Requirements July 2008
+-----+
+ 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
6.5. Security
The basic security requirement raised in Section 6.5 of [RFC4665]
also applies to VPMS.
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.
6.6. Reordering Prevention
A solution SHOULD prevent Layer 2 frame reordering when delivering
customer traffic under normal conditions.
Kamite, et al. Expires January 15, 2009 [Page 14]
Internet-Draft VPMS Framework and Requirements July 2008
6.7. Failure reporting
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.
7. Service Provider Network Requirements
7.1. Scalability
A VPMS solution MUST be designed to scale well with an increase in
the number of any of the following metrics:
- the number of PEs (per VPMS instance and total in a SP network)
- the number of VPMS instances (per PE and total)
- the number of sender CEs (per PE, VPMS instance and total)
- the number of receiver CEs (per PE, VPMS instance and total)
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.
The scalability characteristics SHOULD include:
- the processing resources required by the control plane in managing
PWs (neighborhood or session maintenance messages, keepalives,
timers, etc.)
- the processing resources required by the control plane in managing
PSN tunnels
- the memory resources needed for the control plane
- other particular elements inherent to each solution that impact
scalability
7.2. Pseudo Wire Signaling and PSN Tunneling
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 [I-D.jounay-pwe3-p2mp-pw-requirements].
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
Kamite, et al. Expires January 15, 2009 [Page 15]
Internet-Draft VPMS Framework and Requirements July 2008
[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).
7.3. Discovering VPMS Related Information
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.
All of the requirements on discovery described in Section 7.3 of
[RFC4665] SHOULD be satisfied in VPMS as well.
Auto-discovery will help operators' initial configuration of adding a
new VPN (i.e., VPMS instance), adding/deleting new sender/receiver,
and so on.
The information related to remote sites will be as follows:
- Information to identify the VPMS instance
- PE router ID / IP address as location information
- Information to identify Attachment Circuits and their associated
group information to compose a unique service (i.e., VPMS
instance).
- CE role in each VPMS (Sender and/or Receiver)
- SP-related information (AS number, etc. for an inter-provider
case)
(Needs discussion, including showing example scenario.)
7.4. Activation and Deactivation
This section raises generic requirements for handling related
information about remote sites after the initial provisioning to ease
the total operation of VPMS.
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.
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
Kamite, et al. Expires January 15, 2009 [Page 16]
Internet-Draft VPMS Framework and Requirements July 2008
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.
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.
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.
Kamite, et al. Expires January 15, 2009 [Page 17]
Internet-Draft VPMS Framework and Requirements July 2008
+-----+ 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
7.5. Inter-AS support
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.
7.6. Operation, Administration and Maintenance
TBD (for further study for next revision)
Kamite, et al. Expires January 15, 2009 [Page 18]
Internet-Draft VPMS Framework and Requirements July 2008
7.7. Security
TBD (for further study for next revision)
8. Security Considerations
Security consideration will be covered by section 6.5. and section
7.7. (This is for further study for next revision.)
9. IANA Considerations
This document has no actions for IANA.
10. Acknowledgments
Many thanks to Ichiro Fukuda, Kazuhiro Fujihara, Ukyo Yamaguchi and
Kensuke Shindome for their valuable review and feedback.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, March 2005.
11.2. Informative References
[I-D.ietf-l2vpn-vpls-mcast]
Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter,
"Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-04 (work
in progress), June 2008.
[I-D.jounay-pwe3-p2mp-pw-requirements]
JOUNAY, F., "Use Cases and signaling requirements for
Point-to-Multipoint PW",
draft-jounay-pwe3-p2mp-pw-requirements-01 (work in
progress), November 2007.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006.
Kamite, et al. Expires January 15, 2009 [Page 19]
Internet-Draft VPMS Framework and Requirements July 2008
[RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for
Layer 2 Provider-Provisioned Virtual Private Networks",
RFC 4665, September 2006.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling",
RFC 4761, January 2007.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
Authors' Addresses
Yuji Kamite
NTT Communications Corporation
Tokyo Opera City Tower
3-20-2 Nishi Shinjuku, Shinjuku-ku
Tokyo 163-1421
Japan
Email: y.kamite@ntt.com
Frederic Jounay
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
Email: frederic.jounay@orange-ftgroup.com
Ben Niven-Jenkins
BT
208 Callisto House, Adastral Park
Ipswich, IP5 3RE
UK
Email: benjamin.niven-jenkins@bt.com
Kamite, et al. Expires January 15, 2009 [Page 20]
Internet-Draft VPMS Framework and Requirements July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Kamite, et al. Expires January 15, 2009 [Page 21]