wdiff rfc7338.alt-original rfc7338.txt

Network Working Group
Internet Engineering Task Force (IETF) F. Jounay, Ed.
Internet-Draft
Request for Comments: 7338 Orange CH
Category: Informational Y. Kamite, Ed.
Expires: December 20, 2014
ISSN: 2070-1721 NTT Communications
G. Heron
Cisco Systems
M. Bocci
Alcatel-Lucent
June 20,
August 2014

Requirements and Framework for Point-to-Multipoint Pseudowires
over MPLS Packet Switched Networks

draft-ietf-pwe3-p2mp-pw-requirements-10.txt

Abstract

This document presents a set of requirements and a framework for
providing a Point-to-Multipoint Pseudowire point-to-multipoint pseudowire (PW) over MPLS Packet
Switched Networks. The requirements identified in this document are
related to architecture, signaling signaling, and maintenance aspects of Point-
to-Multipoint point-
to-multipoint PW operation. They are proposed as guidelines for the
standardization of such mechanisms. Among other potential
applications, Point-to-Multipoint point-to-multipoint PWs can be used to optimize the
support of multicast layer Layer 2 services (Virtual Private LAN Service
and Virtual Private Multicast Service).

Status of This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a maximum candidate for any level of Internet
Standard; see Section 2 of six months RFC 5741.

Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 20, 2014.
http://www.rfc-editor.org/info/rfc7338.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document MUST must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

Table of Contents

1. Introduction.....................................................3 Introduction ....................................................3
1.1. Problem Statement........................................... 3 Statement ..........................................3
1.2. Scope of this document...................................... 3 This Document .....................................4
1.3. Conventions used Used in this document........................... 4 This Document ..........................4
2. Definition...................................................... 4 Definitions .....................................................4
2.1. Acronyms.................................................... 4 Acronyms ...................................................4
2.2. Terminology ................................................ 4 ................................................5
3. P2MP PW Requirements.............................................5 Requirements ............................................5
3.1. Reference Model............................................. 5 Model ............................................5
3.2. P2MP PW and Underlying Layer ............................... 7 ...............................7
3.3. P2MP PW Construction........................................ 9 Construction .......................................9
3.4. P2MP PW Signaling Requirements.............................. 9 Requirements ............................10
3.4.1. P2MP PW Identifier........................................... 9 Identifier .................................10
3.4.2. PW type mismatch ....................................... 9 Type Mismatch ...................................10
3.4.3. Interface Parameters sub-TLV............................ 9 Sub-TLV .......................10
3.4.4. Leaf Grafting/Pruning ..................................10 ..............................10
3.4.5. Failure Detection and Reporting.........................10 Reporting ....................10
3.4.6. Protection and Restoration..............................11 Restoration .........................11
3.4.7. Scalability.............................................12 Scalability ........................................13
4. Backward Compatibility..........................................12 Compatibility .........................................13
5. Security Considerations.........................................13 Considerations ........................................13
6. IANA Considerations.............................................13
7. Contributing Authors............................................13
8. Acknowledgments.................................................14
9. References......................................................15
9.1. References .....................................................14
6.1. Normative References........................................15
9.2. References ......................................14
6.2. Informative References......................................15 References ....................................15
7. Acknowledgments ................................................16
8. Contributors ...................................................16

1. Introduction

1.1. Problem Statement

As defined in the pseudowire architecture [RFC3985], a Pseudowire pseudowire
(PW) is a mechanism that emulates the essential attributes of a
telecommunications service (such as a T1 leased line or Frame Relay)
over an IP or MPLS Packet Switched Network. Network (PSN). It provides a
single service which that is perceived by its user as an unshared link or
circuit of the chosen service. A Pseudowire pseudowire is used to transport layer
Layer 1 or
layer Layer 2 traffic (e.g. (e.g., Ethernet, TDM, Time-Division
Multiplexing (TDM), ATM, and FR) Frame Relay) over a layer Layer 3 PSN.
Pseudowire Emulation Edge-to-Edge (PWE3) operates "edge to edge" to
provide the required connectivity between the two endpoints of the
PW.

The Point-to-Multipoint point-to-multipoint (P2MP) topology described in
[I-D.ietf-l2vpn-vpms-frmwk-requirements] [VPMS-REQS] and
required to provide P2MP
Layer2 Layer 2 VPN service can be achieved using
one or more P2MP PWs. The use of PW encapsulation enables P2MP
services transporting layer1 to transport Layer 1 or layer2 Layer 2 data. This could be
achieved using a set of point to point point-to-point PWs, with traffic replication on
at the Root Provider Edge (PE), but at the cost of bandwidth
efficiency, as duplicate traffic would be carried multiple times on
shared links.

This document defines the requirements for a Point-to-Multipoint point-to-multipoint PW
(P2MP PW). A P2MP PW is a mechanism that emulates the essential
attributes of a P2MP telecommunications service such as a P2MP ATM
VC
Virtual Circuit over a Packet Switch Networks. Switched Network.

The required functions of P2MP PWs include encapsulating
service-specific service-
specific Protocol data Data Units (PDU) (PDUs) arriving at an ingress Attachment
Circuit (AC), and carrying them across a tunnel to one or more egress
ACs, managing their timing and order, and any other operations
required to emulate the behavior and characteristics of the service
as faithfully as possible.

1.2. Scope of this document This Document

The document describes the general architecture of P2MP PW with a
reference model, mentions the notion of data encapsulation, and
outlines specific requirements for the setup and maintenance of a
P2MP PW. In this document, the requirements focus on the Single-
Segment PW model. It is The requirements for further study how it should be realized realizing P2MP PW in the
Multi-Segment PW model. For model are left for further study. This document
refers to [RFC3916] for other aspects of P2MP PW implementation, such
as packet processing (section 4) "Packet Processing" (Section 4 of that document) and
Faithfulness "Faithfulness
of Emulated Services (section 7), the document refers to
[RFC3916]. Services" (Section 7 of that document).

1.3. Conventions used Used in this document This Document

Although this is a requirements specification not a protocol
specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted to apply to
protocol solutions designed to meet these requirements as described
in [RFC2119] . [RFC2119].

2. Definition Definitions

2.1. Acronyms

P2P: Point-to-Point
P2MP: Point-to-Multipoint
PW: Pseudowire
PSN: Packet Switched Network
SS-PW: Single-Segment Pseudowire
MS-PW: Multi-Segment Pseudowire

2.2. Terminology

This document uses terminology described in [RFC5659]. It also
introduces additional terms needed in the context of P2MP PW.

P2MP PW, PW (also referred to as PW Tree): tree):
Point-to-Multipoint Pseudowire. A PW attached to a source
Customer Edge (CE) used to distribute Layer1 Layer 1 or Layer2 Layer 2 traffic
to a set of one or more receiver CEs. The P2MP PW is
unidirectional (i.e., carrying traffic from Root PE to Leaf
PEs), PEs)
and optionally supports a return path.

P2MP SS-PW:
Point-to-Multipoint Single-Segment Pseudowire. A single
segment single-segment
P2MP PW set up between the Root PE attached to the source CE and
the Leaf PEs attached to the receiver CEs. The P2MP SS-PW uses
P2MP Label Switched Paths (LSP) (LSPs) as PSN tunnels.
The requirements in this document is targeted for SS-PW model.
Application of MS-PW (Multi-segment PW) model [RFC5254] is out
of scope and left for future work.

Root PE:
P2MP PW Root Provider Edge. The PE attached to the traffic source
CE for the P2MP PW via an Attachment Circuit (AC).

Leaf PE:
P2MP PW Leaf Provider Edge. A PE attached to a set of one or more
traffic receiver CEs, via ACs. The Leaf PE replicates traffic to
the CEs based on its Forwarder function [RFC3985].

P2MP PSN Tunnel:
In the P2MP SS-PW topology, The the PSN Tunnel tunnel is a general term
indicating a virtual P2MP connection between the Root PE and the
Leaf PEs. A P2MP tunnel may potentially carry multiple P2MP PWs
inside (aggregation). This document uses terminology from the
document describing the MPLS multicast architecture [RFC5332] for
MPLS PSN.

3. P2MP PW Requirements

3.1. Reference Model

As per the definition of in [RFC3985], a pseudowire (PW) both originates
and terminates on the edge of the same packet switched network (PSN).
The PW label is unchanged between the originating and terminating
Provider Edges (PEs). This is also known as a single-segment
pseudowire (SS-PW), as (SS-PW) -- the most fundamental network model of PWE3.

A P2MP PW can be defined as Point-to-Multipoint point-to-multipoint connectivity from a
Root PE connected to a traffic source CE to one or more Leaf PEs
connected to traffic receiver CEs. It is considered to be an
extended architecture of the existing unicast-based P2P SS-PW technology.

Figure 1 describes the P2MP PW reference model which that is derived from
[RFC3985] to support P2MP emulated services.

|<-------------P2MP PW------------->|
Native | | Native
ROOT Service | |<----P2MP PSN tunnel --->| | Service LEAF
V (AC) V V V V (AC) V
| +----+ +-----+ +----+ |
| |PE1 | | P |=========|PE2 |AC2 | +----+
| | | | ......PW1.......>|---------->|CE2 |
| | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+ |
+----+ | AC1 | | | . |=========|PE3 |AC3 | +----+
|CE1 |-------->|........PW1.............PW1.......>|---------->|CE3 |
+----+ | | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+AC4 | +----+
| | | | . |=========|PE4 |---------->|CE4 |
| | | | ......PW1.......>| | +----+
| | | | |=========| |AC5 | +----+
| | | | | | |---------->|CE5 |
| +----+ +-----+ +----+ | +----+

Figure 1 1: P2MP PW Reference Model

This architecture applies to the case where a P2MP PSN tunnel extends
between edge nodes of a single PSN domain to transport a
unidirectional P2MP PW with endpoints at these edge nodes. In this
model
model, a single copy of each PW packet is sent over the PW on the
P2MP PSN tunnel and is received by all Leaf PEs due to the P2MP
nature of the PSN tunnel. The P2MP PW SHOULD be traffic optimized,
i.e., only one copy of a P2MP PW packet or PSN tunnel (underlying
layer) packet is sent on any single link along the P2MP path. P
routers participate in P2MP PSN tunnel operation but not in the
signaling of P2MP PWs.

The Reference Model outlines the basic pieces of a P2MP PW. However,
several levels of replication needs need to be considered when designing a
P2MP PW solution:

- Ingress PE replication to CEs: traffic is replicated to a set of
local receiver CEs

- P router replication in the core: traffic is replicated by means
of a P2MP PSN tunnel (P2MP LSP)

- Egress PE replication to CEs: traffic is replicated to local
receiver CEs

Theoretically, it is also possible to consider Ingress PE replication
in the core; that is, all traffic is replicated to a set of P2P PSN
transport tunnels at ingress, not using P router replication at all.

However, this approach may easily lead to more than one-stream
bandwidth consumption at a single duplicate copies of each PW packet
being sent over the same physical link, particularly if specifically in the case
where multiple PSN tunnels logically go over the same transit that physical link. Hence Hence, this
approach is not preferred.

Specific operations that MUST be performed at the PE on the native
data units are not described here since the required pre-processing
(Forwarder (FWRD) and Native Service Processing (NSP)) defined in
section
Section 4.2 of [RFC3985] are is also applicable to P2MP PW.

P2MP PWs are generally unidirectional, but a Root PE may need to
receive unidirectional P2P return traffic from any Leaf PE. For that
purpose
purpose, the P2MP PW solution MAY support an optional return path
from each Leaf PE to the Root PE.

3.2. P2MP PW and Underlying Layer

The definition of MPLS multicast encapsulation [RFC5332] specifies
the procedure to carry MPLS packets that are to be replicated and a
copy of the packet sent to each of the specified next hops. This
notion is also applicable to a P2MP PW (as a MPLS) packet carried by a P2MP PSN
tunnel.

To be more precise, a P2MP PSN tunnel corresponds to a "point-to-
multipoint data link or tunnel" described in [RFC5332] Section 3. 3 of [RFC5332].
Similarly, P2MP PW labels correspond to "the top labels (before
applying the data link or tunnel encapsulation) of all MPLS packets
that are transmitted on a particular point-to-multipoint data link or
tunnel."
tunnel".

In the P2MP PW architecture, PW label with architecture using the SS-PW network model, the PW-PDU
[RFC3985] is replicated by the underlying P2MP PSN tunnel layer in SS-PW network model. In other
words, it is intended to utilize PSN technology designed for
efficient multicast/broadcast transport. layer.
Note that the PW label is
unchanged unchanged, and hidden in switching switching, by the
transit P routers as long as the
model of SS-PW is taken. routers.

In a solution, a P2MP PW MUST be supported over a single P2MP PSN
tunnel as the underlying layer of traffic distribution. Figure 2
gives an example of P2MP PW topology relying on a single P2MP LSP.
The PW tree is composed of one Root PE (i1) and several Leaf PEs (e1,
e2, e3, e4).

The mechanisms for establishing the PSN tunnel are outside the scope
of this document, as long as they enable the essential attributes of
the service to be emulated.

i1
/
/ \
/ \
/ \
/\ \
/ \ \
/ \ \
/ \ / \
e1 e2 e3 e4

Figure 2 2: Example of P2MP Underlying Layer for P2MP PW

A single P2MP PSN tunnel MUST be able to serve the traffic from more
than one P2MP PW
traffic in an aggregated way, i.e., multiplexing.

A P2MP PW solution MAY support different P2MP PSN tunneling
technology (e.g., MPLS over GRE [RFC4023], [RFC4023] or P2MP MPLS LSP) or
different setup protocols. protocols (e.g., MLDP [RFC6388], multipoint extensions for LDP (mLDP)
[RFC6388] and P2MP RSVP-TE [RFC4875]).

The P2MP LSP associated to the P2MP PW can be selected either by user
configuration or by dynamically using a multiplexing/demultiplexing
mechanism.

The P2MP PW multiplexing SHOULD be used based on the overlap rate
between P2MP LSP and P2MP PW. As an example, an existing P2MP LSP
may attach more leaves than the ones defined as Leaf PEs for a given
P2MP PW. It may be attractive to reuse it to minimize new
configuration, but using this P2MP LSP would imply non-
Leaf cause non-Leaf PEs (i.e.
(i.e., not part of the P2MP PW) to receive unwanted traffic.

Note: no special configuration is needed for non-Leaf PEs to drop
those
that unwanted traffic because they do not have forwarding information entry
entries unless they process the setup operation for corresponding
P2MP PWs set-up
operation (e.g. (e.g., signaling).

The operator SHOULD determine whether it is acceptable to partially
multiplex the P2MP PW can accept
partially multiplexing with onto a P2MP LSP, and a minimum congruency rate
may be defined. The defined to enable the Root PE can determine whether P2MP PW can
multiplex to a P2MP LSP according to the congruency rate. make this determination. The
congruency rate SHOULD take into account several items, such as: including:

- the amount of overlap between the number of Leaf PEs of the P2MP PW and the
existing egress PE routers of a the P2MP LSP. If there is a
complete overlap, the congruency is perfect and the rate is 100%.

- at the expense of the additional impact on other traffic (e.g. (e.g., from other VPNs) supported over
the P2MP LSP.

With this procedure procedure, a P2MP PW is nested within a P2MP LSP. This
allows multiplexing several PWs over a common P2MP LSP. Prior to the
P2MP PW signaling phase, the Root PE determines which P2MP LSP will
be used for this P2MP PW. The PSN Tunnel tunnel can be an existing PSN
tunnel or the Root PE can create a new P2MP PSN tunnel. In addition,
if ideal congruency rate is desired, if Note that
the ingress PE may modify or re-create an existing P2MP PW has PSN tunnel in
order to add one or more
extra leaf nodes that are not covered by the existing P2MP LSP, PEs to enable it to transport the P2MP LSP SHOULD be modified or re-created to cover them.
PW.

3.3. P2MP PW Construction

[RFC5332] introduces two approaches to assign assigning MPLS label labels (meaning
PW
label labels in the P2MP PW context): Upstream-Assigned[RFC5331] Upstream-Assigned [RFC5331] and
Downstream-Assigned. However, it is out of scope of this document
which one should be used in PW construction. It is left to the
specification of the solution work. solution.

The following requirements apply to the establishment of P2MP PWs:

- PE nodes MUST be configurable with the P2MP PW identifiers and
ACs.

- A discovery mechanism SHOULD allow the Root PE to discover the
Leaf PEs, or vice versa.

- Solutions SHOULD allow single-sided operation at the Root PE for
the selection of some AC(s) at the Leaf PE(s) to be attached to
the PW tree so that the Root PE controls the Leaf leaf attachment.

- The Root PE SHOULD support a method to be informed about whether a
Leaf PE has successfully attached to the PW tree.

3.4. P2MP PW Signaling Requirements

3.4.1. P2MP PW Identifier

The P2MP PW MUST be uniquely identified. This unique P2MP PW
identifier MUST be used for all signaling procedures related to this
PW (PW setup, Monitoring, etc). monitoring, etc.).

3.4.2. PW type mismatch Type Mismatch

The Root PE and Leaf PEs of a P2MP PW MUST be configured with the
same PW type as defined in [RFC4446] for P2P PW. In case of a
different type, type
mismatch, a PE SHOULD abort attempts to attach the Leaf PE to the
P2MP PW.

3.4.3. Interface Parameters sub-TLV Sub-TLV

Some interface parameters [RFC4446] related to the AC capability have
been defined according to the PW type and are signaled during the PW
setup.

Where applicable, a solution is REQUIRED to ascertain whether the AC
at the Leaf PE is capable of supporting traffic coming from the AC at
the Root PE.

In case of a mismatch, the passive PE (Root or Leaf PE, depending on
the signaling process) SHOULD support mechanisms to reject attempts
to attach the Leaf PE to the P2MP PW.

3.4.4. Leaf Grafting/Pruning

Once the PW tree is established, the solution MUST allow the addition
or removal of a Leaf PE, or a subset of leaves to/from the existing
tree, without any impact on the PW tree (data and control planes) for
the remaining Leaf PEs.

The addition or removal of a Leaf PE MUST also allow the P2MP PSN
tunnel to be updated accordingly. This may cause the P2MP PSN tunnel
to add or remove the corresponding Leaf PE.

3.4.5. Failure Detection and Reporting

Since the underlying layer has an End-to-End end-to-end P2MP topology between
the Root PE and the Leaf PEs, the failure reporting and processing
procedures are implemented only on the edge nodes.

Failure events may cause one or more Leaf PEs to become detached from
the PW tree. These events MUST be reported to the Root PE, using
appropriate out-of-band or inband in-band Operations, Administration, and
Maintenance (OAM) messages for monitoring.

It MUST be possible for the operator to choose the out-of-band or
inband Monitoring in-
band monitoring tools or both to monitor the Leaf PE status.
The For
management purposes, the solution SHOULD allow the Root PE to be
informed of Leaf PEs
failure for management purposes. PEs' failure.

Based on these failure notifications, solutions MUST allow the Root
PE to update the remaining leaves of the PW tree.

- A solution MUST support an in-band status notification mechanism
to detect failures: unidirectional point-to-multipoint traffic
failure. This MUST be realized by enhancing existing unicast PW
methods, such as VCCV Virtual Circuit Connectivity Verification (VCCV)
for seamless and familiar operation as defined in [RFC5085].

- In case of failure, it MUST correctly report which Leaf PEs are
affected. This MUST be realized by enhancing existing PW methods,
such as LDP Status Notification. The notification message SHOULD
include the type of fault (P2MP PW, AC AC, or PSN tunnel).

- A Leaf PE MAY be notified of the status of the Root PE's AC.

- A solution MUST support OAM message mapping [RFC6310] at the Root
PE and Leaf PE if a failure is detected on the source CE.

3.4.6. Protection and Restoration

It is assumed that if recovery procedures are required, the P2MP PSN
tunnel will support standard MPLS-based recovery techniques
(typically based on RSVP-TE). techniques. In that case
case, a mechanism SHOULD be implemented to avoid race conditions
between recovery at the PSN level and recovery at the PW level.

An alternative protection scheme MAY rely on the PW layer.

Leaf PEs MAY be protected via a P2MP PW redundancy mechanism. In the
example depicted below, a standby P2MP PW is used to protect the
active P2MP PW. In that protection scheme scheme, the AC at the Root PE
MUST serve both P2MP PWs. In this scenario, the condition when to do the
switchover criteria for
switching over SHOULD be implemented, e.g. defined, e.g., failure of one or all Leaf failure leaves
of the active P2MP PW will trigger switchover of the whole P2MP PW's switchover. PW.

CE1
|
ROOT active PE1 standby
P2MP PW .../ \....P2MP PW
/ \
P2 P3
/ \ / \
/ \ / \
/ \ / \
LEAF PE4 PE5 PE6 PE7
| | | |
| \ / |
\ CE2 /
\ /
------CE3-----

Figure 3: Example of P2MP PW redundancy Redundancy for protecting Protecting Leaf PEs

Note that some of the nodes/links in this figure can be physically
shared, which
shared; this depends on the service provider policy of network
redundancy.

The Root PE MAY be protected via a P2MP PW redundancy mechanism. In
the example depicted below, a standby P2MP PW is used to protect the
active P2MP. A single AC at the Leaf PE MUST be used to attach the
CE to the primary and the standby P2MP PW. The Leaf PE MUST support
protection mechanisms in order to select the active P2MP PW.

Figure 4: Example of P2MP PW redundancy Redundancy for protecting Protecting Root PEs

3.4.7. Scalability

The solution SHOULD scale at worst linearly for message size, memory
requirements, and processing requirements, with the number of Leaf
PEs.

Increasing the number of P2MP PWs between a Root PE and a given set
of Leaf PEs SHOULD NOT cause the P router to increase the number of
entries in its forwarding table by the same or greater proportion.
Multiplexing P2MP PWs to P2MP PSN Tunnels tunnels achieves this.

4. Backward Compatibility

Solutions MUST be backward compatible with current PW standards.
Solutions SHOULD utilize existing capability advertisement and
negotiation procedures for the PEs implementing P2MP PW endpoints.

The implementation of OAM mechanisms also implies the advertisement
of PE capabilities to support specific OAM features. The solution
MAY allow advertising P2MP PW OAM capabiltities. capabilities. A solution MUST NOT
allow a P2MP PW to be established to PEs that do not support P2MP PW
functionality. It MUST have a mechanism to report an error for
incompatible PEs.

In some cases, upstream traffic is needed from downstream CEs to
upstream CEs. The P2MP PW solution SHOULD allow a return path (i.e. (i.e.,
from the Leaf PE to the Root) Root PE) that provides upstream connectivity.

In particular, the same ACs MAY be shared between the downstream and
upstream directions. For downstream, a CE receives traffic
originated by the Root PE over its AC. For upstream, the CE MAY also
send traffic destined to the same Root PE over the same AC.

5. Security Considerations

The security requirements common to PW are raised in Section 10 11 of
[RFC3916]. P2MP PW is a variant of the initial P2P PW definition,
and those requirements (and the security considerations from
[RFC3985]) also apply to P2MP PW. apply. The security considerations from [RFC5920], [RFC3985] [RFC5920]
and [RFC6941] also apply
respectively to the IP/MPLS and MPLS-TP deployment scenario.
scenarios, respectively.

Some issues specifically due to P2MP topology MUST need to be addressed in
the definition of the solution:

- The solution SHOULD provide means to guarantee protect the traffic delivery delivered
to receivers (Integrity, Confidentially) Confidentiality, Endpoint
Authentication).

- The solution SHOULD support means to protect the P2MP PW as a
whole against attacks that would lead to any kind of denial-of-service. denial of
service.

Specifically, it would be desirable to consider safeguard mechanisms should be considered to avoid any
negative impact on the whole PW Tree under the attack
against its particular receiver(s). Considerations about tree when any one receiver or any
group of receivers is attacked. Safeguard mechanisms for both control the
data plane and data the control plane are necessary.

6.IANA Considerations

This document does not require any IANA action.

9. need to be considered.

6. References

9.1.

6.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, RFC 2119, March 1997.

[RFC3916] Xiao, X., Ed., McPherson, D., Ed., and P. Pate, Ed.,
"Requirements for Pseudo-Wire Emulation Edge-to-Edge
(PWE3)", RFC 3916, September 2004.

[RFC3985] Bryant, S. S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-
Edge
Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.

[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter,
"MPLS Multicast Encapsulations", RFC 5332, August 2008.

[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
October 2009.

[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

[RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M.,
Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations,
Administration, and Maintenance (OAM) Message Mapping",
RFC 6310, July 2011.

9.2.

6.2. Informative References

[I-D.ietf-l2vpn-vpms-frmwk-requirements]
Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D.,
and L. Jin, "Framework and Requirements for Virtual
Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms-
frmwk-requirements-05 (work in progress), October 2012.

[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", RFC 4023, March 2005.

[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, April 2006.

[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
2007.

[RFC5085] Nadeau, T. T., Ed., and C. Pignataro, Ed., "Pseudowire
Virtual Circuit Connectivity Verification (VCCV): A
Control Channel for Pseudowires", RFC 5085, December
2007.

[RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed.,
"Requirements for Multi-Segment Pseudowire Emulation
Edge-to-Edge (PWE3)", RFC 5254, October 2008.

[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", RFC
5331, August 2008.

[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.

[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-to-
Multipoint
Point-to-Multipoint and Multipoint-to-Multipoint Label
Switched Paths", RFC 6388, November 2011.

[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.

[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S.,
Ed., and R. Graveman, R., Ed., "MPLS Transport Profile
(MPLS-TP) Security Framework", RFC 6941, April 2013.

[VPMS-REQS] Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D.,
and L. Jin, "Framework and Requirements for Virtual
Private Multicast Service (VPMS)", Work in Progress,
October 2012.

7. Acknowledgments

The authors thank the following people: the authors of [RFC4461]
since the structure and content of this document were, for some
sections, largely inspired by [RFC4461], JL [RFC4461]; JL. Le Roux and A. Cauvin
for the discussions, comments comments, and support, support; Adrian Farrel for his
Routing Area Director review, review; and IESG reviewers.

7. Contributing Authors

8. Contributors

Philippe Niger
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France

Email:

EMail: philippe.niger@orange-ftgroup.com

Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, CO 80112
US

EMail: lmartini@cisco.com

Lei Wang
Telenor
Snaroyveien 30
Fornebu 1331
Norway

Email:

EMail: lei.wang@telenor.com

Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089

Email:
US

EMail: rahul@juniper.net
Simon Delord
Telstra
380 Flinders lane. Lane
Melbourne

Email:
Australia

EMail: simon.delord@gmail.com

Martin Vigoureux
Alcatel-Lucent France
Route de Villejust
91620 Nozay
France

Email:

EMail: martin.vigoureux@alcatel-lucent.fr

Lizhong Jin
ZTE Corporation
889, Bibo Road
Shanghai, 201203, 201203
China

Email:

EMail: lizho.jin@gmail.com

Authors' Addresses

Frederic Jounay (editor)
Orange CH
4 rue caudray 1020 Renens
Switzerland

Email:

EMail: frederic.jounay@orange.ch

Yuji Kamite (editor)
NTT Communications Corporation
Granpark Tower
3-4-1 Shibaura, Minato-ku
1-1-6 Uchisaiwai-cho, Chiyoda-ku
Tokyo 108-8118 100-8019
Japan

Email:

EMail: y.kamite@ntt.com

Giles Heron
Cisco Systems, Inc.
9 New Square
Bedfont Lakes
Feltham
Middlesex
TW14 8HA
United Kingdom

Email:

EMail: giheron@cisco.com

Matthew Bocci
Alcatel-Lucent Telecom Ltd
Voyager Place
Shoppenhangers Road
Maidenhead
Berks
United Kingdom

Email: matthew.bocci@alcatel-lucent.co.uk

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before
November 10, 2008. The person(s) controlling the copyright in
some of this material may not have granted the IETF Trust the
right to allow modifications of such material outside the IETF
Standards Process. Without obtaining an adequate license from the
person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process,
and derivative works of it may not be created outside the IETF
Standards Process, except to format it for publication as an RFC
or to translate it into languages other than English.

EMail: Matthew.Bocci@alcatel-lucent.com