One document matched: draft-ietf-pwe3-p2mp-pw-requirements-07.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc5332 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5332.xml'>
<!ENTITY rfc4446 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4446.xml'>
<!ENTITY rfc5085 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5085.xml'>
<!ENTITY rfc6073 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6073.xml'>
<!ENTITY rfc3985 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3985.xml'>
<!ENTITY rfc3916 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3916.xml'>
<!ENTITY rfc4461 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4461.xml'>
<!ENTITY rfc5331 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5331.xml'>
<!ENTITY rfc5254 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5254.xml'>
<!ENTITY rfc5659 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5659.xml'>
<!ENTITY rfc6310 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6310.xml'>
<!ENTITY rfc4023 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4023.xml'>
<!ENTITY rfc4875 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4875.xml'>
<!ENTITY rfc6388 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6388.xml'>
<!ENTITY I-D.ietf-l2vpn-vpms-frmwk-requirements PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-l2vpn-vpms-frmwk-requirements-05.xml'>
]>
<rfc category="info" ipr="trust200902" docName="draft-ietf-pwe3-p2mp-pw-requirements-07.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact='yes'?>
<?rfc subcompact='yes'?>
<front>
<title abbrev="P2MP PW Requirements">
Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS PSNs
</title>
<author initials='F.' surname="Jounay" fullname='Frederic Jounay' role='editor'>
<organization abbrev="Orange CH">
Orange CH
</organization>
<address>
<postal>
<street>4 rue caudray 1020 Renens</street>
<country>France</country>
</postal>
<email>frederic.jounay@orange.ch</email>
</address>
</author>
<author initials='Y.' surname="Kamite" fullname='Yuji Kamite' role='editor'>
<organization abbrev="NTT Communications">
NTT Communications Corporation
</organization>
<address>
<postal>
<street>Granpark Tower</street>
<street>3-4-1 Shibaura, Minato-ku</street>
<region>Tokyo</region>
<code>108-8118</code>
<country>Japan</country>
</postal>
<email>y.kamite@ntt.com</email>
</address>
</author>
<author initials='G.' surname="Heron" fullname='Giles Heron'>
<organization abbrev="Cisco Systems">
Cisco Systems, Inc.
</organization>
<address>
<postal>
<street>9 New Square </street>
<street>Bedfont Lakes </street>
<street>Feltham </street>
<street>Middlesex </street>
<street>TW14 8HA </street>
<country>United Kingdom</country>
</postal>
<email>giheron@cisco.com</email>
</address>
</author>
<author initials='M.' surname="Bocci" fullname='Matthew Bocci'>
<organization abbrev="Alcatel-Lucent">
Alcatel-Lucent Telecom Ltd
</organization>
<address>
<postal>
<street>Voyager Place </street>
<street>Shoppenhangers Road </street>
<street>Maidenhead </street>
<street>Berks </street>
<country>United Kingdom</country>
</postal>
<email>matthew.bocci@alcatel-lucent.co.uk</email>
</address>
</author>
<date day="12" month="February" year="2014"/>
<abstract>
<t>
This document presents a set of requirements and a framework for
providing a Point-to-Multipoint Pseudowire (PW) over MPLS PSNs. The
requirements identified in this document are related to architecture,
signaling and maintenance aspects of Point-to-Multipoint PW
operation. They are proposed as guidelines for the standardization of
such mechanisms. Among other potential applications, Point-to-
Multipoint PWs can be used to optimize the support of multicast layer
2 services (Virtual Private LAN Service and Virtual Private Multicast
Service) as defined in the Layer 2 Virtual Private Network Working
Group.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Problem Statement">
<t>
As defined in the pseudowire architecture <xref target="RFC3985"/>, a 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 PSN. It provides a single service which is
perceived by its user as an unshared link or circuit of the chosen
service. A Pseudowire is used to transport layer 1 or layer 2 traffic
(e.g. Ethernet, TDM, ATM, and FR) over a layer 3 PSN. PWE3 operates
"edge to edge" to provide the required connectivity between the two
endpoints of the PW.
</t>
<t>
The Point-to-Multipoint (P2MP) topology described in <xref target="I-D.ietf-l2vpn-vpms-frmwk-requirements"/> and
required to provide P2MP L2VPN services can be achieved using one or
more P2MP PWs. The use of PW encapsulation enables P2MP services
transporting layer 1 or layer 2 data. This could be achieved using a
set of point to point PWs, with traffic replication on the PE, but at
the cost of bandwidth efficiency, as duplicate traffic would be
carried multiple times on shared links.
</t>
<t>
This document defines the requirements for a 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
over a PSN. The required functions of P2MP PWs include encapsulating
service-specific 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.
</t>
<t>
P2MP PWs therefore extend the PWE3 architecture <xref target="RFC3985"/> to offer a
P2MP telecommunications service.
</t>
<t>
This document also defines the associated requirements related to the
P2MP PW operation (e.g. setup and maintenance, protection and
scalability).
</t>
</section>
<section title="Scope of This Document">
<t>
The document describes the general architecture of P2MP PW
with 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 for further study how it should be realized
in Multi-Segment PW model.
For other
aspects of P2MP PW implementation, such as packet processing (section
4) and Faithfulness of Emulated Services (section 7), the document
refers to <xref target="RFC3916"/>.
</t>
</section>
<section title="Conventions used in this document">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in
<xref target="RFC2119"/>
.
</t>
</section>
</section>
<section title="Definition">
<section title="Acronyms">
<t>
<list>
<t>
P2P: Point-to-Point
</t>
<t>
P2MP: Point-to-Multipoint
</t>
<t>
PW: Pseudowire
</t>
<t>
PSN: Packet Switched Network
</t>
<t>
SS-PW: Single-Segment Pseudowire
</t>
<t>
MS-PW: Multi-Segment Pseudowire
</t>
</list>
</t>
</section>
<section title="Terminology">
<t>
This document uses terminology described in <xref target="RFC5659"/>.
It also introduces additional terms needed in the context of P2MP PW.
</t>
<t>
<list style="hanging" hangIndent="6">
<t hangText="P2MP PW, (also referred as PW Tree): ">
<vspace/>
Point-to-Multipoint Pseudowire. A PW attached to a source CE used to
distribute Layer 1 or 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), and optionally supports a return path.
</t>
<t hangText="P2MP SS-PW: ">
<vspace/>
Point-to-Multipoint Single-Segment Pseudowire. A 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 LSPs as PSN
tunnels. The requirements in this document is targeted for SS-PW model.
Application of MS-PW (Multi-segment PW) model <xref target="RFC5254"/>
is out of scope and left for future work.
</t>
<t hangText="Root PE: ">
<vspace/>
P2MP PW Root Provider Edge. The PE attached to the traffic source CE
for the P2MP PW via an Attachment Circuit (AC).
</t>
<t hangText="Leaf PE: ">
<vspace/>
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 <xref target="RFC3985"/>.
</t>
<t hangText="P2MP PSN Tunnel: ">
<vspace/>
In the P2MP SS-PW topology, The PSN 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 <xref target="RFC5332"/> for MPLS PSN.
</t>
</list>
</t>
</section>
</section>
<section title="P2MP PW Requirements">
<section title="Reference Model">
<t>
As per the definition of <xref target="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 the most fundamental network model of PWE3.
</t>
<t>
P2MP PW can be defined as
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 SS-PW technology.
</t>
<t>
Figure 1 describes the P2MP reference model which is derived
from <xref target="RFC3985"/> to support P2MP emulated services.
</t>
<figure><artwork><![CDATA[
|<-----------P2MP PW -------------->|
Native | | Native
Service | |<----P2MP PSN tunnel --->| | Service
(AC) V V V V (AC)
| +----+ +-----+ +----+ |
| |PE1 | | P |=========|PE2 |AC2 | +----+
| | | | ......PW1.......>|---------->|CE2 |
| | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+ |
+----+ | AC1 | | | . |=========|PE3 |AC3 | +----+
|CE1 |-------->|........PW1.............PW1.......>|---------->|CE3 |
+----+ | | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+ |
| | | | . |=========|PE4 |AC4 | +----+
| | | | ......PW1.......>|---------->|CE4 |
| | | | |=========| | | +----+
| +----+ +-----+ +----+ |
Figure 1: P2MP PW Reference Model
]]></artwork></figure>
<t>
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 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 MUST be traffic optimized, i.e.,
only one copy of a P2MP PW packet is sent on any single link. P
routers participate in P2MP PSN tunnel operation but not in the
signaling of P2MP PWs.
</t>
<t>
The Reference Model outlines the basic pieces of a P2MP PW.
However, several levels of replication needs to be considered when designing a
P2MP PW solution:
</t>
<t>
<list style='hanging'>
<t hangText='-'>Ingress PE replication to CEs: traffic is replicated to a set of local receiver CEs</t>
<t hangText='-'>P router replication in the core: traffic replicated by means of P2MP PSN tunnel (P2MP LSP) </t>
<t hangText='-'>Egress PE replication to CEs: traffic replicated to local receiver CEs </t>
</list>
</t>
<t>
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 link, particularly if the PSN tunnels logically go over the same physical link.
Hence this approach is not preferred.
</t>
<t>
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 4.2 of <xref target="RFC3985"/> are also applicable to P2MP PW.
</t>
<t>
P2MP PWs are generally unidirectional, but a Root PE may need to
receive unidirectional P2P return traffic from any Leaf PE. For that purpose
the P2MP PW solution MAY support an optional return path from each Leaf PE to Root PE.
</t>
</section>
<section title="P2MP PW and Underlying Layer">
<t>
The definition of MPLS multicast encapsulation <xref target="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 P2MP PW (as a MPLS) packet carried by a P2MP PSN tunnel.
</t>
<t>
To be more precise, a P2MP PSN tunnel corresponds to a "point-to-multipoint data link or tunnel"
described in <xref target="RFC5332"/> Section 3.
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."
</t>
<t>
In P2MP PW architecture, PW label with PW-PDU <xref target="RFC3985"/> is
replicated by 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 trasnport.
Note that PW label is unchanged and hidden in switching by transit P routers
as long as the model of SS-PW is taken.
</t>
<t>
In a solution, a P2MP PW MUST be supported over a single P2MP PSN tunnel
as underlying layer of traffic distribution.
Figure 2 gives an example of P2MP SS-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).
</t>
<t>
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.
</t>
<figure><artwork><![CDATA[
i1
/
/ \
/ \
/ \
/\ \
/ \ \
/ \ \
/ \ / \
e1 e2 e3 e4
Figure 2: Example of P2MP Underlying Layer for P2MP SS-PW ]]></artwork></figure>
<t>
A single P2MP PSN tunnel MUST be able to serve more than one P2MP PW traffic in an aggregated way,
i.e., multiplexing.
</t>
<t>
A P2MP PW solution MAY support different P2MP PSN tunneling technology (e.g., MPLS over
GRE <xref target="RFC4023"/>, or P-to-MP MPLS LSP) or different setup protocols. (e.g.,
MLDP <xref target="RFC6388"/>, and P2MP RSVP-TE <xref target="RFC4875"/>).
</t>
<t>
The P2MP LSP associated to the P2MP PW can be selected either by user
configuration or by dynamically using a multiplexing/demultiplexing
mechanism.
</t>
<t>
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 PEs receive unwanted
traffic, not destined to Leaf PE at the service layer. The operator
should determine whether the P2MP PW can accept partially
multiplexing with P2MP LSP, and a minimum congruency rate may be
defined. The Root PE can determine whether P2MP PW can multiplex to a
P2MP LSP according to the congruency rate. The congruency rate should
take into account several items, such as:
</t>
<t>
<list style='hanging'>
<t hangText='-'>the amount of overlap between the number of Leaf PEs
of P2MP PW and existing egress PE routers of a P2MP LSP. If there is a complete
overlap, the congruency is perfect and the rate is 100%.
</t>
<t hangText='-'>at the expense of the additional traffic (e.g. other VPNs)
supported over the P2MP LSP.
</t>
</list>
</t>
<t>
With this 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 can be an existing PSN
tunnel or the Root PE can create a new P2MP PSN tunnel.
</t>
</section>
<section title="P2MP PW Construction">
<t>
<xref target="RFC5332"/> introduces two approaches to assign MPLS label
(meaning PW label in P2MP PW's context):
Upstream-Assigned<xref target="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.
</t>
<t>
The following requirements apply to the establishment of P2MP PWs (P2MP SS-PWs):
</t>
<t>
<list style='hanging'>
<t hangText='-'>PE nodes MUST be configurable with the P2MP PW identifiers and ACs. </t>
<t hangText='-'>A discovery mechanism SHOULD allow the Root PE to discover the Leaf PEs, or vice versa.</t>
<t hangText='-'>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 attachment. </t>
</list>
</t>
<t>
The Root PE SHOULD support a method to be informed about whether a
Leaf PE has successfully attached to the PW tree.
</t>
</section>
<section title="P2MP Signaling Requirements">
<section title="PW Identifier">
<t>
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).
</t>
</section>
<section title="PW type mismatch">
<t>
The Root PE and Leaf PEs of a P2MP PW MUST be configured with the
same PW type as defined in <xref target="RFC4446"/> for P2P PW. In case of a
different type, a PE MUST abort attempts to establish the P2MP PW.
</t>
</section>
<section title="Interface Parameters sub-TLV">
<t>
Some interface parameters <xref target="RFC4446"/> related to the AC capability have
been defined according to the PW type and are signaled during the PW
setup.
</t>
<t>
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.
</t>
<t>
In case of a mismatch, the passive PE (Root or Leaf PE, depending on
the signaling process) MUST support mechanisms to reject attempts to
establish the P2MP SS-PW.
</t>
</section>
<section title="Leaf Grafting/Pruning">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Failure Detection and Reporting">
<t>
Since the underlying layer has an 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.
</t>
<t>
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 OAM messages.
</t>
<t>
It MUST be possible for the operator to choose the out-of-band or
inband OAM tools or both to monitor the Leaf PE status.
The solution SHOULD allow the Root PE to be informed of Leaf PEs
failure for management purposes.
</t>
<t>
Based on these failure notifications, solutions MUST allow the Root
PE to update the remaining leaves of the PW tree.
</t>
<t>
<list style='hanging'>
<t hangText='-'>
A solution MUST support in-band OAM mechanism to detect failures:
unidirectional point-to-multipoint traffic failure. This SHOULD be
realized by enhancing existing unicast PW methods, such as VCCV for
seamless and familiar operation defined in <xref target="RFC5085"/><xref target="RFC6073"/>.
</t>
<t hangText='-'>
In case of failure, it SHOULD correctly report which Leaf PEs are
affected. This SHOULD be realized by enhancing existing PW methods,
such as LDP Status Notification. The notification message SHOULD
include the type of fault (P2MP PW, AC or PSN tunnel).
</t>
<t hangText='-'>
A Leaf PE MAY be notified of the status of the Root PE's AC.
</t>
<t hangText='-'>
A solution MUST support OAM message mapping <xref target="RFC6310"/> at the Root
PE and Leaf PE if a failure is detected on the source CE AC.
</t>
</list>
</t>
</section>
<section title="Protection and Restoration">
<t>
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). In that case a mechanism SHOULD be
implemented to avoid race conditions between recovery at the PSN
level and recovery at the PW level.
</t>
<t>
An alternative protection scheme MAY rely on the PW layer.
</t>
<t>
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. In that protection scheme the AC at the Root PE MUST
serve both P2MP PWs. In this scenario, the condition when to do the
switchover SHOULD be implemented, e.g. one or all Leaf failure of
active P2MP PW will trigger the whole P2MP PW's switchover.
</t>
<figure><artwork><![CDATA[
CE1
|
active PE1 standby
P2MP PW .../ \....P2MP PW
/ \
P2 P3
/ \ / \
/ \ / \
/ \ / \
PE4 PE5 PE6 PE7
| | | |
| \ / |
\ CE2 /
\ /
-------CE3------
Figure 3: Example of P2MP PW redundancy for protecting Leaf PEs
]]></artwork></figure>
<t>
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.
</t>
<figure><artwork><![CDATA[
CE1
/ \
| |
active PE1 PE2 standby
P2MP PW1 | | P2MP PW2
| |
P2 P3
/ \/ \
/ /\ \
/ / \ \
/ / \ \
PE4 PE5
| |
CE2 CE3
Figure 4: Example of P2MP PW redundancy for protecting Root PEs
]]></artwork></figure>
</section>
<section title="Scalability">
<t>
The solution SHOULD scale at least linearly with the number of Leaf
PEs.
</t>
<t>
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 achieves this.
</t>
</section>
</section>
</section>
<section title="Manageability considerations">
<t>
The solution SHOULD provide a simple provisioning procedure to build
a P2MP PW.
</t>
<t>
The solution MUST take into consideration the situation where the
Root PE and Leaf PEs are not managed by a single NMS.
</t>
<t>
In that case it MUST be possible to manage the whole P2MP PW using a
single NMS. Typically the P2MP PW could be managed from the Root PE.
</t>
</section>
<section title="Backward Compatibility">
<t>
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.
</t>
<t>
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 capabilities.
</t>
<t>
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.
</t>
<t>
In some cases, upstream traffic is needed from downstream CEs to
upstream CEs. The P2MP PW solution SHOULD allow a return path (i.e.
from the Leaf to the Root) that provides upstream connectivity.
</t>
<t>
In particular, the same ACs MAY be shared between 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.
</t>
</section>
<section title="Security Considerations">
<t>
The security requirements common to PW are raised in Section 10 of
<xref target="RFC3916"/>. P2MP PW is a variant of the initial P2P PW definition, and those
requirements also apply to P2MP PW.
</t>
</section>
<section title="IANA Considerations">
<t>
This draft does not require any IANA action.
</t>
</section>
<section title="Contributing Authors">
<figure><artwork><![CDATA[
Philippe Niger
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
Email: philippe.niger@orange-ftgroup.com
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
EMail: lmartini@cisco.com
Lei Wang
Telenor
Snaroyveien 30
Fornebu 1331
Norway
Email: lei.wang@telenor.com
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
Simon Delord
Alcatel-Lucent
Building 3, 388 Ningqiao Road, Jinqiao, Pudong
Shanghai, 201206, P.R. China
Email: simon.delord@alcatel-lucent.com
Martin Vigoureux
Alcatel-Lucent France
Route de Villejust
91620 Nozay
France
Email: martin.vigoureux@alcatel-lucent.fr
Lizhong Jin
ZTE Corporation
889, Bibo Road,
Shanghai, 201203, China
Email: lizhong.jin@zte.com.cn
]]></artwork></figure>
</section>
<section title="Acknowledgments">
<t>
The authors thank the authors of <xref target="RFC4461"/> since the structure and
content of this document were, for some sections, largely inspired by
<xref target="RFC4461"/>.
Many thanks to JL Le Roux and A. Cauvin for the discussions, comments
and support.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
<references title="Informative References">
&rfc5332;
&rfc5331;
&rfc4446;
&rfc5085;
&rfc6073;
&rfc3985;
&rfc3916;
&rfc4461;
&rfc5254;
&rfc5659;
&rfc6310;
&rfc4023;
&rfc4875;
&rfc6388;
&I-D.ietf-l2vpn-vpms-frmwk-requirements;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:38:53 |