draft-ietf-l2vpn-vpms-frmwk-requirements-00.txt   draft-ietf-l2vpn-vpms-frmwk-requirements-01.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: July 23, 2009 France Telecom Expires: January 14, 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
Jan 19, 2009 July 13, 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-00.txt draft-ietf-l2vpn-vpms-frmwk-requirements-01.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 July 23, 2009. This Internet-Draft will expire on January 14, 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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This document provides a framework and service level requirements for This document provides a framework and service level requirements for
Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer
2 VPN service that provides point-to-multipoint connectivity for a 2 VPN service that provides point-to-multipoint connectivity for a
variety of Layer 2 link layers across an IP or MPLS-enabled PSN. variety of Layer 2 link layers across an IP or MPLS-enabled PSN.
This document outlines architectural service models of VPMS and This document outlines architectural service models of VPMS and
states generic and high level requirements. This is intended to aid states generic and high level requirements. This is intended to aid
in developing protocols and mechanisms to support VPMS. in developing protocols and mechanisms to support VPMS.
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Ethernet Use Case . . . . . . . . . . . . . . . . . . . . 5 4.1. Ethernet Use Case . . . . . . . . . . . . . . . . . . . . 6
4.2. ATM-based Use Case . . . . . . . . . . . . . . . . . . . . 6 4.2. ATM-based Use Case . . . . . . . . . . . . . . . . . . . . 7
4.3. TDM-based Use Case . . . . . . . . . . . . . . . . . . . . 7 4.3. TDM-based Use Case . . . . . . . . . . . . . . . . . . . . 7
5. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 8 5. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 8
6. Customer Requirements . . . . . . . . . . . . . . . . . . . . 10 6. Customer Requirements . . . . . . . . . . . . . . . . . . . . 11
6.1. Service Topology . . . . . . . . . . . . . . . . . . . . . 10 6.1. Service Topology . . . . . . . . . . . . . . . . . . . . . 11
6.1.1. Point-to-Multipoint Support . . . . . . . . . . . . . 10 6.1.1. Point-to-Multipoint Traffic Support . . . . . . . . . 11
6.1.2. Multiple Source Support . . . . . . . . . . . . . . . 10 6.1.2. Reverse Traffic Support . . . . . . . . . . . . . . . 11
6.1.3. Reverse Traffic Support . . . . . . . . . . . . . . . 11
6.2. Transparency . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Transparency . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . . 14 6.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . . 14
6.4. Protection and Restoration . . . . . . . . . . . . . . . . 14 6.4. High Availability . . . . . . . . . . . . . . . . . . . . 14
6.4.1. Dual-homed Access Support . . . . . . . . . . . . . . 14 6.4.1. Dual-homed Access Support . . . . . . . . . . . . . . 14
6.4.2. Single/Dual Traffic Support in Dual-homed Access . . . 14 6.4.2. Single/Dual Traffic Support in Dual-homed Access . . . 17
6.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.6. Reordering Prevention . . . . . . . . . . . . . . . . . . 16 6.6. Reordering Prevention . . . . . . . . . . . . . . . . . . 17
6.7. Failure reporting . . . . . . . . . . . . . . . . . . . . 16 6.7. Failure reporting . . . . . . . . . . . . . . . . . . . . 18
7. Service Provider Network Requirements . . . . . . . . . . . . 16 7. Service Provider Network Requirements . . . . . . . . . . . . 18
7.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Pseudo Wire Signaling and PSN Tunneling . . . . . . . . . 16 7.2. Pseudo Wire Signaling and PSN Tunneling . . . . . . . . . 18
7.3. Discovering VPMS Related Information . . . . . . . . . . . 17 7.3. Discovering VPMS Related Information . . . . . . . . . . . 19
7.4. Activation and Deactivation . . . . . . . . . . . . . . . 18 7.4. Activation and Deactivation . . . . . . . . . . . . . . . 20
7.5. Inter-AS Support . . . . . . . . . . . . . . . . . . . . . 19 7.5. Inter-AS Support . . . . . . . . . . . . . . . . . . . . . 21
7.6. Co-existence with Existing L2VPNs . . . . . . . . . . . . 19 7.6. Co-existence with Existing L2VPNs . . . . . . . . . . . . 22
7.7. Operation, Administration and Maintenance . . . . . . . . 20 7.7. Operation, Administration and Maintenance . . . . . . . . 22
7.7.1. Fault Management . . . . . . . . . . . . . . . . . . . 20 7.7.1. Fault Management . . . . . . . . . . . . . . . . . . . 22
7.7.2. Testing . . . . . . . . . . . . . . . . . . . . . . . 21 7.7.2. Testing . . . . . . . . . . . . . . . . . . . . . . . 23
7.7.3. Performance Management . . . . . . . . . . . . . . . . 21 7.7.3. Performance Management . . . . . . . . . . . . . . . . 23
7.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 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)
point-to-point service. A VPLS is an L2 service that emulates point-to-point service. A VPLS is an L2 service that emulates
Ethernet LAN service across a Wide Area Network (WAN). Ethernet LAN service across a Wide Area Network (WAN).
For some use cases described hereafter, there are P2MP (point-to- For some use cases described hereafter, there are P2MP (point-to-
multipoint) type services for Layer 2 traffic. However, there is no multipoint) type services for Layer 2 traffic. However, there is no
straightforward way to realize them based on the existing L2VPN straightforward way to realize them based on the existing L2VPN
specifications. specifications.
In a VPWS, a SP can set up point-to-point connectivity per a pair of 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- CEs but it is not possible to replicate traffic for point-to-
multipoint services in the SP's network side. A SP could build multipoint services in the SP's network side. A SP could build
multiple PWs independently and have the CEs replicate traffic over multiple Pseudowires (PWs) independently and have the CEs replicate
them, but this is not only inconvenient for the customer, it's a traffic over them, but this is not only inconvenient for the
waste of bandwidth resources. customer, it's a waste of bandwidth resources.
In a VPLS, SPs can natively offer multipoint connectivity across In a VPLS, SPs can natively offer multipoint connectivity across
their backbone. Although it is seemingly applicable for point-to- their backbone. Although it is seemingly applicable for point-to-
multipoint service as well, there remains extra complexity for SPs to multipoint service as well, there remains extra complexity for SPs to
filter unnecessary traffic between irrelevant sites (i.e., from a filter unnecessary traffic between irrelevant sites (i.e., from a
receiver PE to another receiver PE) because VPLS provides multipoint- receiver PE to another receiver PE) because VPLS provides multipoint-
to-multipoint connectivity between CEs. Moreover, VPLS's MAC-based to-multipoint connectivity between CEs. Moreover, VPLS's MAC-based
learning/forwarding operation is unnecessary for some scenarios learning/forwarding operation is unnecessary for some scenarios
particularly if customers only need simple unidirectional point-to- particularly if customers only need simple unidirectional point-to-
multipoint service, or if they require non- Ethernet Layer 2 multipoint service, or if they require non- Ethernet Layer 2
skipping to change at page 5, line 43 skipping to change at page 5, line 43
PE/CE: Provider/Customer Edge PE/CE: Provider/Customer Edge
P: Provider Router P: Provider Router
AC: Attachment Circuit AC: Attachment Circuit
PSN: Packet Switched Network PSN: Packet Switched Network
SP: Service Provider 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.
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. Use Cases
4.1. Ethernet Use Case 4.1. Ethernet Use Case
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
skipping to change at page 6, line 25 skipping to change at page 6, line 37
replication for Ethernet traffic. Native VPLS already supports this replication for Ethernet traffic. Native VPLS already supports this
capability via a full mesh of PWs, and an extension to optimize capability via a full mesh of PWs, and an extension to optimize
replication is also proposed [I-D.ietf-l2vpn-vpls-mcast] as an replication is also proposed [I-D.ietf-l2vpn-vpls-mcast] as an
additional feature. However, VPLS by nature requires MAC-based additional feature. However, VPLS by nature requires MAC-based
learning and forwarding, which might not be needed in some cases by learning and forwarding, which might not be needed in some cases by
particular users. Generally, video distribution applications use particular users. Generally, video distribution applications use
unidirectional P2MP traffic, but may not always require any added unidirectional P2MP traffic, but may not always require any added
complexity of MAC address management. In addition, VPLS is a service complexity of MAC address management. In addition, VPLS is a service
that essentially provides any-to-any connectivity between all CEs in that essentially provides any-to-any connectivity between all CEs in
a L2VPN as it emulates a LAN service. However, if only P2MP a L2VPN as it emulates a LAN service. However, if only P2MP
connectivity is required, the traffic between different receivers is connectivity is required, the traffic between leaves is not allowed.
not always needed, and traffic from receiver to sender is not always It might require extra efforts to guarantee this behavior in VPLS.
needed, either. In these cases, VPMS is a service that provides much And in some P2MP scenarios there no traffic from leafs to root. In
simpler operation. these cases, VPMS is a service that provides much simpler operation.
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.
skipping to change at page 7, line 17 skipping to change at page 7, line 30
4.3. TDM-based Use Case 4.3. TDM-based Use Case
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.
In a PSN environment, the existing VPWS allows support for 2G/3G One use case is TDM-based multicast video delivery. That is, data
mobile backhauling (e.g. TDM traffic for GSM's Abis interface, ATM duplication is simply provided by Layer 1, without using upper
traffic for Release 99 UMTS's Iub interface). Currently, the Mobile 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 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 the 2G/3G controller (e.g. BSC or RNC) and the 2G/3G Base Stations
(BTS or NodeB). Therefore VPWSes (P2P services) are used between (BTS or NodeB). VPWS (P2P service) can be used between each Base
each Base Station and their corresponding controller and nothing more Station and their corresponding controller, nothing more is required.
is required.
As far as synchronization in a PSN environment is concerned, As far as synchronization in a PSN environment is concerned,
different mechanisms can be considered to provide frequency and phase different mechanisms are being considered to provide frequency and
clock required in the 2G/3G Mobile environment to guarantee mobile phase synchronization required in the 2G/3G Mobile environment to
handover and strict QoS. One of them consists of using Adaptive guarantee mobile handover and strict QoS. One mechanism consists of
Clock Distribution and Recovery. With this method a Master element using Adaptive Clock Distribution and Recovery. With this method a
distributes a reference clock at protocol level by regularly sending Master element distributes a reference clock frequency at protocol
TDM PW packets (SAToP, CESoPSN or TDMoIP) to Slave elements. This level by regularly sending TDM PW packets (SAToP, CESoPSN or TDMoIP)
process is based on the fact that the volume of transmitted data to Slave elements. This process is based on the fact that the volume
arrival is considered as an indication of the source frequency that of transmitted data arrival is considered as an indication of the
could be used by the Slave element to recover the source clock source frequency that could be used by the Slave element to recover
frequency. Consequently, with the current methods, the PE connected the source clock frequency. With the current methods, the PE
to the Master must setup and maintain as many VPWS (P2P) as their are connected to the Master must setup and maintain as many VPWS (P2P) as
Slave elements, and the Master has to replicate the traffic. A there are Slave elements, and the Master has to replicate the
better solution to deliver the clock frequency would be to use a VPMS traffic. A more efficient solution to deliver the clock frequency
which supports P2MP traffic. This may scale better than P2P services would be to use a VPMS which supports P2MP traffic. This would scale
(VPWS) with regards to the forwarding plane at the Master since the better than P2P services (VPWS) with regards to the forwarding plane
traffic is no longer replicated to individual VPWSes (P2P) but only at the Master since the traffic is no longer needs to be replicated
to the AC associated to the VPMS (P2MP). It may ease the to individual VPWSes (P2P), only a single copy needs to be sent on
provisioning process since only one source endpoint must be the AC associated to the VPMS (P2MP). Also, it may ease the
configured at the Ingress PE. This alleviated provisioning process provisioning process since only one source endpoint needs to be
would simplify the introduction of new Base Stations. The main gain configured at the Ingress PE. This provisioning process would
would be to avoid replication on the Master and hence save bandwidth simplify the introduction of new Base Stations. The most significant
consumed by the synchronization traffic which typically requires the gain of using VPMS would be that it avoids replication on the Master
highest level of QoS. This kind of traffic will be competing with and hence saves bandwidth consumption by the synchronization traffic
equivalent QOS traffic like VoIP, which is why it is significant to which typically requires the highest level of QoS. This type of
save the slightest bandwidth. 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 | +------+ VPMS A +------+ | VPMS A VPMS A | +------+ Connection +------+ | VPMS A
Sender +->|......>...+.......... >......|>-+ Receiver Sender +->|......>...+.......... >......|>-+ Receiver
| VPMS | . | VPMS | | VPMS | . | VPMS |
| PE1 | . VPMS B | PE2 | | PE1 | . | PE2 |
+-<|......<.. . ....+.....<......|<-+ +-<|......<.. . ....+.....<......|<-+
| +------+ . . +------+ | | +------+ . . +------+ |
+-----+ | | . . | | +-----+ +-----+ | | . . | | +-----+
| CE4 |<---+ |Routed . . | +---| CE3 | | CE4 |<---+ |Routed . . VPMS B's P2MP +---<| CE3 |
+-----+ AC4 |Backbone. . | AC3 +-----+ +-----+ AC4 |Backbone. . Connection AC3 +-----+
VPMS B | . . | VPMS B VPMS B | . . | VPMS B
Receiver | +-v-----v-+ | Sender Receiver | +-v-----v-+ | Sender
------| . . |------- ------| . . |-------
| . VPMS. | | . VPMS. |
| . PE3 . | | . PE3 . |
+---------+ +---------+
v v v v VPMS A:
| | | | Root AC : AC1
AC5| |AC6 AC5| |AC6 Leaf AC : AC2, AC5
v v v v VPMS B:
+-----+ +-----+ +-----+ +-----+ Root AC : AC3
| CE5 | | CE6 | | CE5 | | CE6 | Leaf AC : AC4, AC6
+-----+ +-----+ +-----+ +-----+
VPMS A VPMS B VPMS A VPMS B
Receiver Receiver Receiver Receiver
Figure 1: Reference Model for VPMS Figure 1: Reference Model for VPMS
A VPMS instance is defined as a service entity manageable in VPMS A VPMS instance is defined as a service entity manageable in the VPMS
architecture. A single VPMS instance provides isolated service architecture. A single VPMS instance provides an isolated service
reachability domain to each CE, so it corresponds to a so-called reachability domain to each CE, so it corresponds to a so-called
"VPN" as a specific set of sites that allows communication. A single "VPN" as it allows communication among a specific set of sites. A
VPMS instance provides a unique unidirectional point-to-multipoint single VPMS instance provides a unique point-to-multipoint L2VPN
L2VPN service. In Figure 1, there are two VPMS instances shown, VPMS service. In Figure 1, there are two VPMS instances shown, VPMS A and
A and VPMS B. In principle, there is no traffic exchange allowed VPMS B. In principle, there is no traffic exchange allowed between
between these different instances, so they are treated as different these different instances, so they are treated as different VPNs.
VPNs.
In a VPMS, a single CE-PE connection is used for transmitting frames In a VPMS, a single CE-PE link connection is used for transmitting
for delivery to multiple remote CEs, with point-to-multipoint 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 duplication. The SP's network (PE as well as P) has a role to
duplicate frames so that the traffic source does not need to send replicate frames so that the sender's CE does not need to send
multiple frames to individual receivers. multiple frames to individual receivers.
Like VPWS, an Attachment Circuit (AC) is provided to accommodate CEs 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 in a VPMS. In a VPMS, an AC attached to a VPMS MUST be configured as
"sender" or "receiver" not both. That is, any AC is associated with "root" (sender) or "leaf" (receiver) not both. Any AC is associated
the role of either sending side (Tx) or receiving side (Rx) from the with the role of either sending side (Tx) or receiving side (Rx) from
view of the CE. Thus every AC deals with unidirectional traffic the view of the CE. These will be named the root (sender) AC and
flows. A sender AC does not have a capability of transmitting the leaf (receiver) AC respectively. Unless reverse traffic is
traffic back to a CE at upstream side. Likewise a receiver AC does optionally supported, a root AC does not transmit traffic back to a
not have a capability of receive the traffic from a CE at downstream CE at upstream side, likewise a leaf AC does not receive traffic from
side. In Figure 1, AC1 and AC3 are configured as senders while AC2, a CE at downstream side. In Figure 1, AC1 and AC3 are configured as
AC4, AC5 and AC6 are configured as receivers. In VPMS A, CE1 could root ACs while AC2, AC4, AC5 and AC6 are configured as leaf ACs. In
send traffic via AC1, but CE2 and CE5 could not send back traffic. VPMS A, CE1 could send traffic via AC1, and CE2 and CE5 could receive
the traffic.
A CE which is locally connected to a sender AC is called a sender CE. A CE which is locally connected to a root AC is called a root
Also a CE which is locally connected to a receiver AC is called a (sender) CE. Also a CE which is locally connected to a leaf AC is
receiver CE. However, such CEs's roles will not be managed directly called a leaf (receiver) CE. However, such CEs's roles will not be
in VPMS because the configured AC's role (sender or receiver) will managed directly in VPMS because the configured AC's role (root or
automatically determine them. 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 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). (thorough AC1) is mapped to VPMS A (to CE2 and CE5).
In a VPMS, PEs will be connected by PW technology which may include In a VPMS, P2MP tree-shaped reachability is given from a single root
P2MP traffic optimization (i.e., P2MP PW. See section 7.2.). P2MP AC to several leaf ACs. This will be named a "P2MP connection" in
traffic optimization will provide the benefit of traffic replication this VPMS framework. P2MP connection is a logical entity between PE/
for high bandwidth efficiency. The sender CE has only to transmit ACs in a given VPMS instance that transfers unidirectional traffic
one stream towards the PE and it does not have to replicate traffic. transparently from one local ingress AC to one or more remote egress
Also routed backbone provides IP or MPLS-enabled PSN tunnels for ACs.
transporting the PW traffic.
Regarding end-to-end traffic topology between the PEs, a single VPMS Similar to other L2VPN mechanisms, the VPMS architecture is based on
instance (i.e., one VPN) may correspond to a single unidirectional PWs which may be using through IP or MPLS-enabled PSN tunnels over a
P2MP PW topology. In Figure 1, VPMS A (one instance) has a single routed backbone. That is, every P2MP connection can be instantiated
P2MP PW topology (from PE1 to PE2 and PE3). However, there is also a by PW technology that supports P2MP traffic optimization (i.e., P2MP
case that a single VPMS consists of two or more P2MP PW topology PW. See section 7.2.). P2MP traffic optimization will provide the
grouped which is typically used for redundancy. The details are benefit of traffic replication for high bandwidth efficiency. That
given in section 6.1.2. 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, VPMS can support various Layer 2 protocol services such as Ethernet,
ATM, etc. ATM, etc.
6. Customer Requirements 6. Customer Requirements
6.1. Service Topology 6.1. Service Topology
6.1.1. Point-to-Multipoint Support 6.1.1. Point-to-Multipoint Traffic Support
A solution MUST support unidirectional point-to-multipoint
connectivity from a sender to multiple receivers. A sender CE is
assured to send traffic to one or more receiver CEs. Receiver CEs
include not only the CEs which are located at remote sites, but also
the local CEs which are connected to the same sender-side PE. If
there is only one receiver in the instance, it is considered
equivalent to unidirectional point-to-point traffic.
6.1.2. Multiple Source Support
A solution MUST support multiple sender topologies in one VPMS
instance, where a common receiver group is reachable from two or more
senders. This means that a solution needs to support having multiple
P2MP topologies in the backbone whose roots are located apart in a
common service. In other words, each P2MP topology MUST only have a
single sender, however multiple P2MP topologies can be grouped
together into a single VPMS instance. For example, in Figure 2,
traffic from sender CE1 and CE2 both reach receivers CE3 and CE4
while CE1, CE2, CE3 and CE4 all are associated with a single service.
This topology is useful for increasing service reliability by
redundant sources. Note that every receiver has only to have one AC
connected to each PE to receive traffic. (in Figure 2, AC3 and AC4
respectively). Thus a solution will also need to support protection
and restoration mechanism combining these multiple P2MP topologies.
(See section 6.4 too).
+-----+ AC1 AC2+-----+ A solution MUST support unidirectional point-to-multipoint traffic
| CE1 |>-+ ---------------------------- +-<| CE2 | 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
VPMS A | +------+ +------+ | VPMS A which are located at remote sites, but also the local CEs which are
Sender +->|......>.. .............+..<......|<-+ Sender connected to the same root PE. If there is only one receiver in the
Tx | VPMS | . . . | VPMS | Tx instance, it is considered equivalent to unidirectional point-to-
| PE 1 | . . . | PE 2 | point traffic.
| | . . . | |
+------+ . . . +------+
| . . . |
| +.. . ...... . |
| . . . . |
| . . . . |
| +-v----v-+ +-v----v-+ |
---| . . |---| . . |---
VPMS| . . | | . . |VPMS
PE 3| . | | . |PE 4
+--------+ +--------+
v v
AC3| |AC4
v v
+-----+ +-----+
| CE3 | | CE4 |
+-----+ +-----+
VPMS A VPMS A
Receiver Receiver
Figure 2: Multiple source support 6.1.2. Reverse Traffic Support
6.1.3. 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.
There are cases where a reverse traffic flow is necessary. A sender A VPMS solution MAY support reverse traffic from a leaf AC to a root
CE might sometimes want to receive traffic from a receiver CE. There AC. Each reverse path is basically given in a P2P (unicast) manner.
are some usage scenarios for this, such as stream monitoring through In other words, each leaf of the P2MP tree can individually send back
a loopback mechanism, control channels which need feedback traffic to the root. For this purpose a VPMS instance MAY have more
communication etc. The simplest way to accomplish this is to provide than one reverse P2P connections as network entity; However, such
different VPMS instances for reverse traffic, i.e. a sender CE is a network entities MUST have a common field that enables themselves to
receiver of another VPMS instance. be managed together in the same VPN. Any PWs used for such
connections are expected to be assigned a common VPMS instance ID.
Figure 3 illustrates this kind of reverse traffic scenario, where CE1 Note, a VPMS does not assume any-to-any multipoint reachability.
is configured as a sender in VPMS A and a receiver in VPMS B. VPMS B Therefore, in principle, every leaf AC does not exchange traffic
is used for reverse traffic. Note that a closed single network here directly with other leaf ACs even if reverse traffic is supported.
is composed of two VPMS instances. In operational terms, CE1 and CE4
belong to the same closed "VPN" by administrative policy (e.g., CE1,
CE2, CE3 and CE4 are the devices in one enterprise's intranet
network).
Such bi-directional instances can be easily created if two distinct Figure 3 illustrates this kind of scenario, where CE1 is configured
ACs are provisioned for sending and receiving exclusively (e.g., if as a sender in VPMS A. AC1 is a root AC, and AC2/AC3/AC4 are leaf
VLAN id in dot1Q tagged frame is a service delimiter, different VLAN ACs. P2MP connection is given for forward traffic. Unidirectional
ids are uniquely allocated for Tx and Rx). This approach is P2P connection is also provided for reverse traffic from AC4 to AC1.
acceptable if a receiver CE device can change Layer 2 interface
appropriately in data transmitting and receiving.
Meanwhile it is also true that this might be considered a limitation Other reverse P2P connections can be provided similarly. (from AC2 to
in some deployment scenarios. If a CE is an IP router or Ethernet AC1 / from AC3 to AC1).
bridge, reverse traffic is normally expected to be received on the
same interface as forward traffic on the receiver CE. (i.e., the same
VLAN id is to be used for reverse traffic if the AC supports dot1Q
tagged frames.)
Therefore, in a VPMS solution, both of the two type of ACs, sending In this case, PEs need to deal with two types of traffic, locally-
(Tx) and receiving (Rx), SHOULD be allowed to be placed in the same attached CE's sending (Tx) and receiving (Rx) flows. In Figure 3,
physical/virtual circuit. In Figure 3, suppose AC5 of VPMS A is they are both passing through the same AC (AC1 and AC4). But it is
provisioned as {VLAN id = 100, direction= Rx}. It is expected that an implementation matter if Tx and Rx traffic are conveyed on the
operators can provision AC6 of VPMS B in the same physical port as same physical link or separate links. It is also possible that a
{VLAN id = 100, direction = Tx}. That is, the combination between root PE multiplexes two ore more reverse traffic from different
VLAN id and the flow direction is now considered to be a service leaves and transmits it to an upstream CE over the same local link.
delimiter.
Note, in most implementations of VPWS today, every AC is always Note, in most implementations of VPWS today, every AC is always
considered bidirectional and a unique Layer 2 header/circuit (ATM considered bidirectional. In contrast, in VPMS, every AC can be
VPI/VCI, an Ethernet port, a VLAN etc.) is considered the service chosen unidirectional (if it is a totally unidirectional service), or
delimiter. In contrast in VPMS, every AC is considered bidirectional (if reverse traffic is supported).
unidirectional and traffic direction is an additional element to
identify a unique AC.
+-----+ <-- Rx VPMS B +-----+ <-- Rx (bidirectional)
| CE1 |<----------------+ | CE1 |--------------+
+-----+--------------+ | +-----+ --> Tx |
VPMS A Sender --> Tx VPMS A| | VPMS A Sender |
VPMS B Receiver AC1 v ^ AC2 AC1 |
+----------+ VPMS +----------+ VPMS
| . . | PE1 | . . | PE1
| . ... | | . .... |
-------| . . |-------- -------| . . |--------
| +-v------^-+ | | P2MP +-v------^-+ |
Connection . . |
(forward) + . |
| . . | | . . |
| + . |
+------+ . . . . +------+ +------+ . . . . +------+
+-<|......<.. . .. . ......>..... |>-+ +-<|......<.. . .. . ......>..... |>-+
| | VPMS | . . | VPMS | | | | VPMS | . . | VPMS | |
AC3| | PE2 | . . | PE3 | |AC4 AC2| | PE2 | . . | PE3 | |AC3
| +------+ . . +------+ | | +------+ . . +------+ |
+-----+ | | . . | | +-----+ +-----+ | | . . P2P | | +-----+
| CE2 |<--+ | Routed . . | +-->| CE3 | | CE2 |<--+ | Routed . . Connection +-->| CE3 |
+-----+ <-- | Backbone. . | --> +-----+ +-----+ <-- | Backbone. . (reverse)| --> +-----+
VPMS A Rx | +-v------^-+ | Rx VPMS A VPMS A Rx | +-v------^-+ | Rx VPMS A
Receiver -------| . . |-------- Receiver Receiver -------| . . |-------- Receiver
| . ... | | . .... |
| . . | VPMS | . . | VPMS
+----------+ PE4 +----------+ PE4
AC5v ^AC6 AC4|
| | <-- Tx VPMS B +-----+ |
| +----------------<| CE4 | | <-- Tx +-----+
+------------------->+-----+ +--------------------| CE4 |
--> Rx VPMS A VPMS A Receiver (bidirectional) --> Rx +-----+
VPMS B Sender VPMS A
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 honoured 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 sender
CE to receiver CEs in a given instance. Note, however, if service 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 delimiting fields (VLAN Id in Ethernet, VPI/VCI in ATM, DLCI in FR
etc.) are assigned by SP, they are not transparent. It depends on etc.) are assigned by the SP, the Layer 2 traffic is not necessarily
SP's choice if they are assigned at each AC. Hence it could be that transparent. It will depend on the SP's choice if they are assigned
some of receiver CEs are getting traffic with different delimiting at each AC. Hence, it could be that some of receiver CEs are getting
fields than the other receiver CEs. traffic with different delimiting fields than the other receiver CEs.
VPMS solution SHOULD NOT require any special packet processing by the The VPMS solution SHOULD NOT require any special packet processing by
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 the guaranteed A customer may require that the VPMS service provide guaranteed QoS.
QoS. In particular, for real time applications which are considered In particular, for real time applications which are considered common
common in point-to-multipoint delivery, delay and loss sensitive in point-to-multipoint delivery, delay and loss sensitive traffic
traffic MUST be supported. The solution SHOULD provide native QoS MUST be supported. The solution SHOULD provide native QoS techniques
techniques for service class differentiation, such as IEEE 802.1p CoS for service class differentiation, such as IEEE 802.1p CoS for
for Ethernet. Ethernet.
For bandwidth committed services (e.g., ATM CBR), a solution SHOULD For bandwidth committed services (e.g., ATM CBR), a solution SHOULD
guarantee end-to-end bandwidth. It MAY provide flow admission guarantee end-to-end bandwidth. It MAY provide flow admission
control mechanisms to achieve that. control mechanisms to achieve that.
6.4. Protection and Restoration 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-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 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. Additionally, a solution SHOULD provide protection multiple PEs. This if beneficial to support reliable data delivery
mechanism between the different PEs to which a CE is attached. This for customers. Figure 3 provides an example of this access topology.
is because when an ingress PE node fails whole traffic delivery will .
fail unless a backup sender PE is provided, even in case of dual-
homed access. Similarly, if an egress PE node fails, traffic toward
that CE is never received unless a backup egress PE is provided.
Figure 4 is an example for this access topology.
6.4.2. Single/Dual Traffic Support in Dual-homed Access
When dual-homed access to sender 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 sender 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 ingress PE SHOULD be able to filter the
incoming unnecessary traffic while active PE is working. Also in
either case, single traffic or dual traffic, the protection mechanism
of ingress PEs described in the previous subsection will be necessary
to handle the traffic appropriately.
In the case of dual-homed access to receiver PEs, a solution MAY
allow a receiver CE to receive a single copy of the traffic from
either one of the two 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.
+-----+ +-----+
| 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 15, line 38 skipping to change at page 15, line 33
Receiver | PE4| | Receiver Receiver | PE4| | Receiver
+----+ | +----+ |
| AC6 v | AC6 v
\ +-----+ \ +-----+
+--------------->| CE4 | +--------------->| CE4 |
+-----+ +-----+
VPMS A VPMS A
Receiver Receiver
(dual-homed) (dual-homed)
Figure 4: Dual homing support 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.
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
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 6.5. Security
The basic security requirement raised in Section 6.5 of [RFC4665] The basic security requirement raised in Section 6.5 of [RFC4665]
also applies to VPMS. 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 filtering control mechanism
between particular sender/receiver sites inside a VPMS instance. For between 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 and CE5 is allowed but traffic from CE1 to CE6 is CE1 to CE4/CE5 is allowed but traffic from CE1 to CE6 is filtered.
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
skipping to change at page 16, line 26 skipping to change at page 18, line 20
7. Service Provider Network Requirements 7. Service Provider Network Requirements
7.1. Scalability 7.1. Scalability
A VPMS solution MUST be designed to scale well with an increase in A VPMS solution MUST be designed to scale well with an increase in
the number of any of the following metrics: the number of any of the following metrics:
- the number of PEs (per VPMS instance and total in a SP network) - 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 VPMS instances (per PE and total)
- the number of sender CEs (per PE, VPMS instance and total) - the number of root ACs / sender CEs (per PE, VPMS instance and
- the number of receiver CEs (per PE, VPMS instance and total) total)
- the number of leaf ACs / receiver CEs (per PE, VPMS instance and
total)
A VPMS solution SHALL document its scalability characteristics in A VPMS solution SHALL document its scalability characteristics in
quantitative terms. A solution SHOULD quantify the amount of state quantitative terms. A solution SHOULD quantify the amount of state
that a PE and a P device has to support. that a PE and a P device has to support.
The scalability characteristics SHOULD include: The scalability characteristics SHOULD include:
- the processing resources required by the control plane in managing - the processing resources required by the control plane in managing
PWs (neighborhood or session maintenance messages, keepalives, PWs (neighborhood or session maintenance messages, keepalives,
timers, etc.) timers, etc.)
skipping to change at page 17, line 11 skipping to change at page 19, line 6
network. For supporting efficient replication, it is expected to network. For supporting efficient replication, it is expected to
take advantage of PW and PSN mechanisms that are capable of P2MP take advantage of PW and PSN mechanisms that are capable of P2MP
traffic. traffic.
Regarding PW mechanism, [I-D.ietf-pwe3-p2mp-pw-requirements] Regarding PW mechanism, [I-D.ietf-pwe3-p2mp-pw-requirements]
introduces P2MP PW concept and its requirements, showing two basic introduces P2MP PW concept and its requirements, showing two basic
approaches of providing replication. One is SS (Single Segment)-PW approaches of providing replication. One is SS (Single Segment)-PW
model that provides replication by PSN tunnel such as P2MP LSP (i.e., model that provides replication by PSN tunnel such as P2MP LSP (i.e.,
by outer label layer), and the other is MS (Multi Segment)-PW model by outer label layer), and the other is MS (Multi Segment)-PW model
that provides replication by multiple interconnected PWs (i.e., by that provides replication by multiple interconnected PWs (i.e., by
inner label layer). In either case, end-to-end P2MP topology in VPMS inner label layer). In either case, end-to-end P2MP topology (i.e.,
is common from the view of PEs and ACs. Requirements as a provider P2MP connection) in VPMS is common from the view of ACs.
service specified in this document will be commonly applied Requirements as a provider service specified in this document will be
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
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 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 only to VPMS. The actual multipoint-to-multipoint) that is applied to VPMS. The actual type
type of PSN tunnel used in VPMS will be dependent on individual of PSN tunnel used in VPMS will be dependent on individual deployment
deployment scenarios (e.g., which PSN protocol is available now in scenarios (e.g., which PSN protocol is available in the core and how
the core and how much network resources operators will want to much of the network resources that operators will want to optimize).
optimize).
7.3. Discovering VPMS Related Information 7.3. Discovering VPMS Related Information
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 information to be discovered by the PEs to minimize the
amount of configuration the SP must perform. 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.
skipping to change at page 18, line 9 skipping to change at page 20, line 9
Following is an example scenario: by default, every PE will have the Following is an example scenario: by default, every PE will have the
association among the information described above. Suppose a new PE association among the information described above. Suppose a new PE
having an AC is provisioned in the existing VPMS instance and this AC having an AC is provisioned in the existing VPMS instance and this AC
is configured as receiver. This information will be automatically is configured as receiver. This information will be automatically
discovered by the other existing remote PEs (i.e., ingress and egress discovered by the other existing remote PEs (i.e., ingress and egress
PEs in the same VPMS instance). Once the ingress PE discovers this 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 new PE/AC, it can automatically add it as the new leaf of P2MP
topology according to P2MP PW signaling mechanism. This operation topology according to P2MP PW signaling mechanism. This operation
does not require any new configuration at the existing PEs. 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 7.4. Activation and Deactivation
This section raises generic requirements for handling related This section raises generic requirements for handling related
information about remote sites after the initial provisioning to ease information about remote sites after the initial provisioning to ease
the total operation of VPMS. 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 CE/AC. After initial provisioning, a administrative status of each AC. After initial provisioning, a SP
SP might change connectivity configuration between particular CEs might change connectivity configuration between particular CEs inside
inside a single VPMS instance for operational reasons. This feature a single VPMS instance for operational reasons. This feature will be
will be beneficial to help such a scenario. beneficial to help such a scenario.
For example, in Figure 5, CE1, CE3, CE4 and CE5 (and their ACs) are For example, in Figure 5, AC1, AC3, AC4 and AC5 are initially
initially provisioned for VPMS A. CE2 is not provisioned for any provisioned for VPMS A. AC2 is not provisioned for any VPMSes. In
VPMSes. In VPMS A, CE1 is a sender and CE3, CE4 and CE5 are VPMS A, CE1 is a sender and CE3, CE4 and CE5 are receivers. Traffic
receivers. Traffic will usually flow from CE1 to all receivers, CE3, will usually flow from CE1 to all receivers, CE3, CE4 and CE5.
CE4 and CE5. However, for maintenance operation, application's However, for maintenance operation, application's request (e.g.,
request (e.g., stream program has changed) or some other reasons, CE4 stream program has changed) or some other reasons, AC4 needs to be
needs to be set as administratively deactivated. Then it becomes set as administratively deactivated. Then it becomes necessary to
necessary to turn off traffic from PE4 to CE4. This operation must turn off traffic from PE4 to CE4. This operation must be
be appropriately distinguished from failure cases. appropriately distinguished from failure cases.
When deactivating a particular site, backbone PSN/PW resources (e.g., When deactivating a particular site, backbone PSN/PW resources (e.g.,
admission control of PSN tunnel) MAY be released for that particular admission control of PSN tunnel) MAY be released for that particular
direction in order to provide that bandwidth to other services. In direction in order to provide that bandwidth to other services. In
Figure 5, CE3 is now administratively activated and receiving Figure 5, AC3 is now administratively activated and receiving
traffic. However, if CE3 comes to be administratively deactivated, traffic. However, if AC3 comes to be administratively deactivated,
and if RSVP-TE (including P2P and/or P2MP) is used for backbone PSN, 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. then TE reserved resources from PE1 to PE3 may be released.
In addition, a solution SHOULD allow single-sided activation In addition, a solution SHOULD allow single-sided activation
operation at a sender PE. In some scenarios, operators prefer operation at a root (ingress) PE. In some scenarios, operators
centralized operation. This is often considered natural for one-way prefer centralized operation. This is often considered natural for
digital audio/video distribution applications: SPs often want to one-way digital audio/video distribution applications: SPs often want
complete their service delivery by a single operation at one source to complete their service delivery by a single operation at one
PE, not by multiple operations at many receiver PEs. Figure 5 source PE, not by multiple operations at many leaf (egress) PEs.
illustrates this scenario, where a SP only has to do single-sided Figure 5 illustrates this scenario, where a SP only has to do single-
operation at PE1 (source) to administratively activate/deactivate sided operation at PE1 (source) to administratively activate/
various connections from AC1 to AC3, AC4 and/or AC5. It is not deactivate various connections from AC1 to AC3, AC4 and/or AC5. It
needed to perform operations on PE3 and PE4 directly. is not needed to perform operations on PE3 and PE4 directly.
+-----+ AC1 +-----+ AC1
+ CE1 +----------------+ + CE1 +----------------+
+-----+ | +-----+ |
VPMS A Sender | VPMS A Sender |
(sending now) v (sending now) v
+----+ +----+
-----|VPMS|-------- -----|VPMS|--------
| | PE1| | | | PE1| |
| +----+ | | +----+ |
+----+ +----+ +----+ +----+
|VPMS| |VPMS| |VPMS| |VPMS|
| PE2| Routed | PE3| | PE2| Routed | PE3|
+----+ Backbone +----+ AC2 +----+ Backbone +----+ AC3
AC2 / | | \ AC3 (not provisioned) / | | \
+-----+ / | | \ +-----+ +-----+ / | | \ +-----+
+ CE2 +<-+ | | +->| CE3 | + CE2 +<-+ | | +->| CE3 |
+-----+ | +----+ | +-----+ +-----+ | +----+ | +-----+
(not provisioned) ----|VPMS|--------- VPMS A Receiver (not receiving) ----|VPMS|--------- VPMS A Receiver
| PE4| (receiving now) | PE4| (receiving now)
+----+ +----+
AC5 / \ AC4 AC5 / \ AC4
+-----+ / \ +-----+ +-----+ / \ +-----+
+ CE5 +<----------+ +---------------->| CE4 | + CE5 +<----------+ +---------------->| CE4 |
+-----+ +-----+ +-----+ +-----+
VPMS A Receiver VPMS A Receiver VPMS A Receiver VPMS A Receiver
(receiving now) (not receiving) (receiving now) (not receiving)
CE1/AC1: Administratively activated AC1: Administratively activated
CE2/AC2: No VPMS provisioned AC2: No VPMS provisioned
CE3/AC3: Administratively activated AC3: Administratively activated
CE4/AC4: Administratively deactivated AC4: Administratively deactivated
CE5/AC5: Administratively activated AC5: Administratively activated
Figure 5: Site activation and deactivation Figure 5: Site activation and deactivation
7.5. Inter-AS Support 7.5. Inter-AS Support
A solution SHOULD support inter-AS scenarios, where there is more A solution SHOULD support inter-AS scenarios, where there is more
than one provider providing a common VPMS instance and VPN. More than one provider providing a common VPMS instance and VPN. More
specifically, it is necessary to consider the case where some of the specifically, it is necessary to consider the case where some of the
PEs that compose one VPMS belong to several different ASes. PEs that compose one VPMS belong to several different ASes.
7.6. Co-existence with Existing L2VPNs 7.6. Co-existence with Existing L2VPNs
A solution MUST co-exist with the existing L2VPNs (e.g., VPWS, VPLS) 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 across the same SP's network. A solution MUST NOT impede the
operation of auto-discovery and signalling mechanism that are already operation of auto-discovery and signaling mechanism that are already
supported by the PEs for those existing L2VPNs. supported by the PEs for those existing L2VPNs.
7.7. Operation, Administration and Maintenance 7.7. Operation, Administration and Maintenance
7.7.1. Fault Management 7.7.1. Fault Management
7.7.1.1. Fault Detection 7.7.1.1. Fault Detection
A solution MUST provide tools that detect reachability failure and A solution MUST provide tools that detect reachability failure and
traffic looping of P2MP transport in a VPMS instance. If multiple traffic looping of data transport in a VPMS instance. If multiple
sources are supported (i.e., multiple P2MP topologies are grouped root ACs are supported (i.e., multiple P2MP connections are grouped
together into a single VPMS instance), such tools MUST be able to together into a single VPMS instance), such tools MUST be able to
perform distinguishing each P2MP topology. perform distinguishing each P2MP connection.
7.7.1.2. Fault Notification 7.7.1.2. Fault Notification
A solution MUST provide fault notification and trouble tracking A solution MUST provide fault notification and trouble tracking
mechanisms. (e.g. SNMP-trap and syslog that notify fault to remote mechanisms. (e.g. SNMP-trap and syslog that notify fault to remote
NMS.) NMS.)
In VPMS one point of failure at upstream often affects a number of In VPMS one point of failure at upstream often affects a number of
downstream PEs and ACs that might raise a notification message. downstream PEs and ACs that might raise a notification message.
Hence notification messages MAY be summarized or compressed for Hence notification messages MAY be summarized or compressed for
operators' ease of management. operators' ease of management.
In case of receiver-side failure (receiver PE or its AC), this fault In case of receiver-side failure (leaf PE or its AC), this fault
status SHOULD be able to be monitored at sender PE. This will help status SHOULD be able to be monitored at root PE. This will help an
an operator to monitor each receiver PEs/AC in a centralized manner; operator to monitor each leaf PE/AC in a centralized manner; that is,
that is, a sender PE can collect receiver-side information. How this a root PE can collect leaf-side information. How this status is
status is transferred depends on a solution. transferred depends on a solution.
In contrast, in case of sender-side failure (sender PE or its AC), In contrast, in case of sender-side failure (root PE or its AC), this
this fault status SHOULD also be able to be monitored at receiver fault status SHOULD also be able to be monitored at leaf PEs. This
PEs. This will help an operator to troubleshoot at receiver PEs will help an operator to troubleshoot at leaf PEs (i.e., distinguish
(i.e., distinguish local AC's failure from remote upstream AC's local AC's failure from remote root AC's failure easily).
failure easily).
In any case of failure at SP's network, fault information MAY be In any case of failure at SP's network, fault information MAY be
notified to the customer. Specifically, such fault MAY trigger notified to the customer. Specifically, such fault MAY trigger
generating customer OAM message toward CEs (e.g., AIS) and/or generating customer OAM message toward CEs (e.g., AIS) and/or
shutting down receiver ACs. shutting down leaf ACs.
7.7.1.3. Fault Isolation 7.7.1.3. Fault Isolation
A solution MUST provide diagnostic/troubleshooting tools for P2MP A solution MUST provide diagnostic/troubleshooting tools for data
transport in a VPMS instance. transport in a VPMS instance.
7.7.2. Testing 7.7.2. Testing
A solution MUST provide a mechanism for testing each P2MP A solution MUST provide a mechanism for testing each data
connectivity and verifying the associated information in a VPMS connectivity and verifying the associated information in a VPMS
instance. The connectivity is between sender and all receiver ACs. 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. 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 data test and MAY support CE-to-CE path test. In either case the minimum
path provided 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.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 7.7.3. Performance Management
A solution MUST offer mechanisms to monitor traffic performance A solution MUST offer mechanisms to monitor traffic performance
parameters and statistics in each P2MP traffic. parameters and statistics of data traffic in VPMS.
A solution MUST provide access to: A solution MUST provide access to:
- Traffic statistics (total traffic forwarded, incoming, outgoing, - Traffic statistics (total traffic forwarded, incoming, outgoing,
dropped, etc., by period of time) dropped, etc., by period of time)
A solution SHOULD provide access to: A solution SHOULD provide access to:
- Performance information related to traffic usage, e.g., one-way - Performance information related to traffic usage, e.g., one-way
delay, one-way jitter, one-way loss, delay variations (the delay, one-way jitter, one-way loss, delay variations (the
difference of various one-way delay from a particular sender PE to difference of various one-way delay from a particular root PE to
multiple receiver PEs) etc. multiple leaf PEs) etc.
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
skipping to change at page 22, line 12 skipping to change at page 24, line 25
Security consideration will be covered by section 6.5. and section Security consideration will be covered by section 6.5. and section
7.8. (This is for further study for next revision.) 7.8. (This is for further study for next revision.)
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 valuable review and feedback. 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. References
11.1. Normative References 11.1. Normative References
[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.
 End of changes. 80 change blocks. 
361 lines changed or deleted 436 lines changed or added

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