One document matched: draft-ietf-l2vpn-vpms-frmwk-requirements-01.txt
Differences from draft-ietf-l2vpn-vpms-frmwk-requirements-00.txt
Network Working Group Y. Kamite
Internet-Draft NTT Communications
Intended status: Informational F. Jounay
Expires: January 14, 2010 France Telecom
B. Niven-Jenkins
BT
D. Brungard
AT&T
L. Jin
Nokia Siemens Networks
July 13, 2009
Framework and Requirements for Virtual Private Multicast Service (VPMS)
draft-ietf-l2vpn-vpms-frmwk-requirements-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 14, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
Kamite, et al. Expires January 14, 2010 [Page 1]
Internet-Draft VPMS Framework and Requirements July 2009
and restrictions with respect to this document.
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 14, 2010 [Page 2]
Internet-Draft VPMS Framework and Requirements July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope of This Document . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Ethernet Use Case . . . . . . . . . . . . . . . . . . . . 6
4.2. ATM-based Use Case . . . . . . . . . . . . . . . . . . . . 7
4.3. TDM-based Use Case . . . . . . . . . . . . . . . . . . . . 7
5. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 8
6. Customer Requirements . . . . . . . . . . . . . . . . . . . . 11
6.1. Service Topology . . . . . . . . . . . . . . . . . . . . . 11
6.1.1. Point-to-Multipoint Traffic Support . . . . . . . . . 11
6.1.2. Reverse Traffic Support . . . . . . . . . . . . . . . 11
6.2. Transparency . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . . 14
6.4. High Availability . . . . . . . . . . . . . . . . . . . . 14
6.4.1. Dual-homed Access Support . . . . . . . . . . . . . . 14
6.4.2. Single/Dual Traffic Support in Dual-homed Access . . . 17
6.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.6. Reordering Prevention . . . . . . . . . . . . . . . . . . 17
6.7. Failure reporting . . . . . . . . . . . . . . . . . . . . 18
7. Service Provider Network Requirements . . . . . . . . . . . . 18
7.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Pseudo Wire Signaling and PSN Tunneling . . . . . . . . . 18
7.3. Discovering VPMS Related Information . . . . . . . . . . . 19
7.4. Activation and Deactivation . . . . . . . . . . . . . . . 20
7.5. Inter-AS Support . . . . . . . . . . . . . . . . . . . . . 21
7.6. Co-existence with Existing L2VPNs . . . . . . . . . . . . 22
7.7. Operation, Administration and Maintenance . . . . . . . . 22
7.7.1. Fault Management . . . . . . . . . . . . . . . . . . . 22
7.7.2. Testing . . . . . . . . . . . . . . . . . . . . . . . 23
7.7.3. Performance Management . . . . . . . . . . . . . . . . 23
7.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Kamite, et al. Expires January 14, 2010 [Page 3]
Internet-Draft VPMS Framework and Requirements July 2009
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 not possible to replicate traffic for point-to-
multipoint services in the SP's network side. A SP could build
multiple Pseudowires (PWs) independently and have the CEs replicate
traffic over them, but this is not only inconvenient for the
customer, it's a waste of bandwidth resources.
In a VPLS, SPs can natively offer multipoint connectivity across
their backbone. Although it is seemingly applicable for point-to-
multipoint service as well, there remains extra complexity for SPs to
filter unnecessary traffic between irrelevant sites (i.e., from a
receiver PE to another receiver PE) because VPLS provides multipoint-
to-multipoint connectivity between CEs. Moreover, VPLS's MAC-based
learning/forwarding operation is unnecessary for some scenarios
particularly if customers only need 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 class of provider-
provisioned Layer 2 Virtual Private Networks (L2VPN).
This document introduces a new service framework, reference model and
functional requirements for VPMS by extending the existing framework
[RFC4664] and requirements [RFC4665] for L2VPNs.
Kamite, et al. Expires January 14, 2010 [Page 4]
Internet-Draft VPMS Framework and Requirements July 2009
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
VPMS instance: A service entity manageable in a VPMS that provides
isolated service reachability domain to each CE. It corresponds
to a so-called "VPN" as a specific set of sites that allows
communication.
Kamite, et al. Expires January 14, 2010 [Page 5]
Internet-Draft VPMS Framework and Requirements July 2009
P2MP connection: A logical entity between PE/ACs in a given VPMS
instance that transfers unidirectional traffic transparently from
one local ingress AC to one or more remote egress ACs.
4. Use Cases
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 (P2MP native Ethernet)
services, 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
complexity 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 leaves is not allowed.
It might require extra efforts to guarantee this behavior in VPLS.
And in some P2MP scenarios there no traffic from leafs to root. 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 for multiple multicast
groups. All traffic from a particular Attachment Circuit (AC) will
be forwarded 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.
Kamite, et al. Expires January 14, 2010 [Page 6]
Internet-Draft VPMS Framework and Requirements July 2009
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
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.
One use case is TDM-based multicast video delivery. That is, data
duplication is simply provided by Layer 1, without using upper
layer's multicast protocols.
A second use case is TDM clock distribution scenario. 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). VPWS (P2P service) can be used between each Base
Station and their corresponding controller, nothing more is required.
As far as synchronization in a PSN environment is concerned,
different mechanisms are being considered to provide frequency and
phase synchronization required in the 2G/3G Mobile environment to
guarantee mobile handover and strict QoS. One mechanism consists of
using Adaptive Clock Distribution and Recovery. With this method a
Master element distributes a reference clock frequency 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
Kamite, et al. Expires January 14, 2010 [Page 7]
Internet-Draft VPMS Framework and Requirements July 2009
the source clock frequency. With the current methods, the PE
connected to the Master must setup and maintain as many VPWS (P2P) as
there are Slave elements, and the Master has to replicate the
traffic. A more efficient solution to deliver the clock frequency
would be to use a VPMS which supports P2MP traffic. This would scale
better than P2P services (VPWS) with regards to the forwarding plane
at the Master since the traffic is no longer needs to be replicated
to individual VPWSes (P2P), only a single copy needs to be sent on
the AC associated to the VPMS (P2MP). Also, it may ease the
provisioning process since only one source endpoint needs to be
configured at the Ingress PE. This provisioning process would
simplify the introduction of new Base Stations. The most significant
gain of using VPMS would be that it avoids replication on the Master
and hence saves bandwidth consumption by the synchronization traffic
which typically requires the highest level of QoS. This type of
traffic will be competing with equivalent QoS traffic like VoIP,
which is why it is critical to be able to efficiently use the
bandwidth.
5. Reference Model
The VPMS reference model is shown in Figure 1.
Kamite, et al. Expires January 14, 2010 [Page 8]
Internet-Draft VPMS Framework and Requirements July 2009
+-----+ AC1 AC2 +-----+
| CE1 |>---+ ------------------------ +--->| CE2 |
+-----+ | | VPMS A's P2MP | | +-----+
VPMS A | +------+ Connection +------+ | VPMS A
Sender +->|......>...+.......... >......|>-+ Receiver
| VPMS | . | VPMS |
| PE1 | . | PE2 |
+-<|......<.. . ....+.....<......|<-+
| +------+ . . +------+ |
+-----+ | | . . | | +-----+
| CE4 |<---+ |Routed . . VPMS B's P2MP +---<| CE3 |
+-----+ AC4 |Backbone. . Connection AC3 +-----+
VPMS B | . . | VPMS B
Receiver | +-v-----v-+ | Sender
------| . . |-------
| . VPMS. |
| . PE3 . |
+---------+
v v VPMS A:
| | Root AC : AC1
AC5| |AC6 Leaf AC : AC2, AC5
v v VPMS B:
+-----+ +-----+ Root AC : AC3
| CE5 | | CE6 | Leaf AC : AC4, AC6
+-----+ +-----+
VPMS A VPMS B
Receiver Receiver
Figure 1: Reference Model for VPMS
A VPMS instance is defined as a service entity manageable in the VPMS
architecture. A single VPMS instance provides an isolated service
reachability domain to each CE, so it corresponds to a so-called
"VPN" as it allows communication among a specific set of sites. A
single VPMS instance provides a unique point-to-multipoint L2VPN
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, so they are treated as different VPNs.
In a VPMS, a single CE-PE link 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
replicate frames so that the sender's CE does not need to send
multiple frames to individual receivers.
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
"root" (sender) or "leaf" (receiver) not both. Any AC is associated
Kamite, et al. Expires January 14, 2010 [Page 9]
Internet-Draft VPMS Framework and Requirements July 2009
with the role of either sending side (Tx) or receiving side (Rx) from
the view of the CE. These will be named the root (sender) AC and
leaf (receiver) AC respectively. Unless reverse traffic is
optionally supported, a root AC does not transmit traffic back to a
CE at upstream side, likewise a leaf AC does not receive traffic from
a CE at downstream side. In Figure 1, AC1 and AC3 are configured as
root ACs while AC2, AC4, AC5 and AC6 are configured as leaf ACs. In
VPMS A, CE1 could send traffic via AC1, and CE2 and CE5 could receive
the traffic.
A CE which is locally connected to a root AC is called a root
(sender) CE. Also a CE which is locally connected to a leaf AC is
called a leaf (receiver) CE. However, such CEs's roles will not be
managed directly in VPMS because the configured AC's role (root or
leaf) will automatically determine them.
Similarly, a PE which locally accommodates a root AC is called a root
(sender) PE. A PE which locally accommodates a leaf AC is called a
leaf (receiver) PE.
Basically there is a one-to-one mapping between an attachment circuit
and a VPMS instance. For example, all traffic from CE1 to PE1
(thorough AC1) is mapped to VPMS A (to CE2 and CE5).
In a VPMS, P2MP tree-shaped reachability is given from a single root
AC to several leaf ACs. This will be named a "P2MP connection" in
this VPMS framework. P2MP connection is a logical entity between PE/
ACs in a given VPMS instance that transfers unidirectional traffic
transparently from one local ingress AC to one or more remote egress
ACs.
Similar to other L2VPN mechanisms, the VPMS architecture is based on
PWs which may be using through IP or MPLS-enabled PSN tunnels over a
routed backbone. That is, every P2MP connection can be instantiated
by PW technology that supports P2MP traffic optimization (i.e., P2MP
PW. See section 7.2.). P2MP traffic optimization will provide the
benefit of traffic replication for high bandwidth efficiency. That
is, the sender CE has only to transmit one stream towards the PE and
it does not have to replicate traffic.
Regarding end-to-end traffic topology between the ACs, a single VPMS
instance (i.e., one VPN) may correspond to a single P2MP connection.
In Figure 1, VPMS A (one instance) has one P2MP connection (from AC1
to AC2 and AC5). However, there is also a case that a single VPMS
consists of two or more P2MP connections grouped, which is typically
used for redundancy. The details are given in section 6.4.
VPMS can support various Layer 2 protocol services such as Ethernet,
Kamite, et al. Expires January 14, 2010 [Page 10]
Internet-Draft VPMS Framework and Requirements July 2009
ATM, etc.
6. Customer Requirements
6.1. Service Topology
6.1.1. Point-to-Multipoint Traffic Support
A solution MUST support unidirectional point-to-multipoint traffic
from a sender CE to multiple receiver CEs. A root CE can send
traffic to one or more leaf CEs. Leaf CEs include not only the CEs
which are located at remote sites, but also the local CEs which are
connected to the same root PE. If there is only one receiver in the
instance, it is considered equivalent to unidirectional point-to-
point traffic.
6.1.2. Reverse Traffic Support
There are cases where a reverse traffic flow is needed. A sender CE
may need to receive traffic from receiver CEs. There are some usage
scenarios for this, such as stream monitoring through a loopback
mechanism, control channels which need feedback communication etc. A
possible 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. However, provisioning different VPNs for a
particular customer would make its management task more complex. It
is desired to have an alternative solution for supporting reverse
traffic flow. This section provides additional requirements for this
optional capability.
A VPMS solution MAY support reverse traffic from a leaf AC to a root
AC. Each reverse path is basically given in a P2P (unicast) manner.
In other words, each leaf of the P2MP tree can individually send back
traffic to the root. For this purpose a VPMS instance MAY have more
than one reverse P2P connections as network entity; However, such
network entities MUST have a common field that enables themselves to
be managed together in the same VPN. Any PWs used for such
connections are expected to be assigned a common VPMS instance ID.
Note, a VPMS does not assume any-to-any multipoint reachability.
Therefore, in principle, every leaf AC does not exchange traffic
directly with other leaf ACs even if reverse traffic is supported.
Figure 3 illustrates this kind of scenario, where CE1 is configured
as a sender in VPMS A. AC1 is a root AC, and AC2/AC3/AC4 are leaf
ACs. P2MP connection is given for forward traffic. Unidirectional
P2P connection is also provided for reverse traffic from AC4 to AC1.
Kamite, et al. Expires January 14, 2010 [Page 11]
Internet-Draft VPMS Framework and Requirements July 2009
Other reverse P2P connections can be provided similarly. (from AC2 to
AC1 / from AC3 to AC1).
In this case, PEs need to deal with two types of traffic, locally-
attached CE's sending (Tx) and receiving (Rx) flows. In Figure 3,
they are both passing through the same AC (AC1 and AC4). But it is
an implementation matter if Tx and Rx traffic are conveyed on the
same physical link or separate links. It is also possible that a
root PE multiplexes two ore more reverse traffic from different
leaves and transmits it to an upstream CE over the same local link.
Note, in most implementations of VPWS today, every AC is always
considered bidirectional. In contrast, in VPMS, every AC can be
chosen unidirectional (if it is a totally unidirectional service), or
bidirectional (if reverse traffic is supported).
Kamite, et al. Expires January 14, 2010 [Page 12]
Internet-Draft VPMS Framework and Requirements July 2009
+-----+ <-- Rx (bidirectional)
| CE1 |--------------+
+-----+ --> Tx |
VPMS A Sender |
AC1 |
+----------+ VPMS
| . . | PE1
| . .... |
-------| . . |--------
| P2MP +-v------^-+ |
Connection . . |
(forward) + . |
| . . |
+------+ . . . . +------+
+-<|......<.. . .. . ......>..... |>-+
| | VPMS | . . | VPMS | |
AC2| | PE2 | . . | PE3 | |AC3
| +------+ . . +------+ |
+-----+ | | . . P2P | | +-----+
| CE2 |<--+ | Routed . . Connection +-->| CE3 |
+-----+ <-- | Backbone. . (reverse)| --> +-----+
VPMS A Rx | +-v------^-+ | Rx VPMS A
Receiver -------| . . |-------- Receiver
| . .... |
| . . | VPMS
+----------+ PE4
AC4|
|
| <-- Tx +-----+
+--------------------| CE4 |
(bidirectional) --> Rx +-----+
VPMS A
Receiver
Figure 3: Reverse traffic support
6.2. Transparency
A solution is intended to provide Layer-2 traffic transparency.
Transparency SHOULD be supported 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 the SP, the Layer 2 traffic is not necessarily
transparent. It will depend on the 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.
Kamite, et al. Expires January 14, 2010 [Page 13]
Internet-Draft VPMS Framework and Requirements July 2009
The VPMS solution SHOULD NOT require any special packet processing by
the end users (CEs).
6.3. Quality of Service (QoS)
A customer may require that the VPMS service provide 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. High Availability
A solution MUST provide protection and restoration mechanism for end-
to-end services to ensure high availability.
There are multiple parts of the connection that can support
protection and restoration: (1) CE to PE, (2) between PEs (3) inside
core (PSN backbone). It is expected that (3) is fulfilled by
existing PSN protection mechanisms (e.g., RSVP-TE FRR). Following
subsections will cover the requirements for redundancy support for
(1) and (2).
6.4.1. Dual-homed Access Support
A solution MUST allow dual-homed redundant access from a CE to
multiple PEs. This if beneficial to support reliable data delivery
for customers. Figure 3 provides an example of this access topology.
.
Kamite, et al. Expires January 14, 2010 [Page 14]
Internet-Draft VPMS Framework and Requirements July 2009
+-----+
| 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 3: Dual-homing support
A solution SHOULD provide a protection mechanism between the
redundant PEs to which a CE is dual-homed. This is because when an
ingress root PE node fails whole traffic delivery will fail unless a
backup root PE is provided, even in case of dual-homed access.
Similarly, if an egress leaf PE node fails, traffic toward that CE is
never received unless a backup leaf PE is provided.
In some cases, the data source is required to be highly reliable
since it is often deployed as a centralized server that provides
traffic to many receivers. Therefore, there is an additional
requirement specifically about redundancy of root-side: each VPMS
instance SHOULD be able to have multiple P2MP connections whose roots
are located at separate root ACs. Those root ACs can be located at
physically separate root PEs, whereas those trees will share common
leaf ACs. This means that each P2MP connection has a single root AC,
but several P2MP connections can be managed together inside a common
VPN.
Kamite, et al. Expires January 14, 2010 [Page 15]
Internet-Draft VPMS Framework and Requirements July 2009
For example, in Figure 4, traffic from root AC1 and AC2 both reach
receivers CE3 and CE4 while AC1, AC2, AC3 and AC4 all are associated
with a single VPMS instance. This topology is reliable since there
are redundant root PE/ACs. At the egress side, PE3 and PE4 select
traffic from either root, PE1 or PE2. Each leaf PE has one leaf AC
only (AC3 attached to PE3, and AC4 attached to PE4). Therefore, PEs
will need to support PW protection and restoration mechanism so that
two redundant P2MP connections are given among common ACs.
+-----+ AC2
| CE1 |>--------------------------------------------+
+-----+ |
AC1v VPMS A |
| Sender ----------------------------- |
| | VPMS A's P2MP | |
| +------+ Connection-2 +------+ |
+------->|......>.. .............+..<......|<-+
Tx | VPMS | . . . | VPMS | Tx
| PE 1 | . . . | PE 2 |
| | . . . | |
+------+ . . . +------+
| . . . |
VPMS A's P2MP +.. . ...... . |
Connection-1 . . . . |
| . . . . |
| +-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 4: Multiple P2MP connections in Dual-homed Sender
Note, if the solution supports dual-homed sender scenario by multiple
root ACs, it is expected that such a mechanism can also be used in
multi-source scenrio. For example, suppose in TV provisioning
Kamite, et al. Expires January 14, 2010 [Page 16]
Internet-Draft VPMS Framework and Requirements July 2009
scenario, a receiver CE has the fixed one interface to the leaf PE,
and the CE needs to receive many TV channel traffic from two video
servers (the two servers provide different TV channels). The two
video servers are in different location. In this case, there need
two root ACs and the same number of P2MP connections, which is
similar to dual-homed sender case.
6.4.2. Single/Dual Traffic Support in Dual-homed Access
When dual-homed access to root PEs is provided, a solution MAY allow
a sender CE to transmit just a single copy of the traffic to either
one of the two root (ingress) PEs or to transmit a copy of the
traffic to both the PEs simultaneously. The latter scenario consumes
more resource of CE-PE link than the single traffic scenario, but it
is usually applicable when a source device has only a simple
forwarding capability without any switchover functionality. In the
dual traffic case, the backup root (ingress) PE SHOULD be able to
filter the incoming unnecessary traffic while the other root PE is
active. In either case, single traffic or dual traffic, the
switchover mechanism between root (ingress) PEs will be necessary to
handle traffic appropriately in failure.
In the case of dual-homed access to leaf PEs, a solution MAY allow a
receiver CE to receive a single copy of the traffic from either one
of the two leaf (egress) PEs, or receive a copy of the traffic from
both PEs simultaneously. The dual traffic approach is applicable if
CE has fast switchover capability as a receiver by selecting either
one of incoming traffic, but note that additional traffic resources
are always consumed at PE-CE link of backup side. Specifically in
the single traffic case, it might be needed to support switchover
mechanism between egress PEs in failure.
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/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 14, 2010 [Page 17]
Internet-Draft VPMS Framework and Requirements July 2009
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 root ACs / sender CEs (per PE, VPMS instance and
total)
- the number of leaf ACs / 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 optimizing the bandwidth usage required in a SP's
network. For supporting efficient replication, it is expected to
take advantage of PW and PSN mechanisms that are capable of P2MP
traffic.
Regarding PW mechanism, [I-D.ietf-pwe3-p2mp-pw-requirements]
introduces P2MP PW concept and its requirements, showing two basic
approaches of providing replication. One is SS (Single Segment)-PW
model that provides replication by PSN tunnel such as P2MP LSP (i.e.,
Kamite, et al. Expires January 14, 2010 [Page 18]
Internet-Draft VPMS Framework and Requirements July 2009
by outer label layer), and the other is MS (Multi Segment)-PW model
that provides replication by multiple interconnected PWs (i.e., by
inner label layer). In either case, end-to-end P2MP topology (i.e.,
P2MP connection) in VPMS is common from the view of ACs.
Requirements as a provider service specified in this document will be
commonly applied regardless of P2MP PW's signaling model.
It is out of scope of this document how to extend and use PW
mechanisms to realize P2MP connections. For example, it is under the
scope of the solution work how to support forward/reverse traffic
e.g., by a single PW signaling, coupling multiple PWs, or other ways.
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 to VPMS. The actual type
of PSN tunnel used in VPMS will be dependent on individual deployment
scenarios (e.g., which PSN protocol is available in the core and how
much of the network resources that 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).
- AC role in each VPMS (Sender or Receiver)
- SP-related information (AS number, etc. for an inter-provider
case)
Following is an example scenario: by default, every PE will have the
association among the information described above. Suppose a new PE
having an AC is provisioned in the existing VPMS instance and this AC
is configured as receiver. This information will be automatically
discovered by the other existing remote PEs (i.e., ingress and egress
Kamite, et al. Expires January 14, 2010 [Page 19]
Internet-Draft VPMS Framework and Requirements July 2009
PEs in the same VPMS instance). Once the ingress PE discovers this
new PE/AC, it can automatically add it as the new leaf of P2MP
topology according to P2MP PW signaling mechanism. This operation
does not require any new configuration at the existing PEs.
Note that VPMS instance is created when one root PE and at least one
leaf PE are added. In principle VPMS requires such minimum
provisioning. Hence in dual-homing case of sender, only backup root
PE can be dynamically added/deleted to/from VPMS without destroying
the VPN.
( Editor's note: This might be under study, including auto-discovery
requirement if any when multiple roots (sender-side PEs) exist.)
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 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, AC1, AC3, AC4 and AC5 are initially
provisioned for VPMS A. AC2 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, AC4 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, AC3 is now administratively activated and receiving
traffic. However, if AC3 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 root (ingress) PE. In some scenarios, operators
prefer centralized operation. This is often considered natural for
one-way digital audio/video distribution applications: SPs often want
Kamite, et al. Expires January 14, 2010 [Page 20]
Internet-Draft VPMS Framework and Requirements July 2009
to complete their service delivery by a single operation at one
source PE, not by multiple operations at many leaf (egress) 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.
+-----+ AC1
+ CE1 +----------------+
+-----+ |
VPMS A Sender |
(sending now) v
+----+
-----|VPMS|--------
| | PE1| |
| +----+ |
+----+ +----+
|VPMS| |VPMS|
| PE2| Routed | PE3|
AC2 +----+ Backbone +----+ AC3
(not provisioned) / | | \
+-----+ / | | \ +-----+
+ CE2 +<-+ | | +->| CE3 |
+-----+ | +----+ | +-----+
(not receiving) ----|VPMS|--------- VPMS A Receiver
| PE4| (receiving now)
+----+
AC5 / \ AC4
+-----+ / \ +-----+
+ CE5 +<----------+ +---------------->| CE4 |
+-----+ +-----+
VPMS A Receiver VPMS A Receiver
(receiving now) (not receiving)
AC1: Administratively activated
AC2: No VPMS provisioned
AC3: Administratively activated
AC4: Administratively deactivated
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
Kamite, et al. Expires January 14, 2010 [Page 21]
Internet-Draft VPMS Framework and Requirements July 2009
PEs that compose one VPMS belong to several different ASes.
7.6. Co-existence with Existing L2VPNs
A solution MUST co-exist with the existing L2VPNs (e.g., VPWS, VPLS)
across the same SP's network. A solution MUST NOT impede the
operation of auto-discovery and signaling mechanism that are already
supported by the PEs for those existing L2VPNs.
7.7. Operation, Administration and Maintenance
7.7.1. Fault Management
7.7.1.1. Fault Detection
A solution MUST provide tools that detect reachability failure and
traffic looping of data transport in a VPMS instance. If multiple
root ACs are supported (i.e., multiple P2MP connections are grouped
together into a single VPMS instance), such tools MUST be able to
perform distinguishing each P2MP connection.
7.7.1.2. Fault Notification
A solution MUST provide fault notification and trouble tracking
mechanisms. (e.g. SNMP-trap and syslog that notify fault to remote
NMS.)
In VPMS one point of failure at upstream often affects a number of
downstream PEs and ACs that might raise a notification message.
Hence notification messages MAY be summarized or compressed for
operators' ease of management.
In case of receiver-side failure (leaf PE or its AC), this fault
status SHOULD be able to be monitored at root PE. This will help an
operator to monitor each leaf PE/AC in a centralized manner; that is,
a root PE can collect leaf-side information. How this status is
transferred depends on a solution.
In contrast, in case of sender-side failure (root PE or its AC), this
fault status SHOULD also be able to be monitored at leaf PEs. This
will help an operator to troubleshoot at leaf PEs (i.e., distinguish
local AC's failure from remote root AC's failure easily).
In any case of failure at SP's network, fault information MAY be
notified to the customer. Specifically, such fault MAY trigger
generating customer OAM message toward CEs (e.g., AIS) and/or
shutting down leaf ACs.
Kamite, et al. Expires January 14, 2010 [Page 22]
Internet-Draft VPMS Framework and Requirements July 2009
7.7.1.3. Fault Isolation
A solution MUST provide diagnostic/troubleshooting tools for data
transport in a VPMS instance.
7.7.2. Testing
A solution MUST provide a mechanism for testing each data
connectivity and verifying the associated information in a VPMS
instance. The connectivity is between a root and all leaf ACs (i.e.,
each P2MP connection can be tested).
Operators will run testing before and after service activation.
Testing mechanism SHOULD support end-to-end testing of the data path
used by customer's data. End-to-end testing 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. In either case the minimum
data path unit for each VPMS is unidirectional, hence if loopback
testing is supported, additional consideration about reverse-path
might also be needed (see section 6.1.3).
If there are multiple P2MP connections for redundancy (active/backup
tree) in a common VPMS (like in Figure 4), testing mechanism MUST be
able to check the connectivity over not only working P2MP connection
but also protecting connection(s). This testing MUST be able to be
performed from a root PE. It MAY also be able to be performed from a
sender CE.
7.7.3. Performance Management
A solution MUST offer mechanisms to monitor traffic performance
parameters and statistics of data traffic in VPMS.
A solution MUST provide access to:
- Traffic statistics (total traffic forwarded, incoming, outgoing,
dropped, etc., by period of time)
A solution SHOULD provide access to:
- Performance information related to traffic usage, e.g., one-way
delay, one-way jitter, one-way loss, delay variations (the
difference of various one-way delay from a particular root PE to
multiple leaf PEs) etc.
All or part of this information SHOULD be made available through
standardized SNMP MIB Modules (Management Information Base).
Kamite, et al. Expires January 14, 2010 [Page 23]
Internet-Draft VPMS Framework and Requirements July 2009
It is expected that such information can be used for SLA monitoring
between sender and receiver, to give the SP a clear picture of
current service providing to the customer.
7.8. Security
TBD (for further study for next revision)
8. Security Considerations
Security consideration will be covered by section 6.5. and section
7.8. (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 ideas and feedback in documentation.
The authors gratefully acknowledge the valuable review and comments
provided by Greg Mirsky and Yuji Tochio.
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.ietf-pwe3-p2mp-pw-requirements]
JOUNAY, F., Niger, P., Kamite, Y., DeLord, S., and L.
Kamite, et al. Expires January 14, 2010 [Page 24]
Internet-Draft VPMS Framework and Requirements July 2009
Martini, "Requirements for Point-to-Multipoint
Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-00 (work
in progress), September 2008.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006.
[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
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Email: y.kamite@ntt.com
Frederic Jounay
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
Email: frederic.jounay@orange-ftgroup.com
Kamite, et al. Expires January 14, 2010 [Page 25]
Internet-Draft VPMS Framework and Requirements July 2009
Ben Niven-Jenkins
BT
208 Callisto House, Adastral Park
Ipswich, IP5 3RE
UK
Email: benjamin.niven-jenkins@bt.com
Deborah Brungard
AT&T
Rm. D1-3C22, 200 S. Laurel Ave.
Middletown, NJ, 07748
USA
Email: dbrungard@att.com
Lizhong Jin
Nokia Siemens Networks
Building 89, 1122 North QinZhou Road,
Shanghai, 200211
P.R.China
Email: lizhong.jin@nsn.com
Kamite, et al. Expires January 14, 2010 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-21 11:38:50 |