draft-ietf-l2vpn-vpms-frmwk-requirements-01.txt   draft-ietf-l2vpn-vpms-frmwk-requirements-02.txt 
Network Working Group Y. Kamite Network Working Group Y. Kamite
Internet-Draft NTT Communications Internet-Draft NTT Communications
Intended status: Informational F. Jounay Intended status: Informational F. Jounay
Expires: January 14, 2010 France Telecom Expires: April 29, 2010 France Telecom
B. Niven-Jenkins B. Niven-Jenkins
BT BT
D. Brungard D. Brungard
AT&T AT&T
L. Jin L. Jin
Nokia Siemens Networks Nokia Siemens Networks
July 13, 2009 Oct 26, 2009
Framework and Requirements for Virtual Private Multicast Service (VPMS) Framework and Requirements for Virtual Private Multicast Service (VPMS)
draft-ietf-l2vpn-vpms-frmwk-requirements-01.txt draft-ietf-l2vpn-vpms-frmwk-requirements-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 15 skipping to change at page 2, line 26
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope of This Document . . . . . . . . . . . . . . . . . . 4 1.2. Scope of This Document . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Ethernet Use Case . . . . . . . . . . . . . . . . . . . . 6 4.1. Ethernet Use Case . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Ethernet-based multicast stream . . . . . . . . . . . 6
4.1.2. Ethernet-based time/frequency synchronization . . . . 7
4.2. ATM-based Use Case . . . . . . . . . . . . . . . . . . . . 7 4.2. ATM-based Use Case . . . . . . . . . . . . . . . . . . . . 7
4.3. TDM-based Use Case . . . . . . . . . . . . . . . . . . . . 7 4.2.1. ATM-based multicast stream . . . . . . . . . . . . . . 7
4.3. TDM-based Use Case . . . . . . . . . . . . . . . . . . . . 8
4.3.1. TDM-based multicast stream . . . . . . . . . . . . . . 8
5. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 8 5. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 8
6. Customer Requirements . . . . . . . . . . . . . . . . . . . . 11 6. Customer Requirements . . . . . . . . . . . . . . . . . . . . 10
6.1. Service Topology . . . . . . . . . . . . . . . . . . . . . 11 6.1. Service Topology . . . . . . . . . . . . . . . . . . . . . 10
6.1.1. Point-to-Multipoint Traffic Support . . . . . . . . . 11 6.1.1. Point-to-Multipoint Traffic Support . . . . . . . . . 10
6.1.2. Reverse Traffic Support . . . . . . . . . . . . . . . 11 6.1.2. Reverse Traffic Support . . . . . . . . . . . . . . . 10
6.2. Transparency . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Transparency . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . . 14 6.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . . 13
6.4. High Availability . . . . . . . . . . . . . . . . . . . . 14 6.4. High Availability . . . . . . . . . . . . . . . . . . . . 13
6.4.1. Dual-homed Access Support . . . . . . . . . . . . . . 14 6.4.1. Dual-homed Access Support . . . . . . . . . . . . . . 13
6.4.2. Single/Dual Traffic Support in Dual-homed Access . . . 17 6.4.2. Single/Dual Traffic Support in Dual-homed Access . . . 16
6.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.6. Reordering Prevention . . . . . . . . . . . . . . . . . . 17 6.6. Reordering Prevention . . . . . . . . . . . . . . . . . . 17
6.7. Failure reporting . . . . . . . . . . . . . . . . . . . . 18 6.7. Failure reporting . . . . . . . . . . . . . . . . . . . . 17
7. Service Provider Network Requirements . . . . . . . . . . . . 18 7. Service Provider Network Requirements . . . . . . . . . . . . 17
7.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Pseudo Wire Signaling and PSN Tunneling . . . . . . . . . 18 7.2. Pseudo Wire Signaling and PSN Tunneling . . . . . . . . . 17
7.3. Discovering VPMS Related Information . . . . . . . . . . . 19 7.3. Auto-discovery . . . . . . . . . . . . . . . . . . . . . . 18
7.4. Activation and Deactivation . . . . . . . . . . . . . . . 20 7.4. Activation and Deactivation . . . . . . . . . . . . . . . 19
7.5. Inter-AS Support . . . . . . . . . . . . . . . . . . . . . 21 7.5. Inter-AS Support . . . . . . . . . . . . . . . . . . . . . 21
7.6. Co-existence with Existing L2VPNs . . . . . . . . . . . . 22 7.6. Co-existence with Existing L2VPNs . . . . . . . . . . . . 21
7.7. Operation, Administration and Maintenance . . . . . . . . 22 7.7. Operation, Administration and Maintenance . . . . . . . . 22
7.7.1. Fault Management . . . . . . . . . . . . . . . . . . . 22 7.7.1. Fault Management . . . . . . . . . . . . . . . . . . . 22
7.7.2. Testing . . . . . . . . . . . . . . . . . . . . . . . 23 7.7.2. Testing . . . . . . . . . . . . . . . . . . . . . . . 22
7.7.3. Performance Management . . . . . . . . . . . . . . . . 23 7.7.3. Performance Management . . . . . . . . . . . . . . . . 23
7.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
1.1. Problem Statement 1.1. Problem Statement
[RFC4664] describes different types of Provider Provisioned Layer 2 [RFC4664] describes different types of Provider Provisioned Layer 2
VPNs (L2 PPVPNs, or L2VPNs). Some of them are widely deployed today, VPNs (L2 PPVPNs, or L2VPNs). Some of them are widely deployed today,
such as Virtual Private Wire Service (VPWS) and Virtual Private LAN 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) Service (VPLS). A VPWS is a VPN service that supplies a Layer 2 (L2)
skipping to change at page 6, line 13 skipping to change at page 6, line 13
communication. communication.
P2MP connection: A logical entity between PE/ACs in a given VPMS P2MP connection: A logical entity between PE/ACs in a given VPMS
instance that transfers unidirectional traffic transparently from instance that transfers unidirectional traffic transparently from
one local ingress AC to one or more remote egress ACs. one local ingress AC to one or more remote egress ACs.
4. Use Cases 4. Use Cases
4.1. Ethernet Use Case 4.1. Ethernet Use Case
4.1.1. Ethernet-based multicast stream
For multicast traffic delivery, there is a requirement to deliver a For multicast traffic delivery, there is a requirement to deliver a
unidirectional P2MP service in addition to the existing P2P service. unidirectional P2MP service in addition to the existing P2P service.
The demand is growing to provide private (P2MP native Ethernet) The demand is growing to provide private (P2MP native Ethernet)
services, for various applications such as IP- based delivery of TV services, for various applications such as IP- based delivery of TV
broadcasting, content delivery networks, etc. Moreover, many digital broadcasting, content delivery networks, etc. Moreover, many digital
audio/video devices (e.g., MPEG-TS, HD-SDI) that supports Ethernet audio/video devices (e.g., MPEG-TS, HD-SDI) that supports Ethernet
interfaces are becoming available, which will make Ethernet P2MP interfaces are becoming available, which will make Ethernet P2MP
service more common. Also there are some applications that naturally service more common. Also there are some applications that naturally
suited to static transport of VPMS. For example, MPEG-TS/IP/ suited to static transport of VPMS. For example, MPEG-TS/IP/
Ethernet in DVB-H is typically static broadcast without any signaling Ethernet in DVB-H is typically static broadcast without any signaling
skipping to change at page 7, line 5 skipping to change at page 7, line 6
Note that VPMS provides single coverage of receiver membership; that Note that VPMS provides single coverage of receiver membership; that
is, there is no distinct differentiation for multiple multicast is, there is no distinct differentiation for multiple multicast
groups. All traffic from a particular Attachment Circuit (AC) will groups. All traffic from a particular Attachment Circuit (AC) will
be forwarded toward the same remote receivers, even if the be forwarded toward the same remote receivers, even if the
destination MAC address is changed. Basically in VPMS, destination destination MAC address is changed. Basically in VPMS, destination
MAC addresses are not used for forwarding, which is significantly MAC addresses are not used for forwarding, which is significantly
different from VPLS. If MAC-based forwarding is preferred (i.e., different from VPLS. If MAC-based forwarding is preferred (i.e.,
multicast/unicast differentiation of MAC address), VPLS should be multicast/unicast differentiation of MAC address), VPLS should be
chosen rather than VPMS. chosen rather than VPMS.
4.1.2. Ethernet-based time/frequency synchronization
Nowadays there exist several solutions to provide synchronization for
time and/or frequency reference by the packet-based technology of
Ethernet. For example, PTPv2 (Precision Time Protocol version 2) is
a time-transfer protocol defined in the IEEEE1588-2008 standard. It
provides precise synchronization of packet-based networks (e.g.,
Ethernet). It adopts two-way time transfer approach for
synchronization. Time transfer protocol may be operated in multicast
or unicast mode in both directions, and it is mapped over the
Ethernet/IP/UDP protocol stack.
Moreover, PTPv2 telecom profile is now discussed in ITU-T that
defines a set of capabilities and extensions required to support
telecommunication applications. It aims at providing frequency
distribution with higher level of accuracy. It allows unicast mode
or the mix of unicast/multicast modes for the transmission of the PTP
messages.
In this aspect, VPMS might be considered as a potential packet-based
infrastructure to deliver multicast messages in PTPv2 with efficient
forwarding. Note, however, in PTPv2 telecom profile, multicast
transport may not always be supported in all the parts of a telecom
network because multicast might sometimes generate additional PDV
(packet delay variation) compared to unicast. Therefore, VPMS use
case and the corresponding solution for this purpose will need more
study in the future (e.g., PDV issue to be checked).
4.2. ATM-based Use Case 4.2. ATM-based Use Case
4.2.1. ATM-based multicast stream
A use case of ATM-based service in VPMS could be to offer the A use case of ATM-based service in VPMS could be to offer the
capability for service providers to support IP multicast wholesale capability for service providers to support IP multicast wholesale
services over ATM in case the wholesale customer relies on ATM services over ATM in case the wholesale customer relies on ATM
infrastructure. The P2MP support alleviates the constraint in terms infrastructure. The P2MP support alleviates the constraint in terms
of replication for ATM to support IP multicast services. of replication for ATM to support IP multicast services.
Another use case of VPMS for ATM is for audio/video stream Another use case of VPMS for ATM is for audio/video stream
applications. Today many digital TV broadcasting networks adopt ATM- applications. Today many digital TV broadcasting networks adopt ATM-
based distribution systems with point-to-multipoint PVPs/PVCs. The based distribution systems with point-to-multipoint PVPs/PVCs. The
transport network supports replicating ATM cells in transit nodes to transport network supports replicating ATM cells in transit nodes to
efficiently deliver programs to multiple terminals. For migrating efficiently deliver programs to multiple terminals. For migrating
such ATM-based networks onto IP/MPLS-based networks, VPMS is such ATM-based networks onto IP/MPLS-based networks, VPMS is
considered to be a candidate solution. considered to be a candidate solution.
4.3. TDM-based Use Case 4.3. TDM-based Use Case
4.3.1. TDM-based multicast stream
Today the existing VPWS already supports TDM emulation services Today the existing VPWS already supports TDM emulation services
(SAToP, CESoPSN or TDMoIP). It is a Layer 1 service, not Layer 2 (SAToP, CESoPSN or TDMoIP). It is a Layer 1 service, not Layer 2
service; however, a common architecture is being used since they are service; however, a common architecture is being used since they are
all packet-based emulations over a SP's network. VPMS is also all packet-based emulations over a SP's network. VPMS is also
considered to be a solution for such TDM applications that require considered to be a solution for such TDM applications that require
point-to-multipoint topology. point-to-multipoint topology.
One use case is TDM-based multicast video delivery. That is, data One use case is TDM-based multicast stream delivery, like video
duplication is simply provided by Layer 1, without using upper delivery. That is, data duplication is simply provided by Layer 1,
layer's multicast protocols. 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
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 5. Reference Model
The VPMS reference model is shown in Figure 1. The VPMS reference model is shown in Figure 1.
+-----+ AC1 AC2 +-----+ +-----+ AC1 AC2 +-----+
| CE1 |>---+ ------------------------ +--->| CE2 | | CE1 |>---+ ------------------------ +--->| CE2 |
+-----+ | | VPMS A's P2MP | | +-----+ +-----+ | | VPMS A's P2MP | | +-----+
VPMS A | +------+ Connection +------+ | VPMS A VPMS A | +------+ Connection +------+ | VPMS A
Sender +->|......>...+.......... >......|>-+ Receiver Sender +->|......>...+.......... >......|>-+ Receiver
skipping to change at page 10, line 26 skipping to change at page 9, line 48
called a leaf (receiver) CE. However, such CEs's roles will not be 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 managed directly in VPMS because the configured AC's role (root or
leaf) will automatically determine them. leaf) will automatically determine them.
Similarly, a PE which locally accommodates a root AC is called a root 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 (sender) PE. A PE which locally accommodates a leaf AC is called a
leaf (receiver) PE. leaf (receiver) PE.
Basically there is a one-to-one mapping between an attachment circuit Basically there is a one-to-one mapping between an attachment circuit
and a VPMS instance. For example, all traffic from CE1 to PE1 and a VPMS instance. For example, all traffic from CE1 to PE1
(thorough AC1) is mapped to VPMS A (to CE2 and CE5). (through AC1) is mapped to VPMS A (to CE2 and CE5).
In a VPMS, P2MP tree-shaped reachability is given from a single root 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 AC to several leaf ACs. This will be named a "P2MP connection" in
this VPMS framework. P2MP connection is a logical entity between PE/ this VPMS framework. P2MP connection is a logical entity between PE/
ACs in a given VPMS instance that transfers unidirectional traffic ACs in a given VPMS instance that transfers unidirectional traffic
transparently from one local ingress AC to one or more remote egress transparently from one local ingress AC to one or more remote egress
ACs. ACs.
Similar to other L2VPN mechanisms, the VPMS architecture is based on 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 PWs which may be using through IP or MPLS-enabled PSN tunnels over a
skipping to change at page 11, line 22 skipping to change at page 10, line 44
A solution MUST support unidirectional point-to-multipoint traffic A solution MUST support unidirectional point-to-multipoint traffic
from a sender CE to multiple receiver CEs. A root CE can send 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 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 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 connected to the same root PE. If there is only one receiver in the
instance, it is considered equivalent to unidirectional point-to- instance, it is considered equivalent to unidirectional point-to-
point traffic. point traffic.
6.1.2. Reverse Traffic Support 6.1.2. Reverse Traffic Support
There are cases where a reverse traffic flow is needed. A sender CE There are cases where a reverse traffic flow is needed. A root CE
may need to receive traffic from receiver CEs. There are some usage may need to receive traffic from leaf CEs. There are some usage
scenarios for this, such as stream monitoring through a loopback scenarios for this, such as stream monitoring through a loopback
mechanism, control channels which need feedback communication etc. A mechanism, control channels which need feedback communication etc. A
possible way to accomplish this is to provide different VPMS possible way to accomplish this is to provide different VPMS
instances for reverse traffic, i.e. a sender CE is a receiver of instances for reverse traffic, i.e. a root CE is a receiver of
another VPMS instance. However, provisioning different VPNs for a another VPMS instance. However, provisioning different VPNs for a
particular customer would make its management task more complex. It particular customer would make its management task more complex. It
is desired to have an alternative solution for supporting reverse is desired to have an alternative solution for supporting reverse
traffic flow. This section provides additional requirements for this traffic flow. This section provides additional requirements for this
optional capability. optional capability.
A VPMS solution MAY support reverse traffic from a leaf AC to a root 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. 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 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 traffic to the root. For this purpose a VPMS instance MAY have more
than one reverse P2P connections as network entity; However, such than one reverse P2P connections as network entity; However, such
network entities MUST have a common field that enables themselves to network entities MUST have a common indetifier that enables
be managed together in the same VPN. Any PWs used for such themselves to be managed together in the same VPN. Thus any PWs used
connections are expected to be assigned a common VPMS instance ID. for such connections are expected to be assigned a common VPMS
instance ID (i.e., VPN ID).
Note, a VPMS does not assume any-to-any multipoint reachability. Note, a VPMS does not assume any-to-any multipoint reachability.
Therefore, in principle, every leaf AC does not exchange traffic Therefore, in principle, every leaf AC does not exchange traffic
directly with other leaf ACs even if reverse traffic is supported. directly with other leaf ACs even if reverse traffic is supported.
Figure 3 illustrates this kind of scenario, where CE1 is configured 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 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 ACs. P2MP connection is given for forward traffic. Unidirectional
P2P connection is also provided for reverse traffic from AC4 to AC1. P2P connection is also provided for reverse traffic from AC4 to AC1.
Other reverse P2P connections can be provided similarly. (from AC2 to Other reverse P2P connections can be provided similarly. (from AC2 to
AC1 / from AC3 to AC1). AC1 / from AC3 to AC1).
In this case, PEs need to deal with two types of traffic, locally- 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, 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 they are both passing through the same physical PE-CE link (AC1 and
an implementation matter if Tx and Rx traffic are conveyed on the AC4 respectively). But it is an implementation matter if Tx and Rx
same physical link or separate links. It is also possible that a traffic are conveyed on the same physical link or separate links. It
root PE multiplexes two ore more reverse traffic from different is also possible that a root PE multiplexes two ore more reverse
leaves and transmits it to an upstream CE over the same local link. traffic from different leaves and transmits it to an upstream CE over
the same local physical link.
Note, in most implementations of VPWS today, every AC is always Note, in most implementations of VPWS today, every AC is always
considered bidirectional. In contrast, in VPMS, every AC can be considered bidirectional. In contrast, in VPMS, every AC can be
chosen unidirectional (if it is a totally unidirectional service), or chosen unidirectional (if it is a totally unidirectional service), or
bidirectional (if reverse traffic is supported). bidirectional (if reverse traffic is supported).
+-----+ <-- Rx (bidirectional) +-----+ <-- Rx (bidirectional)
| CE1 |--------------+ | CE1 |--------------+
+-----+ --> Tx | +-----+ --> Tx |
VPMS A Sender | VPMS A Sender |
skipping to change at page 13, line 45 skipping to change at page 12, line 45
(bidirectional) --> Rx +-----+ (bidirectional) --> Rx +-----+
VPMS A VPMS A
Receiver Receiver
Figure 3: Reverse traffic support Figure 3: Reverse traffic support
6.2. Transparency 6.2. Transparency
A solution is intended to provide Layer-2 traffic transparency. A solution is intended to provide Layer-2 traffic transparency.
Transparency SHOULD be supported per VPMS instance basis. In other Transparency SHOULD be supported per VPMS instance basis. In other
words, Layer 2 traffic can be transparently transported from a sender words, Layer-2 traffic can be transparently transported from a local
CE to receiver CEs in a given instance. Note, however, if service CE to remote CEs in a given instance. Note, however, if service
delimiting fields (VLAN Id in Ethernet, VPI/VCI in ATM, DLCI in FR 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 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 transparent. It will depend on the SP's choice if they assign it to
at each AC. Hence, it could be that some of receiver CEs are getting each AC. Hence, it could be that some of the leaf CEs are receiving
traffic with different delimiting fields than the other receiver CEs. traffic that has different delimiting fields than the traffic for the
other leaf CEs. Hence, it could be that some of receiver CEs are
getting traffic with different delimiting fields than the other
receiver CEs.
The VPMS solution SHOULD NOT require any special packet processing by The VPMS solution SHOULD NOT require any special packet processing by
the end users (CEs). the end users (CEs).
6.3. Quality of Service (QoS) 6.3. Quality of Service (QoS)
A customer may require that the VPMS service provide guaranteed QoS. A customer may require that the VPMS service provide guaranteed QoS.
In particular, for real time applications which are considered common In particular, for real time applications which are considered common
in point-to-multipoint delivery, delay and loss sensitive traffic in point-to-multipoint delivery, delay and loss sensitive traffic
MUST be supported. The solution SHOULD provide native QoS techniques MUST be supported. The solution SHOULD provide native QoS techniques
skipping to change at page 14, line 30 skipping to change at page 13, line 33
6.4. High Availability 6.4. High Availability
A solution MUST provide protection and restoration mechanism for end- A solution MUST provide protection and restoration mechanism for end-
to-end services to ensure high availability. to-end services to ensure high availability.
There are multiple parts of the connection that can support There are multiple parts of the connection that can support
protection and restoration: (1) CE to PE, (2) between PEs (3) inside protection and restoration: (1) CE to PE, (2) between PEs (3) inside
core (PSN backbone). It is expected that (3) is fulfilled by core (PSN backbone). It is expected that (3) is fulfilled by
existing PSN protection mechanisms (e.g., RSVP-TE FRR). Following existing PSN protection mechanisms (e.g., RSVP-TE FRR). Following
subsections will cover the requirements for redundancy support for subsections covers the requirements for redundancy support for (1)
(1) and (2). and (2).
6.4.1. Dual-homed Access Support 6.4.1. Dual-homed Access Support
A solution MUST allow dual-homed redundant access from a CE to A solution MUST allow dual-homed redundant access from a CE to
multiple PEs. This if beneficial to support reliable data delivery multiple PEs. This if beneficial to support reliable data delivery
for customers. Figure 3 provides an example of this access topology. for customers. Figure 3 provides an example of this access topology.
.
+-----+ +-----+
| CE1 |--------------+ | CE1 |--------------+
+-----+ \ +-----+ \
VPMS A | | VPMS A | |
Sender | v AC1 Sender | v AC1
(dual-homed)| +----+ (dual-homed)| +----+
| -----|VPMS|-------- | -----|VPMS|--------
| | | PE1| | | | | PE1| |
\ | +----+ | \ | +----+ |
skipping to change at page 16, line 9 skipping to change at page 15, line 9
are located at separate root ACs. Those root ACs can be located at are located at separate root ACs. Those root ACs can be located at
physically separate root PEs, whereas those trees will share common physically separate root PEs, whereas those trees will share common
leaf ACs. This means that each P2MP connection has a single root AC, leaf ACs. This means that each P2MP connection has a single root AC,
but several P2MP connections can be managed together inside a common but several P2MP connections can be managed together inside a common
VPN. VPN.
For example, in Figure 4, traffic from root AC1 and AC2 both reach 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 receivers CE3 and CE4 while AC1, AC2, AC3 and AC4 all are associated
with a single VPMS instance. This topology is reliable since there with a single VPMS instance. This topology is reliable since there
are redundant root PE/ACs. At the egress side, PE3 and PE4 select 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 traffic from either root, PE1 or PE2. In this figure, each leaf PE
only (AC3 attached to PE3, and AC4 attached to PE4). Therefore, PEs has one leaf AC only (AC3 attached to PE3, and AC4 attached to PE4).
will need to support PW protection and restoration mechanism so that Therefore, PEs will need to support PW protection and restoration
two redundant P2MP connections are given among common ACs. mechanism so that two redundant P2MP connections are given among
common ACs.
+-----+ AC2 +-----+ AC2
| CE1 |>--------------------------------------------+ | CE1 |>--------------------------------------------+
+-----+ | +-----+ |
AC1v VPMS A | AC1v VPMS A |
| Sender ----------------------------- | | Sender ----------------------------- |
| | VPMS A's P2MP | | | | VPMS A's P2MP | |
| +------+ Connection-2 +------+ | | +------+ Connection-2 +------+ |
+------->|......>.. .............+..<......|<-+ +------->|......>.. .............+..<......|<-+
Tx | VPMS | . . . | VPMS | Tx Tx | VPMS | . . . | VPMS | Tx
skipping to change at page 16, line 46 skipping to change at page 15, line 47
AC3| |AC4 AC3| |AC4
v v v v
+-----+ +-----+ +-----+ +-----+
| CE3 | | CE4 | | CE3 | | CE4 |
+-----+ +-----+ +-----+ +-----+
VPMS A VPMS A VPMS A VPMS A
Receiver Receiver Receiver Receiver
Figure 4: Multiple P2MP connections in Dual-homed Sender Figure 4: Multiple P2MP connections in Dual-homed Sender
Note, if the solution supports dual-homed sender scenario by multiple Note, if the solution supports dual-homed sender scenario to provide
root ACs, it is expected that such a mechanism can also be used in multiple root ACs like, it is expected that such a mechanism can also
multi-source scenrio. For example, suppose in TV provisioning be used in multi-source scenrio. For example, suppose in TV
scenario, a receiver CE has the fixed one interface to the leaf PE, provisioning scenario, a leaf (receiver) CE has the fixed one
and the CE needs to receive many TV channel traffic from two video interface to the leaf PE, and the CE needs to receive many TV channel
servers (the two servers provide different TV channels). The two traffic from two video servers (the two servers provide different TV
video servers are in different location. In this case, there need channels). The two video servers are in different location. In this
two root ACs and the same number of P2MP connections, which is case, there need two root ACs and the same number of P2MP
similar to dual-homed sender case. connections, which is similar to dual-homed sender case. If the root
CE shown in Figure 4 is given physically separated, such a topology
is equivalent to this multi-source scenario.
6.4.2. Single/Dual Traffic Support in Dual-homed Access 6.4.2. Single/Dual Traffic Support in Dual-homed Access
When dual-homed access to root PEs is provided, a solution MAY allow 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 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 one of the two root (ingress) PEs or to transmit a copy of the
traffic to both the PEs simultaneously. The latter scenario consumes traffic to both the PEs simultaneously. The latter scenario consumes
more resource of CE-PE link than the single traffic scenario, but it more resource of CE-PE link than the single traffic scenario, but it
is usually applicable when a source device has only a simple is usually applicable when a source device has only a simple
forwarding capability without any switchover functionality. In the forwarding capability without any switchover functionality. In the
dual traffic case, the backup root (ingress) PE SHOULD be able to dual traffic case, the backup root (ingress) PE SHOULD be able to
filter the incoming unnecessary traffic while the other root PE is filter the incoming unnecessary traffic while the other root PE is
active. In either case, single traffic or dual traffic, the active if it is needed by SP. In either case, single traffic or dual
switchover mechanism between root (ingress) PEs will be necessary to traffic, the switchover mechanism between root (ingress) PEs will be
handle traffic appropriately in failure. necessary to handle traffic appropriately in case of failure.
In the case of dual-homed access to leaf PEs, a solution MAY allow a 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 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 of the two leaf (egress) PEs, or receive a copy of the traffic from
both PEs simultaneously. The dual traffic approach is applicable if both PEs simultaneously. The dual traffic approach is applicable if
CE has fast switchover capability as a receiver by selecting either CE has fast switchover capability as a receiver by selecting either
one of incoming traffic, but note that additional traffic resources one of incoming traffic, but note that additional traffic resources
are always consumed at PE-CE link of backup side. Specifically in are always consumed at PE-CE link of backup side. Specifically in
the single traffic case, it might be needed to support switchover the single traffic case, it might be needed to support switchover
mechanism between egress PEs in failure. mechanism between egress PEs in case of failure.
6.5. Security 6.5. Security
The basic security requirement raised in Section 6.5 of [RFC4665] The basic security requirements from the view of customers are raised
also applies to VPMS. in section 6.5 of [RFC4665]. It also applies to VPMS.
In addition, a VPMS solution MAY have the mechanisms to activate the In addition, a VPMS solution MAY have the mechanisms to activate the
appropriate filtering capabilities (for example, MAC/VLAN filtering appropriate filtering capabilities (for example, MAC/VLAN filtering
etc.), and it MAY be added with the filtering control mechanism etc.), and it MAY be added with the control mechanism between
between particular sender/receiver sites inside a VPMS instance. For particular sender/receiver sites inside a VPMS instance. For
example, in Figure 1, filtering can be added such that traffic from 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. CE1 to CE4/CE5 is allowed but traffic from CE1 to CE6 is filtered.
6.6. Reordering Prevention 6.6. Reordering Prevention
A solution SHOULD prevent Layer 2 frame reordering when delivering A solution SHOULD prevent Layer-2 frame reordering when delivering
customer traffic under normal conditions. customer traffic under normal conditions.
6.7. Failure reporting 6.7. Failure reporting
A solution MAY provide information to the customer about failures. A solution MAY provide information to the customer about failures.
For example, if there is a loss of connectivity toward some of the For example, if there is a loss of connectivity toward some of the
receiver CEs, it is reported to the sender CE. receiver CEs, it is reported to the sender CE.
7. Service Provider Network Requirements 7. Service Provider Network Requirements
skipping to change at page 19, line 18 skipping to change at page 18, line 23
Requirements as a provider service specified in this document will be Requirements as a provider service specified in this document will be
commonly applied regardless of P2MP PW's signaling model. commonly applied regardless of P2MP PW's signaling model.
It is out of scope of this document how to extend and use PW 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 mechanisms to realize P2MP connections. For example, it is under the
scope of the solution work how to support forward/reverse traffic scope of the solution work how to support forward/reverse traffic
e.g., by a single PW signaling, coupling multiple PWs, or other ways. e.g., by a single PW signaling, coupling multiple PWs, or other ways.
This document does not raise any specific requirements for particular This document does not raise any specific requirements for particular
PSN tunneling schemes (point-to-point, point-to-multipoint and PSN tunneling schemes (point-to-point, point-to-multipoint and
multipoint-to-multipoint) that is applied to VPMS. The actual type multipoint-to-multipoint) that are applied to VPMS. The actual type
of PSN tunnel used in VPMS will be dependent on individual deployment 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 scenarios (e.g., which PSN protocol is available in the core and how
much of the network resources that operators will want to optimize). much of the network resources that operators will want to optimize).
7.3. Discovering VPMS Related Information 7.3. Auto-discovery
A solution SHOULD support auto-discovery methods that dynamically A solution SHOULD support auto-discovery methods that dynamically
allow VPMS information to be discovered by the PEs to minimize the allow VPMS related information to be discovered by the PEs to
amount of configuration the SP must perform. minimize the amount of configuration the SP must perform.
All of the requirements on discovery described in Section 7.3 of All of the requirements on discovery described in Section 7.3 of
[RFC4665] SHOULD be satisfied in VPMS as well. [RFC4665] SHOULD be satisfied in VPMS as well.
Auto-discovery will help operators' initial configuration of adding a Auto-discovery will help operators' initial configuration of adding a
new VPN (i.e., VPMS instance), adding/deleting new sender/receiver, new VPN (i.e., VPMS instance), adding/deleting new sender/receiver,
and so on. and so on.
The information related to remote sites will be as follows: The candidate information treated in auto-discovery will be as
follows:
- Information to identify the VPMS instance - Information to indentify the location of each PE, e.g., PE router
- PE router ID / IP address as location information ID / IP address
- Information to identify Attachment Circuits and their associated - Information to identify the VPMS instance, that is, to identify a
group information to compose a unique service (i.e., VPMS VPN
instance). - Information to identify the type of ACs (root AC or leaf AC)
- AC role in each VPMS (Sender or Receiver) - Information to identify the P2MP connection that binds ACs
- Information to show if reverse traffic support is optionally
desired
- SP-related information (AS number, etc. for an inter-provider - SP-related information (AS number, etc. for an inter-provider
case) case)
Following is an example scenario: by default, every PE will have the Following is an example scenario about adding a new leaf PE: suppose
association among the information described above. Suppose a new PE there are three PEs in an existing VPMS, PE1, PE2, PE3. PE1 is a
having an AC is provisioned in the existing VPMS instance and this AC root PE and has a AC1. PE2 and PE3 are leaves and have AC2 and AC3.
is configured as receiver. This information will be automatically every PE has the association among the information described above.
discovered by the other existing remote PEs (i.e., ingress and egress Now a new PE4 having an AC4 is provisioned in the existing VPMS
PEs in the same VPMS instance). Once the ingress PE discovers this instance and this AC is configured as leaf. This information will be
new PE/AC, it can automatically add it as the new leaf of P2MP automatically discovered by the other existing remote PEs (i.e.,
topology according to P2MP PW signaling mechanism. This operation ingress and egress PEs in the same VPMS instance). Once the ingress
does not require any new configuration at the existing PEs. PE1 discovers this new PE/AC, it can automatically add AC4 as the new
leaf of P2MP connection topology according to P2MP PW signaling
mechanism. The ingress PE1 will graft a new leaf (PE4) to the
already existing P2MP connection which is now created from AC1 to
AC2/AC3/AC4. This operation does not require any new configuration
at the existing PEs.
Another example is about adding new root PE: suppose there are one
root PE (PE1/AC1) and three leaf PEs (PE2/AC2, PE3/AC3 and PE4/AC4).
There is an existing P2MP connection from AC1 to AC2/AC3/AC4. Now
the operator adds a new root PE/AC (PE5/AC5) for some reasons (e.g.,
multiple source sites, dual-homed access, root PE redundancy etc.).
Then, auto-discovery mechanism advertises this information to all
other members PE1/PE2/PE3/PE4, and a new P2MP connection from AC5 to
AC2/AC3/AC4 is created by PW signaling.
Note that VPMS instance is created when one root PE and at least one Note that VPMS instance is created when one root PE and at least one
leaf PE are added. In principle VPMS requires such minimum leaf PE are added. In principle VPMS requires such minimum
provisioning. Hence in dual-homing case of sender, only backup root provisioning. Hence in dual-homing case of sender, only backup root
PE can be dynamically added/deleted to/from VPMS without destroying PE can be dynamically added/deleted to/from VPMS without destroying
the VPN. 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 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 A solution SHOULD provide a way to activate/deactivate the
administrative status of each AC. After initial provisioning, a SP administrative status of each AC. After initial provisioning, a SP
might change connectivity configuration between particular CEs inside might change connectivity configuration between particular CEs inside
a single VPMS instance for operational reasons. This feature will be a single VPMS instance for operational reasons. This feature will be
beneficial to help such a scenario. beneficial to help such a scenario.
For example, in Figure 5, AC1, AC3, AC4 and AC5 are initially For example, in Figure 5, AC1, AC3, AC4 and AC5 are initially
provisioned for VPMS A. AC2 is not provisioned for any VPMSes. In 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 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. will usually flow from CE1 to all receivers, CE3, CE4 and CE5.
skipping to change at page 23, line 24 skipping to change at page 23, line 14
instance. The connectivity is between a root and all leaf ACs (i.e., instance. The connectivity is between a root and all leaf ACs (i.e.,
each P2MP connection can be tested). each P2MP connection can be tested).
Operators will run testing before and after service activation. Operators will run testing before and after service activation.
Testing mechanism SHOULD support end-to-end testing of the data path 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 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 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 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 data path unit for each VPMS is unidirectional, hence if loopback
testing is supported, additional consideration about reverse-path testing is supported, additional consideration about reverse-path
might also be needed (see section 6.1.3). might also be needed (see section 6.1.2).
If there are multiple P2MP connections for redundancy (active/backup If there are multiple P2MP connections for redundancy (active/backup
tree) in a common VPMS (like in Figure 4), testing mechanism MUST be tree) in a common VPMS (like in Figure 4), testing mechanism MUST be
able to check the connectivity over not only working P2MP connection able to check the connectivity over not only working P2MP connection
but also protecting connection(s). This testing MUST be able to be 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 performed from a root PE. It MAY also be able to be performed from a
sender CE. sender CE.
7.7.3. Performance Management 7.7.3. Performance Management
skipping to change at page 24, line 11 skipping to change at page 23, line 49
All or part of this information SHOULD be made available through All or part of this information SHOULD be made available through
standardized SNMP MIB Modules (Management Information Base). standardized SNMP MIB Modules (Management Information Base).
It is expected that such information can be used for SLA monitoring It is expected that such information can be used for SLA monitoring
between sender and receiver, to give the SP a clear picture of between sender and receiver, to give the SP a clear picture of
current service providing to the customer. current service providing to the customer.
7.8. Security 7.8. Security
TBD (for further study for next revision) Section 7.6. of [RFC4665] describes common Layer-2 VPN security
requirements from service provider aspect, which also applies to
VPMS. (For example, an SP network MUST be protected against
malformed or maliciously constructed customer traffic, etc.)
This subsection adds VPMS-specific consideration and requirements.
In VPMS, all traffic is transported with multicast duplication in
terms of end-to-end perspective, regardless of customer's individual
protocol. A PE never processes CE's multicast control protocol
(e.g., PIM, IGMP, MLD as Layer-3). Hence, in PE and P, basically the
security threat from malicious customer's C-plane protocol is small.
In VPMS, there is security threat from malicious customers' D-plane
traffic. A PE might receive a high volume of data from a CE. If
there is no safeguard on PE, it will cause excessive replication in
the SP network. Therefore, a VPMS solution SHOULD support traffic
policing to limit the unwanted data traffic. Such a policing
mechanism MUST be configurable per VPN basis, not the total of
various VPNs to isolate malicious customer's traffic from others.
8. Security Considerations 8. Security Considerations
Security consideration will be covered by section 6.5. and section The security requirements common to customers and service providers
7.8. (This is for further study for next revision.) are raised in Section 5.5. of [RFC4665], which are fundamental for
all Layer-2 VPN services. VPMS is a variant of Layer-2 VPN, and that
statement also applies to VPMS.
Moreover, in this document, security requirements from the view of
customers are shown in Section 6.5. Security requirements from the
view of providers are shown in Section 7.8. They explain security
considerations that are specific to VPMS.
9. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
10. Acknowledgments 10. Acknowledgments
Many thanks to Ichiro Fukuda, Kazuhiro Fujihara, Ukyo Yamaguchi and Many thanks to Ichiro Fukuda, Kazuhiro Fujihara, Ukyo Yamaguchi and
Kensuke Shindome for their ideas and feedback in documentation. Kensuke Shindome for their ideas and feedback in documentation.
skipping to change at page 24, line 44 skipping to change at page 25, line 16
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, March 2005. Private Network (VPN) Terminology", RFC 4026, March 2005.
11.2. Informative References 11.2. Informative References
[I-D.ietf-l2vpn-vpls-mcast] [I-D.ietf-l2vpn-vpls-mcast]
Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter,
"Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-04 (work "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-05 (work
in progress), June 2008. in progress), July 2009.
[I-D.ietf-pwe3-p2mp-pw-requirements] [I-D.ietf-pwe3-p2mp-pw-requirements]
JOUNAY, F., Niger, P., Kamite, Y., DeLord, S., and L. JOUNAY, F., Niger, P., Kamite, Y., DeLord, S., and L.
Martini, "Requirements for Point-to-Multipoint Martini, "Requirements for Point-to-Multipoint
Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-00 (work Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-00 (work
in progress), September 2008. in progress), September 2008.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006. Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for
Layer 2 Provider-Provisioned Virtual Private Networks", Layer 2 Provider-Provisioned Virtual Private Networks",
RFC 4665, September 2006. RFC 4665, September 2006.
 End of changes. 47 change blocks. 
146 lines changed or deleted 187 lines changed or added

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