draft-ietf-l2vpn-vpms-frmwk-requirements-04.txt   draft-ietf-l2vpn-vpms-frmwk-requirements-05.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 12, 2012 France Telecom Expires: April 25, 2013 Orange CH
B. Niven-Jenkins B. Niven-Jenkins
Velocix Velocix
D. Brungard D. Brungard
AT&T AT&T
L. Jin L. Jin
ZTE ZTE
July 11, 2011 Oct 22, 2012
Framework and Requirements for Virtual Private Multicast Service (VPMS) Framework and Requirements for Virtual Private Multicast Service (VPMS)
draft-ietf-l2vpn-vpms-frmwk-requirements-04.txt draft-ietf-l2vpn-vpms-frmwk-requirements-05.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 12, 2012. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 43 skipping to change at page 2, line 43
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. Multi-Source Support . . . . . . . . . . . . . . . . . . . 13 6.4. Multi-Source Support . . . . . . . . . . . . . . . . . . . 13
6.5. High Availability . . . . . . . . . . . . . . . . . . . . 14 6.5. High Availability . . . . . . . . . . . . . . . . . . . . 14
6.5.1. Dual-homed Access Support . . . . . . . . . . . . . . 14 6.5.1. Dual-homed Access Support . . . . . . . . . . . . . . 14
6.5.2. Single/Dual Traffic Support in Dual-homed Access . . . 17 6.5.2. Single/Dual Traffic Support in Dual-homed Access . . . 17
6.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.7. Reordering Prevention . . . . . . . . . . . . . . . . . . 17 6.7. Misordering Prevention . . . . . . . . . . . . . . . . . . 17
6.8. Failure reporting . . . . . . . . . . . . . . . . . . . . 17 6.8. Failure reporting . . . . . . . . . . . . . . . . . . . . 17
7. Service Provider Network Requirements . . . . . . . . . . . . 18 7. Service Provider Network Requirements . . . . . . . . . . . . 18
7.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Pseudo Wire Signaling and PSN Tunneling . . . . . . . . . 18 7.2. Pseudo Wire Signaling and PSN Tunneling . . . . . . . . . 18
7.2.1. Point-to-Multipoint Pseudo Wire . . . . . . . . . . . 18
7.2.2. PSN Tunneling . . . . . . . . . . . . . . . . . . . . 19
7.2.3. Static Solution . . . . . . . . . . . . . . . . . . . 19
7.3. Auto-discovery . . . . . . . . . . . . . . . . . . . . . . 19 7.3. Auto-discovery . . . . . . . . . . . . . . . . . . . . . . 19
7.4. Activation and Deactivation . . . . . . . . . . . . . . . 20 7.4. Activation and Deactivation . . . . . . . . . . . . . . . 21
7.5. Inter-AS Support . . . . . . . . . . . . . . . . . . . . . 22 7.5. Inter-AS Support . . . . . . . . . . . . . . . . . . . . . 22
7.6. Co-existence with Existing L2VPNs . . . . . . . . . . . . 22 7.6. Co-existence with Existing L2VPNs . . . . . . . . . . . . 22
7.7. Operation, Administration and Maintenance . . . . . . . . 22 7.7. Operation, Administration and Maintenance . . . . . . . . 23
7.7.1. Fault Management . . . . . . . . . . . . . . . . . . . 22 7.7.1. Fault Management . . . . . . . . . . . . . . . . . . . 23
7.7.2. Testing . . . . . . . . . . . . . . . . . . . . . . . 23 7.7.2. Testing . . . . . . . . . . . . . . . . . . . . . . . 23
7.7.3. Performance Management . . . . . . . . . . . . . . . . 23 7.7.3. Performance Management . . . . . . . . . . . . . . . . 24
7.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
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, an 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 Pseudowires (PWs) independently and have the CEs replicate multiple Pseudowires (PWs) independently and have the CEs replicate
traffic over them, but this is not only inconvenient for the traffic over them, but this is not only inconvenient for the
customer, it's a 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
skipping to change at page 6, line 39 skipping to change at page 6, line 39
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 leaves is not allowed. connectivity is required, the traffic between leaf nodes is not
It might require extra efforts to guarantee this behavior in VPLS. allowed. It might require extra efforts to guarantee this behavior
And in some P2MP scenarios there no traffic from leafs to root. In in VPLS. And in some P2MP scenarios there no traffic from leafs to
these cases, VPMS is a service that provides much simpler operation. root. In 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 in one VPN. All traffic from a particular Attachment Circuit
be forwarded toward the same remote receivers, even if the (AC) will 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 by MAC address), VPLS should be
chosen rather than VPMS. chosen rather than VPMS.
4.1.2. Ethernet-based time/frequency synchronization 4.1.2. Ethernet-based time/frequency synchronization
Nowadays there exist several solutions to provide synchronization for Nowadays there exist several solutions to provide synchronization for
time and/or frequency reference by the packet-based technology of time and/or frequency reference by the packet-based technology of
Ethernet. For example, PTPv2 (Precision Time Protocol version 2) is Ethernet. For example, PTPv2 (Precision Time Protocol version 2) is
a time-transfer protocol defined in the IEEE 1588-2008 standard. It a time-transfer protocol defined in the IEEE 1588-2008 standard. It
provides precise synchronization of packet-based networks (e.g., provides precise synchronization of packet-based networks (e.g.,
Ethernet). It adopts two-way time transfer approach for Ethernet). It adopts two-way time transfer approach for
skipping to change at page 11, line 42 skipping to change at page 11, line 42
Unidirectional P2P connection is also provided for traffic in the Unidirectional P2P connection is also provided for traffic in the
reverse direction, from AC4 to AC1. Other reverse P2P connections reverse direction, from AC4 to AC1. Other reverse P2P connections
can be provided similarly. (from AC2 to AC1 / from AC3 to AC1). can be provided similarly. (from AC2 to AC1 / from AC3 to AC1).
In this case, PEs need to deal with two types of traffic, locally- In this case, PEs need to deal with two types of traffic, locally-
attached CE's sending (Tx) and receiving (Rx) flows. In Figure 3, attached CE's sending (Tx) and receiving (Rx) flows. In Figure 3,
they are both passing through the same physical PE-CE link (AC1 and they are both passing through the same physical PE-CE link (AC1 and
AC4 respectively). But it is an implementation matter if Tx and Rx AC4 respectively). But it is an implementation matter if Tx and Rx
traffic are conveyed on the same physical link or separate links. It traffic are conveyed on the same physical link or separate links. It
is also possible that a root PE multiplexes two ore more reverse is also possible that a root PE multiplexes two ore more reverse
traffic from different leaves and transmits it to an upstream CE over traffic from different leaf ACs and transmits it to an upstream CE
the same local physical link. over the same local physical link.
Note, in most implementations of VPWS today, every AC is always Note, in most implementations of VPWS today, every AC is always
considered bidirectional. In contrast, in VPMS, every AC can be considered bidirectional. In contrast, in VPMS, every AC can be
chosen unidirectional (if it is a totally unidirectional service), or chosen unidirectional (if it is a totally unidirectional service), or
bidirectional (if reverse traffic is supported). bidirectional (if reverse traffic is supported).
+-----+ <-- Rx (bidirectional) +-----+ <-- Rx (bidirectional)
| CE1 |--------------+ | CE1 |--------------+
+-----+ --> Tx | +-----+ --> Tx |
VPMS A Sender | VPMS A Sender |
skipping to change at page 12, line 48 skipping to change at page 12, line 48
Figure 3: Reverse traffic support Figure 3: Reverse traffic support
6.2. Transparency 6.2. Transparency
A solution is intended to provide Layer-2 traffic transparency. A solution is intended to provide Layer-2 traffic transparency.
Transparency SHOULD be supported per VPMS instance basis. In other Transparency SHOULD be supported per VPMS instance basis. In other
words, Layer-2 traffic can be transparently transported from a local words, Layer-2 traffic can be transparently transported from a local
CE to remote CEs in a given instance. Note, however, if service CE to remote CEs in a given instance. Note, however, if service
delimiting fields (VLAN Id in Ethernet, VPI/VCI in ATM, DLCI in FR delimiting fields (VLAN Id in Ethernet, VPI/VCI in ATM, DLCI in FR
etc.) are assigned by the SP, the Layer-2 traffic is not necessarily etc.) are assigned and possibly can be changed by the SP, the Layer-2
transparent. It will depend on the SP's choice if they assign it to traffic is not necessarily transparent. It will depend on the SP's
each AC. Hence, it could be that some of the leaf CEs are receiving choice if they assign it to each AC. Hence, it could be that some of
traffic that has different delimiting fields than the traffic for the the leaf CEs are receiving traffic that has different delimiting
other leaf CEs. Hence, it could be that some of receiver CEs are fields than the traffic for the other leaf CEs.
getting traffic with different delimiting fields than the other
receiver CEs.
The VPMS solution SHOULD NOT require any special packet processing by The VPMS solution SHOULD NOT require any special packet processing by
the end users (CEs). the end users (CEs).
6.3. Quality of Service (QoS) 6.3. Quality of Service (QoS)
A customer may require that the VPMS service provide guaranteed QoS. A customer may require that the VPMS service provide guaranteed QoS.
In particular, for real time applications which are considered common In particular, for real time applications which are considered common
in point-to-multipoint delivery, delay and loss sensitive traffic in point-to-multipoint delivery, delay and loss sensitive traffic
MUST be supported. The solution SHOULD provide native QoS techniques MUST be supported. The solution SHOULD provide native QoS techniques
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 (Constant Bit Rate)),
guarantee end-to-end bandwidth. It MAY provide flow admission a solution SHOULD guarantee end-to-end bandwidth. It MAY provide
control mechanisms to achieve that. flow admission control mechanisms to achieve that.
6.4. Multi-Source Support 6.4. Multi-Source Support
A VPMS solution SHOULD support multiple sources in each VPN. That 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 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 sender CE SHOULD be able to be connected to physically separate root
PEs, which will facilitate flexible topology design. PEs, which will facilitate flexible topology design.
Additionally, traffic from sender CEs MAY have a common single Additionally, traffic from sender CEs MAY have a common single
coverage to receiver CEs, i.e., data from any sources can reach the coverage to receiver CEs, i.e., data from any sources can reach the
skipping to change at page 15, line 51 skipping to change at page 15, line 51
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. VPMS (i.e, VPN).
For example, in Figure 5, 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.
skipping to change at page 17, line 42 skipping to change at page 17, line 42
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.7. Reordering Prevention 6.7. Misordering Prevention
A solution SHOULD prevent Layer-2 frame reordering when delivering A solution SHOULD prevent Layer-2 frame misordering when delivering
customer traffic under normal conditions. customer traffic under normal conditions. This is often necessary
for real-time based applications.
6.8. 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
skipping to change at page 18, line 36 skipping to change at page 18, line 36
PWs (neighborhood or session maintenance messages, keepalives, PWs (neighborhood or session maintenance messages, keepalives,
timers, etc.) timers, etc.)
- the processing resources required by the control plane in managing - the processing resources required by the control plane in managing
PSN tunnels PSN tunnels
- the memory resources needed for the control plane - the memory resources needed for the control plane
- other particular elements inherent to each solution that impact - other particular elements inherent to each solution that impact
scalability scalability
7.2. Pseudo Wire Signaling and PSN Tunneling 7.2. Pseudo Wire Signaling and PSN Tunneling
As for data plane format and its processing procedures, VPMS solution
MUST support encapsulation scheme that is based on the existing
standard PW architecture [RFC3985].
A VPMS solution SHOULD provide an efficient replication that can A VPMS solution SHOULD provide an efficient replication that can
contribute to optimizing the bandwidth usage required in a SP's contribute to optimizing the bandwidth usage required in a SP's
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.
7.2.1. Point-to-Multipoint Pseudo Wire
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 (i.e., inner label layer). In either case, end-to-end P2MP topology (i.e.,
P2MP connection) in VPMS is common from the view of ACs. P2MP connection) in VPMS is common from the view of ACs.
Requirements as a provider service specified in this document will be Requirements as a provider service specified in this document will be
commonly applied regardless of P2MP PW's signaling model. commonly applied regardless of P2MP PW's model.
It is out of scope of this document how to extend and use PW It is out of scope of this document how to extend and use PW
mechanisms to realize P2MP connections. For example, it is under the mechanisms to realize P2MP connections as a solution. For example,
scope of the solution work how to support forward/reverse traffic it is under the scope of the solution work how to support forward/
e.g., by a single PW signaling, coupling multiple PWs, or other ways. reverse traffic by a single PW signaling, coupling multiple PWs, or
other ways.
This document does not raise any specific requirements for particular 7.2.2. PSN Tunneling
PSN tunneling schemes (point-to-point, point-to-multipoint and
multipoint-to-multipoint) that are applied to VPMS. The actual type Today, there are several standardized PSN tunneling schemes and their
of PSN tunnel used in VPMS will be dependent on individual deployment control plane protocols that support efficient multicast data
scenarios (e.g., which PSN protocol is available in the core and how replication in MPLS, such as P2MP RSVP-TE [RFC4875] and MLDP
much of the network resources that operators will want to optimize). [RFC6388].
In general, this document does not restrict which control plane
protocols should be mandatory. There is no mandatory limitation
either, about a particular type of data replication topology in PSN
tunneling (point-to-point, point-to-multipoint and multipoint-to-
multipoint).
In VPMS, the preferred type of PSN tunneling will depend on each
deployment scenario. (e.g., which control plane protocol is available
in the core and how much of the network resources that operators will
want to optimize). The detailed mechanism needs to be specified by
solution work.
7.2.3. Static Solution
VPMS solution MAY support static provisioning for PWs and/or PSN
tunneling. Due to some operational reasons, there is a scenario
where control plane protocol is not used between PSN nodes. In this
case, operators will need to have a different method to set up PWs
and/or PSN tunnels (e.g., by manual configuration or other outband
interfaces).
7.3. Auto-discovery 7.3. Auto-discovery
A solution SHOULD support auto-discovery methods that dynamically A solution SHOULD support auto-discovery methods that dynamically
allow VPMS related information to be discovered by the PEs to allow VPMS related information to be discovered by the PEs to
minimize the amount of configuration the SP must perform. minimize the amount of configuration the SP must perform.
All of the requirements on discovery described in Section 7.3 of All of the requirements on discovery described in Section 7.3 of
[RFC4665] SHOULD be satisfied in VPMS as well. [RFC4665] SHOULD be satisfied in VPMS as well.
skipping to change at page 19, line 46 skipping to change at page 20, line 25
VPN VPN
- Information to identify the type of ACs (root AC or leaf AC) - Information to identify the type of ACs (root AC or leaf AC)
- Information to identify the P2MP connection that binds ACs - Information to identify the P2MP connection that binds ACs
- Information to show if reverse traffic support is optionally - Information to show if reverse traffic support is optionally
desired desired
- SP-related information (AS number, etc. for an inter-provider - SP-related information (AS number, etc. for an inter-provider
case) case)
Following is an example scenario about adding a new leaf PE: suppose Following is an example scenario about adding a new leaf PE: suppose
there are three PEs in an existing VPMS, PE1, PE2, PE3. PE1 is a there are three PEs in an existing VPMS, PE1, PE2, PE3. PE1 is a
root PE and has a AC1. PE2 and PE3 are leaves and have AC2 and AC3. root PE and has a AC1. PE2 and PE3 are leaf PEs and have AC2 and
every PE has the association among the information described above. AC3. every PE has the association among the information described
Now a new PE4 having an AC4 is provisioned in the existing VPMS above. Now a new PE4 having an AC4 is provisioned in the existing
instance and this AC is configured as leaf. This information will be VPMS instance and this AC is configured as leaf. This information
automatically discovered by the other existing remote PEs (i.e., will be automatically discovered by the other existing remote PEs
ingress and egress PEs in the same VPMS instance). Once the ingress (i.e., ingress and egress PEs in the same VPMS instance). Once the
PE1 discovers this new PE/AC, it can automatically add AC4 as the new ingress PE1 discovers this new PE/AC, it can automatically add AC4 as
leaf of P2MP connection topology according to P2MP PW signaling the new leaf of P2MP connection topology according to P2MP PW
mechanism. The ingress PE1 will graft a new leaf (PE4) to the signaling mechanism. The ingress PE1 will graft a new leaf (PE4) to
already existing P2MP connection which is now created from AC1 to the already existing P2MP connection which is now created from AC1 to
AC2/AC3/AC4. This operation does not require any new configuration AC2/AC3/AC4. This operation does not require any new configuration
at the existing PEs. at the existing PEs.
Another example is about adding a new root PE: suppose there are one Another example is about adding a new root PE: suppose there are one
root PE (PE1/AC1) and three leaf PEs (PE2/AC2, PE3/AC3 and PE4/AC4). root PE (PE1/AC1) and three leaf PEs (PE2/AC2, PE3/AC3 and PE4/AC4).
There is an existing P2MP connection from AC1 to AC2/AC3/AC4. Now There is an existing P2MP connection from AC1 to AC2/AC3/AC4. Now
the operator adds a new root PE/AC (PE5/AC5) for some reasons (e.g., the operator adds a new root PE/AC (PE5/AC5) for some reasons (e.g.,
multiple source sites, dual-homed access, root PE redundancy etc.). multiple source sites, dual-homed access, root PE redundancy etc.).
Then, auto-discovery mechanism advertises this information to all Then, auto-discovery mechanism advertises this information to all
other members PE1/PE2/PE3/PE4, and a new P2MP connection from AC5 to other members PE1/PE2/PE3/PE4, and a new P2MP connection from AC5 to
skipping to change at page 25, line 18 skipping to change at page 26, line 4
10. Acknowledgments 10. Acknowledgments
Many thanks to Ichiro Fukuda, Kazuhiro Fujihara, Ukyo Yamaguchi and Many thanks to Ichiro Fukuda, Kazuhiro Fujihara, Ukyo Yamaguchi and
Kensuke Shindome for their ideas and feedback in documentation. Kensuke Shindome for their ideas and feedback in documentation.
The authors gratefully acknowledge the valuable review and comments The authors gratefully acknowledge the valuable review and comments
provided by Greg Mirsky and Yuji Tochio. 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.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[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., and L. Fang, "Multicast in Aggarwal, R., Rekhter, Y., Kamite, Y., and L. Fang,
VPLS", draft-ietf-l2vpn-vpls-mcast-09 (work in progress), "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-11 (work
July 2011. in progress), July 2012.
[I-D.ietf-pwe3-p2mp-pw-requirements] [I-D.ietf-pwe3-p2mp-pw-requirements]
Heron, G., Wang, L., Aggarwal, R., Vigoureux, M., Bocci, Bocci, M., Heron, G., and Y. Kamite, "Requirements and
M., Jin, L., JOUNAY, F., Niger, P., Kamite, Y., DeLord, Framework for Point-to-Multipoint Pseudowires over MPLS
S., and L. Martini, "Requirements and Framework for Point- PSNs", draft-ietf-pwe3-p2mp-pw-requirements-05 (work in
to-Multipoint Pseudowire", progress), September 2011.
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",
RFC 4761, January 2007. RFC 4761, January 2007.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling", (VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007. RFC 4762, January 2007.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011.
Authors' Addresses Authors' Addresses
Yuji Kamite Yuji Kamite
NTT Communications Corporation NTT Communications Corporation
Granpark Tower Granpark Tower
3-4-1 Shibaura, Minato-ku 3-4-1 Shibaura, Minato-ku
Tokyo 108-8118 Tokyo 108-8118
Japan Japan
Email: y.kamite@ntt.com Email: y.kamite@ntt.com
Frederic Jounay Frederic Jounay
France Telecom Orange CH
2, avenue Pierre-Marzin 4 rue caudray 1020 Renens
22307 Lannion Cedex
France France
Email: frederic.jounay@orange-ftgroup.com Email: frederic.jounay@orange.ch
Ben Niven-Jenkins Ben Niven-Jenkins
Velocix Velocix
326 Cambridge Science Park 326 Cambridge Science Park
Milton Road, Cambridge Milton Road, Cambridge
CB4 0WG CB4 0WG
UK UK
Email: ben@niven-jenkins.co.uk Email: ben@niven-jenkins.co.uk
 End of changes. 35 change blocks. 
73 lines changed or deleted 113 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/