draft-ietf-l2vpn-vpms-frmwk-requirements-03.txt   draft-ietf-l2vpn-vpms-frmwk-requirements-04.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 13, 2011 France Telecom Expires: January 12, 2012 France Telecom
B. Niven-Jenkins B. Niven-Jenkins
Velocix Velocix
D. Brungard D. Brungard
AT&T AT&T
L. Jin L. Jin
ZTE ZTE
July 12, 2010 July 11, 2011
Framework and Requirements for Virtual Private Multicast Service (VPMS) Framework and Requirements for Virtual Private Multicast Service (VPMS)
draft-ietf-l2vpn-vpms-frmwk-requirements-03.txt draft-ietf-l2vpn-vpms-frmwk-requirements-04.txt
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.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 13, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 38 skipping to change at page 2, line 38
4.2.1. ATM-based multicast stream . . . . . . . . . . . . . . 7 4.2.1. ATM-based multicast stream . . . . . . . . . . . . . . 7
4.3. TDM-based Use Case . . . . . . . . . . . . . . . . . . . . 8 4.3. TDM-based Use Case . . . . . . . . . . . . . . . . . . . . 8
4.3.1. TDM-based multicast stream . . . . . . . . . . . . . . 8 4.3.1. TDM-based multicast stream . . . . . . . . . . . . . . 8
5. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 8 5. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 8
6. Customer Requirements . . . . . . . . . . . . . . . . . . . . 10 6. Customer Requirements . . . . . . . . . . . . . . . . . . . . 10
6.1. Service Topology . . . . . . . . . . . . . . . . . . . . . 10 6.1. Service Topology . . . . . . . . . . . . . . . . . . . . . 10
6.1.1. Point-to-Multipoint Traffic Support . . . . . . . . . 10 6.1.1. Point-to-Multipoint Traffic Support . . . . . . . . . 10
6.1.2. Reverse Traffic Support . . . . . . . . . . . . . . . 10 6.1.2. Reverse Traffic Support . . . . . . . . . . . . . . . 10
6.2. Transparency . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Transparency . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . . 13 6.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . . 13
6.4. High Availability . . . . . . . . . . . . . . . . . . . . 13 6.4. Multi-Source Support . . . . . . . . . . . . . . . . . . . 13
6.4.1. Dual-homed Access Support . . . . . . . . . . . . . . 13 6.5. High Availability . . . . . . . . . . . . . . . . . . . . 14
6.4.2. Single/Dual Traffic Support in Dual-homed Access . . . 16 6.5.1. Dual-homed Access Support . . . . . . . . . . . . . . 14
6.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.5.2. Single/Dual Traffic Support in Dual-homed Access . . . 17
6.6. Reordering Prevention . . . . . . . . . . . . . . . . . . 17 6.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.7. Failure reporting . . . . . . . . . . . . . . . . . . . . 17 6.7. Reordering Prevention . . . . . . . . . . . . . . . . . . 17
7. Service Provider Network Requirements . . . . . . . . . . . . 17 6.8. Failure reporting . . . . . . . . . . . . . . . . . . . . 17
7.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 17 7. Service Provider Network Requirements . . . . . . . . . . . . 18
7.2. Pseudo Wire Signaling and PSN Tunneling . . . . . . . . . 17 7.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 18
7.3. Auto-discovery . . . . . . . . . . . . . . . . . . . . . . 18 7.2. Pseudo Wire Signaling and PSN Tunneling . . . . . . . . . 18
7.4. Activation and Deactivation . . . . . . . . . . . . . . . 19 7.3. Auto-discovery . . . . . . . . . . . . . . . . . . . . . . 19
7.5. Inter-AS Support . . . . . . . . . . . . . . . . . . . . . 21 7.4. Activation and Deactivation . . . . . . . . . . . . . . . 20
7.6. Co-existence with Existing L2VPNs . . . . . . . . . . . . 21 7.5. Inter-AS Support . . . . . . . . . . . . . . . . . . . . . 22
7.6. Co-existence with Existing L2VPNs . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . . . . 22 7.7.2. Testing . . . . . . . . . . . . . . . . . . . . . . . 23
7.7.3. Performance Management . . . . . . . . . . . . . . . . 23 7.7.3. Performance Management . . . . . . . . . . . . . . . . 23
7.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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
skipping to change at page 10, line 27 skipping to change at page 10, line 27
PW. See section 7.2.). P2MP traffic optimization will provide the PW. See section 7.2.). P2MP traffic optimization will provide the
benefit of traffic replication for high bandwidth efficiency. That benefit of traffic replication for high bandwidth efficiency. That
is, the sender CE has only to transmit one stream towards the PE and is, the sender CE has only to transmit one stream towards the PE and
it does not have to replicate traffic. it does not have to replicate traffic.
Regarding end-to-end traffic topology between the ACs, a single VPMS Regarding end-to-end traffic topology between the ACs, a single VPMS
instance (i.e., one VPN) may correspond to a single P2MP connection. 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 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 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 consists of two or more P2MP connections grouped, which is typically
used for redundancy. The details are given in section 6.4. used for multi-source or redundancy. The details are given in
section 6.4 and 6.5.
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 Traffic Support 6.1.1. Point-to-Multipoint Traffic Support
skipping to change at page 13, line 24 skipping to change at page 13, line 24
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
for service class differentiation, such as IEEE 802.1p CoS for for service class differentiation, such as IEEE 802.1p CoS 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. High Availability 6.4. Multi-Source Support
A VPMS solution SHOULD support multiple sources in each VPN. That
is, two or more sender CEs can exist in the same VPMS instance. Each
sender CE SHOULD be able to be connected to physically separate root
PEs, which will facilitate flexible topology design.
Additionally, traffic from sender CEs MAY have a common single
coverage to receiver CEs, i.e., data from any sources can reach the
same group of receivers. For example, in TV provisioning scenario,
customers may need to receive two or more TV channels from different
sources. In figure 3, suppose there are 7 hosts, CE1 to CE7 which
belong to a given VPMS instance A. CE1, CE2 and CE3 are common
sources of this VPN, and are attached to different PEs respectively.
Traffic from each source can reach the same group of receivers, CE4
to CE7.
This kind of scenario will require multiple P2MP connections in a
single VPMS instance (i.e., VPN). Each P2MP connection's root might
be a completely different CE/AC, but leaf CE/ACs are overlapped.
Since this is basically the same requirement as dual-homed scenario,
see section 6.5.1 for details.
VPMS A +-----+ +-----+ VPMS A
Sender | CE1 | | CE2 | Sender
+-----+ +-----+
| |
+-----+ VPMS A v AC1 v AC2
| CE3 | Sender +----+ +----+
+-----+ -----|VPMS|-----|VPMS|-----
\ | | PE1| | PE2| |
\ | +----+ +----+ |
\ | |
\ AC3 +----+ +----+
+---->|VPMS| |VPMS| AC5 VPMS A
| PE3| Routed | PE4|-----+ Receiver
+----+ Backbone +----+ | +-----+
/ | | \ +-->| CE5 |
AC4 / | | \ +-----+
/ | | \ AC6
+-----+ / | +----+ | \ +-----+
| CE4 |<--+ -----------|VPMS|---------- +->| CE6 |
+-----+ | PE5| +-----+
VPMS A +----+ VPMS A
Receiver | AC7 Receiver
v
+-----+
| CE7 | VPMS A
+-----+ Receiver
Figure 3: Multi-Source support
6.5. 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 covers the requirements for redundancy support for (1) subsections covers the requirements for redundancy support for (1)
and (2). and (2).
6.4.1. Dual-homed Access Support 6.5.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 4 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 14, line 33 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 3: Dual-homing support Figure 4: Dual-homing support
A solution SHOULD provide a protection mechanism between the A solution SHOULD provide a protection mechanism between the
redundant PEs to which a CE is dual-homed. This is because when an 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 ingress root PE node fails whole traffic delivery will fail unless a
backup root PE is provided, even in case of dual-homed access. 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 Similarly, if an egress leaf PE node fails, traffic toward that CE is
never received unless a backup leaf PE is provided. never received unless a backup leaf PE is provided.
In some cases, the data source is required to be highly reliable In some cases, the data source is required to be highly reliable
since it is often deployed as a centralized server that provides since it is often deployed as a centralized server that provides
traffic to many receivers. Therefore, there is an additional traffic to many receivers. Therefore, there is an additional
requirement specifically about redundancy of root-side: each VPMS requirement specifically about redundancy of root-side: each VPMS
instance SHOULD be able to have multiple P2MP connections whose roots instance SHOULD be able to have multiple P2MP connections whose roots
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 5, 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. In this figure, each leaf PE traffic from either root, PE1 or PE2. In this figure, each leaf PE
has one leaf AC only (AC3 attached to PE3, and AC4 attached to PE4). has one leaf AC only (AC3 attached to PE3, and AC4 attached to PE4).
Therefore, PEs will need to support PW protection and restoration Therefore, PEs will need to support PW protection and restoration
mechanism so that two redundant P2MP connections are given among mechanism so that two redundant P2MP connections are given among
common ACs. common ACs.
+-----+ AC2 +-----+ AC2
skipping to change at page 15, line 45 skipping to change at page 16, line 45
+--------+ +--------+ +--------+ +--------+
v v v v
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 5: Multiple P2MP connections in Dual-homed Sender
Note, if the solution supports dual-homed sender scenario that
provides multiple root ACs, it is expected that such a mechanism can
also be used in a multi-source scenrio. For example, suppose in TV
provisioning scenario, a leaf (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. 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.5.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 such forwarding capability without any switchover functionality. In such
a dual traffic case, the backup root (ingress) PE SHOULD be able to a 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
skipping to change at page 16, line 39 skipping to change at page 17, line 30
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 case of failure. mechanism between egress PEs in case of failure.
6.5. Security 6.6. Security
The basic security requirements from the view of customers are raised The basic security requirements from the view of customers are raised
in section 6.5 of [RFC4665]. It 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 control mechanism between etc.), and it MAY be added with the control mechanism 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.7. 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.8. 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
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
skipping to change at page 19, line 48 skipping to change at page 20, line 33
the VPN. the VPN.
7.4. Activation and Deactivation 7.4. Activation and Deactivation
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, an SP administrative status of each AC. After initial provisioning, an 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 6, 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.
However, for maintenance operation, application's request (e.g., However, for maintenance operation, application's request (e.g.,
stream program has changed) or some other reasons, AC4 needs to be stream program has changed) or some other reasons, AC4 needs to be
set as administratively deactivated. Then it becomes necessary to set as administratively deactivated. Then it becomes necessary to
turn off traffic from PE4 to CE4. This operation must be turn off traffic from PE4 to CE4. This operation must 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, AC3 is now administratively activated and receiving Figure 6, AC3 is now administratively activated and receiving
traffic. However, if AC3 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 root (ingress) PE. In some scenarios, operators operation at a root (ingress) PE. In some scenarios, operators
prefer centralized operation. This is often considered natural for prefer centralized operation. This is often considered natural for
one-way digital audio/video distribution applications: SPs often want one-way digital audio/video distribution applications: SPs often want
to complete their service delivery by a single operation at one to complete their service delivery by a single operation at one
source PE, not by multiple operations at many leaf (egress) PEs. source PE, not by multiple operations at many leaf (egress) PEs.
Figure 5 illustrates this scenario, where a SP only has to do single- Figure 6 illustrates this scenario, where a SP only has to do single-
sided operation at PE1 (source) to administratively activate/ sided operation at PE1 (source) to administratively activate/
deactivate various connections from AC1 to AC3, AC4 and/or AC5. It deactivate various connections from AC1 to AC3, AC4 and/or AC5. It
is not 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
+----+ +----+
skipping to change at page 21, line 38 skipping to change at page 21, line 47
+-----+ +-----+ +-----+ +-----+
VPMS A Receiver VPMS A Receiver VPMS A Receiver VPMS A Receiver
(receiving now) (not receiving) (receiving now) (not receiving)
AC1: Administratively activated AC1: Administratively activated
AC2: No VPMS provisioned AC2: No VPMS provisioned
AC3: Administratively activated AC3: Administratively activated
AC4: Administratively deactivated AC4: Administratively deactivated
AC5: Administratively activated AC5: Administratively activated
Figure 5: Site activation and deactivation Figure 6: 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
skipping to change at page 25, line 15 skipping to change at page 25, line 30
[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., and L. Fang, "Multicast in
"Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-06 (work VPLS", draft-ietf-l2vpn-vpls-mcast-09 (work in progress),
in progress), March 2010. July 2011.
[I-D.ietf-pwe3-p2mp-pw-requirements] [I-D.ietf-pwe3-p2mp-pw-requirements]
Heron, G., Wang, L., Aggarwal, R., Vigoureux, M., Bocci, Heron, G., Wang, L., Aggarwal, R., Vigoureux, M., Bocci,
M., Jin, L., JOUNAY, F., Niger, P., Kamite, Y., DeLord, M., Jin, L., JOUNAY, F., Niger, P., Kamite, Y., DeLord,
S., and L. Martini, "Requirements for Point-to-Multipoint S., and L. Martini, "Requirements and Framework for Point-
Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-02 (work to-Multipoint Pseudowire",
in progress), January 2010. draft-ietf-pwe3-p2mp-pw-requirements-04 (work in
progress), July 2011.
[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.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", (VPLS) Using BGP for Auto-Discovery and Signaling",
 End of changes. 28 change blocks. 
57 lines changed or deleted 99 lines changed or added

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