One document matched: draft-ietf-pwe3-p2mp-pw-requirements-01.txt
Differences from draft-ietf-pwe3-p2mp-pw-requirements-00.txt
Network Working Group F. Jounay (Ed.)
Internet Draft P. Niger
Category: Informational Track France Telecom
Expires: January 2010
Y. Kamite
L. Martini NTT Communications
Cisco
S. Delord
R. Aggarwal Uecomm
Juniper Networks
L. Wang
M. Bocci Telenor
M. Vigoureux
Alcatel-Lucent G. Heron
BT
L. Jin
Nokia Siemens July, 2009
Requirements for Point-to-Multipoint Pseudowire
draft-ietf-pwe3-p2mp-pw-requirements-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January, 2010.
Jounay et al. Expires January 2010 [Page 1]
Internet Draft P2MP PW Requirements July 2009
Abstract
This document presents a set of requirements for providing an
unidirectional Point-to-Multipoint PWE3 (Pseudowire Emulation Edge to
Edge) emulation. The requirements identified in this document are
related to architecture, signaling and maintenance aspects of a
Point-to-Multipoint PW operation. They are proposed as guidelines for
the standardization of such mechanisms. Among other potential
applications Point-to-Multipoint PWs SHOULD be used to optimize the
support of multicast services as defined in the Layer 2 Virtual
Private Network working group.
Conventions used in this document
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 [RFC2119].
Table of Contents
1. Introduction....................................................3
1.1. Problem Statement.............................................3
1.2. Scope of the document.........................................4
2. Definition......................................................4
2.1. Acronyms......................................................4
2.2. Terminology...................................................4
3. P2MP SS-PW Requirements.........................................5
3.1. P2MP SS-PW Reference Model....................................5
3.2. P2MP SS-PW Underlying Layer...................................7
3.3. P2MP SS-PW Construction.......................................7
3.4. P2MP SS-PW Signaling Requirements.............................8
3.4.1. PW Identifier...............................................8
3.4.2. PW type mismatch............................................8
3.4.3. Interface Parameters sub-TLV................................8
3.4.4. Leaf Grafting/Pruning.......................................8
3.5. Failure Detection and Reporting...............................9
3.6. Protection and Restoration....................................9
3.7. Scalability..................................................10
3.8. Order of Magnitude...........................................11
4. P2MP MS-PW Requirements........................................11
4.1. P2MP MS-PW Pseudowire Reference Model........................11
4.2. P2MP SS-PW Underlying Layer..................................12
4.3. P2MP MS-PW Signaling Requirements............................13
4.3.1. Dynamically Instantiated P2MP MS-PW........................13
4.3.2. P2MP MS-PW Setup Mechanisms................................13
4.3.3. PW type mismatch...........................................13
4.3.4. Interface Parameters sub-TLV...............................14
4.3.5. Leaf Grafting/Pruning......................................14
4.3.6. Explicit Routing...........................................14
4.4. Failure Detection and Reporting..............................14
Jounay et al. Expires January 2010 [Page 2]
Internet Draft P2MP PW Requirements July 2009
4.5. Protection and Restoration...................................15
4.6. Scalability..................................................15
4.7. Order of Magnitude...........................................16
5. Manageability considerations...................................16
6. Backward Compatibility.........................................16
7. Security Considerations........................................17
8. IANA Considerations............................................17
9. Acknowledgments................................................17
10. References....................................................17
10.1. Normative References........................................17
10.2. Informative References......................................18
Authors' Addresses................................................18
Copyright and Licence Notice .....................................19
1. Introduction
1.1. Problem Statement
As defined in the PWE3 WG charter, a Pseudowire (PW) emulates a
point-to-point bidirectional link over an IP/MPLS network, and
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 non IP traffic (e.g. Ethernet, TDM, ATM, and FR) in an
IP/MPLS-based PSN (Packet Switched Network). PWE3 operates "edge to
edge" to provide the required connectivity between the two endpoints
of the PW.
The P2MP topology mentioned in [VPMS REQ] and required to provide
P2MP L2VPN services can be achieved via a P2MP PW. The use of PW
becomes necessary for some P2MP services requiring specific
encapsulation capabilities. This could be achieved using a set of
point to point PWs, with traffic replication on the PE, but faces
obvious bandwidth limitation issues, as traffic is carried multiple
time on shared links.
This document defines the requirements for the use of a Point-to-
Multipoint PW (P2MP PW). A Point-to-Multipoint (P2MP) Pseudowire (PW)
is a mechanism that emulates the essential attributes of a P2MP
Telecommunications service such as P2MP ATM over PSN. One of the
applicabilities of a P2MP PW is to deliver a non-IP multicast service
that carries multicast frames from a multicast source to one or more
multicast receivers. 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.
P2MP PWs extend the PWE3 architecture [RFC3985] to offer a P2MP
Telecommunications service.
Jounay et al. Expires January 2010 [Page 3]
Internet Draft P2MP PW Requirements July 2009
This document aims at defining the associated requirements related to
the P2MP PW operation (e.g. setup and maintenance, protection,
scalability, etc).
1.2. Scope of the document
The document describes the P2MP PW Reference Model architectures and
outlines specific signaling requirements for the set up and
maintenance of a P2MP PW. The requirements are divided into two
parts, i.e. those applicable in a Single-Segment topology and those
applicable in a Multi-Segment topology. For other aspects of P2MP PW
implementation like packet processing (section 4) and Faithfulness of
Emulated Services (section 7), the document refers to [RFC3916].
Some P2MP PW requirements are derived from the signaling requirements
for P2MP Traffic-Engineered MPLS Label Switched Paths [RFC4461].
2. Definition
2.1. Acronyms
P2P: Point-to-Point
P2MP: Point-to-Multipoint
PW: Pseudowire
SS-PW: Single-Segment Pseudowire
MS-PW: Multi-Segment Pseudowire
2.2. Terminology
This document uses terminology described in [RFC5254], [MS-PW ARCH],
[SEG PW].
It also introduces additional terms needed in the context of P2MP PW.
P2MP PW, (also referred as PW Tree)
Point-to-Multipoint Pseudowire. A PW attached to a source used to
distribute L1/L2 format traffic to a set of one or more receivers (or
leaves). The P2MP PW is unidirectional.
P2MP SS-PW
Point-to-Multipoint Single-Segment Pseudowire. A single segment P2MP
PW set up between the PE attached to the source and the PEs attached
to the receivers. The P2MP SS-PW relies on a P2MP LSP as PSN tunnel.
Jounay et al. Expires January 2010 [Page 4]
Internet Draft P2MP PW Requirements July 2009
P2MP MS-PW
Point-to-Multipoint Multi-Segment Pseudowire. A multi-segment P2MP PW
represents an End-to-End PW segmented by means of S-PEs which are in
charge of switching the PW label. Each segment can rely on either
P2P LSP or a P2MP LSP as PSN tunnel.
Ingress PE
P2MP PW Ingress Provider Edge. Router attached to a Customer
Equipment (traffic source) via an Attachment Circuit (AC). In a MS-PW
architecture the term used is Ingress T-PE.
Egress PE
P2MP PW Egress Provider Edge. Router attached to a set of on or more
Customer Equipments (traffic receivers or leaves) via a set of one or
more Attachment Circuits (AC). In a MS-PW architecture the term used
is Egress T-PE.
Branch S-PE
The branch S-PE is only defined and required in the context of MS-PW.
The branch S-PE has one upstream PW segment and one or several
downstream PW segments.
P2MP PSN Tunnel
In the P2MP SS-PW topology, The PSN Tunnel is a general term
indicating a virtual P2MP connection between the Ingress PE and the
Egress PEs. A P2MP tunnel may potentially carry multiple P2MP PWs
inside. This document uses terminology from the document describing
the MPLS multicast architecture [RFC5332] for MPLS PSN.
3. P2MP SS-PW Requirements
3.1. P2MP SS-PW Reference Model
A P2MP SS-PW provides a Point-to-Multipoint connectivity from an
Ingress PE connected to a traffic source to at least two Egress PEs
connected to traffic receivers. The PW endpoints connect the PW to
its attachment circuits (AC). As for a P2P PW, an AC can be a Frame
Relay DLC, an ATM VP/VC, an Ethernet port, a VLAN, a HDLC link on a
physical interface.
Figure 1 describes the P2MP SS-PW reference model which is derived
from [RFC3985] to support P2MP emulated services.
Jounay et al. Expires January 2010 [Page 5]
Internet Draft P2MP PW Requirements July 2009
|<-----------P2MP SS-PW------------>|
Native | | Native
Service | |<----P2MP PSN tunnel --->| | Service
(AC) V V V V (AC)
| +----+ +-----+ +----+ |
| |PE1 | | P |=========|PE2 |AC3 | +----+
| | | | ......PW1.......>|---------->|CE3 |
| | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+ |
+----+ | AC1 | | | . |=========|PE3 |AC4 | +----+
|CE1 |-------->|........PW1.............PW1.......>|---------->|CE4 |
+----+ | | | | . |=========| | | +----+
| | | | . | +----+ |
+----+ |AC2 | |=========| . | |
| CE2|<--------| | | . | +----+AC5 | +----+
+----+ | | | | . |=========|PE4 |---------->|CE5 |
| | | | ......PW1.......>| | +----+
| | | | |=========| |AC6 | +----+
| | | | | | |---------->| CE6|
| +----+ +-----+ +----+ | +----+
Figure 1 P2MP SS-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 a single copy of each PW packet is sent over the P2MP
PSN tunnel and is received by all Egress PEs due to the P2MP nature
of the PSN tunnel. P2MP PW MUST be traffic optimised, only one copy
of P2MP PW packet on one single link. P Router is joining P2MP PSN
tunnel operation but is not participating in the signaling of P2MP
PW. P2MP PW operation is associated with PE1, PE2, PE3 and PE4.
An AC attached to P2MP PW MUST be configured as "sender" or
"receiver" not both. Any AC is associated with the role of either
sending side (Tx) or receiving side (Rx) from the view of CE. Thus
every AC deals with unidirectional traffic. In Figure 1, AC1 is
configured as sending sides while AC2, AC3, AC4, AC5 and AC6 are as
receiving sides.
Referring to Figure 1, CE2, CE5 and CE6 MAY want to receive multicast
traffic from CE1. P2MP SS-PW (and P2MP MS-PW outlined in section 4)
solution MUST support such an operational case where one or more ACs
are connected to the same PE and local replication is needed. A PE
providing P2MP PW MUST support the following functions:
- Ingress PE MUST support traffic replication over its directly
connected ACs toward receiver CEs if necessary, in addition to PSN
transport.
- Egress PE MUST support traffic replication over its directly
connected ACs toward receiver CEs if necessary.
Jounay et al. Expires January 2010 [Page 6]
Internet Draft P2MP PW Requirements July 2009
In the simplest case one AC serves one P2MP PW, but one AC MUST be
able to serve multiple P2MP PW for PW tree redundancy (see section
3.6 or for multitree-based VPMS [VPMS REQ].
In nature the P2MP PW is unidirectional, but it may be required for
an ingress PE to receive unidirectional P2P traffic from any egress
PE. For that purpose the P2MP PW MUST also support OPTIONAL
bidirectional connectivity between the Ingress PE and each Egress PE
- Downstream: Point-to-Multipoint (Ingress PE to any Egress PE)
- Upstream: Point-to-Point (any Egress PE to Ingress PE)
3.2. P2MP SS-PW Underlying Layer
The P2MP SS-PW implies an underlying P2MP PSN tunnel. Figure 2 gives
an example of P2MP SS-PW topology relying on a P2MP LSP. The PW tree
is composed of one Ingress PE (i1) and several Egress PEs (e1, e2,
e3, e4).
The P2MP PSN MAY be signaled with P2MP RSVP-TE [RFC4875] or MLDP
[MLDP].
i1
/
/ \
/ \
/ \
/\ \
/ \ \
/ \ \
/ \ / \
e1 e2 e3 e4
Figure 2 Example of P2MP Underlying Layer for P2MP SS-PW
The P2MP PW MAY be supported over multiple P2MP PSN tunnel. These
P2MP PSN tunnels MUST be able to serve more than one P2MP PW.
The P2MP Tunnels MAY also be of different technology ( ex. MPLS over
GRE, or P-to-MP MPLS LSP ) or just use different setup protocols. (
ex. MLDP, and P2MP RSVP-TE ).
3.3. P2MP SS-PW Construction
As initial step PE nodes have to be configured with P2MP PW
identifier and ACs.
Then discovery mechanism SHOULD allow PE to discover remote PEs
configuration.
Eventually the solution SHOULD allow single-sided operation at the
Ingress PE for the selection of some AC(s) at the Egress PE(s) to be
attached to the PW tree so that the Ingress PE controls the leaf
attachment.
Jounay et al. Expires January 2010 [Page 7]
Internet Draft P2MP PW Requirements July 2009
Note that the Ingress PE single sided operation is a management
requirement and does not presume any signaling requirement.
The Ingress PE SHOULD support a method to be informed about the
Egress PE successfully attached to the PW tree.
3.4. P2MP SS-PW Signaling Requirements
3.4.1. PW Identifier
The P2MP PW MUST be uniquely identified. This unique P2MP PW
identifier MUST be used for all the signaling procedure related to
this PW (PW setup, monitoring).
3.4.2. PW type mismatch
As for P2P PW, the ACs configured at Ingress PE and Egress PEs of a
P2MP PW MUST be of the same PW type [RFC4446]. In case of a different
type, the passive PE (Ingress or Egress PE, depending on the
signaling process) MUST support mechanisms to reject attempts to
establish the P2MP PW.
3.4.3. Interface Parameters 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.
When applicable, this mechanism used for the P2P PW setup MUST be
enhanced for P2MP PW setup so as to ascertain that AC at the Egress
PE is capable to support traffic coming from AC at the Ingress PE.
In case of mismatch, the passive PE (Ingress or Egress PE, depending
on the signaling process) MUST support mechanisms to reject attempts
to establish the P2MP SS-PW.
3.4.4. Leaf Grafting/Pruning
Once the PW tree is setup, the solution MUST allow the addition or
removal of a leaf, or a subset of leaves to/from the existing tree,
without any impact on the PW tree (data and control planes) for the
remaining leaves.
The addition or removal of a leaf MUST also allow to the P2MP PSN
tunnel to be updated accordingly. This MAY cause P2MP PSN tunnel to
add or remove the corresponding leaf.
Jounay et al. Expires January 2010 [Page 8]
Internet Draft P2MP PW Requirements July 2009
3.5. Failure Detection and Reporting
Since the underlying layer has an End-to-End P2MP topology between
the Ingress PE and the Egress PEs, the failure reporting and
processing procedures are implemented only on the edge nodes.
Failure events MAY cause one or more Egress PEs and associated leaves
to become detached from the PW tree. These events MUST be reported to
the Ingress PE, using appropriate out-band OAM messages.
The solution SHOULD allow the Ingress PE to be informed of Egress PEs
and associated leaves failure for management purposes.
Based on these failure notifications the solution MUST allow the
Ingress PE to update the remaining leaves of the PW tree.
- 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.
- In case of failure, it SHOULD correctly report which Egress PEs are
affected. This SHOULD be realized by enhancing existing PW methods,
such as LDP Notification for seamless and familiar operation. The
notification message SHOULD include the type of fault (P2MP PW, AC or
PSN tunnel).
- Respectively an Egress PE also MAY receive the status of the
Ingress PE's AC status.
- A solution MUST support OAM message mapping at the Ingress PE if
failure is detected on the AC. The Egress PE MUST report accordingly
at the service layer this OAM message on its associated AC.
3.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). In that 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.
Egress 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 Ingress 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 course P2MP PW switchover.
Jounay et al. Expires January 2010 [Page 9]
Internet Draft P2MP PW Requirements July 2009
CE1
|
active PE1 standby
P2MP PW .../ \....P2MP PW
/ \
P2 P3
/ \ / \
/ \ / \
/ \ / \
PE4 PE5 PE6 PE7
| | | |
| \ / |
\ CE2 /
\ /
-------CE3------
Ingress 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 Egress PE MUST be used to attach the
CE to the primary and the standby P2MP PW. The Egress PE MUST support
protection mechanism in order to select the active P2MP PW.
CE1
/ \
| |
active PE1 PE2 standby
P2MP PW1 | | P2MP PW2
| |
P2 P3
/ \/ \
/ /\ \
/ / \ _\
/ / \ \
PE4 PE5
| |
CE2 CE3
3.7. Scalability
The solution SHOULD scale at least as well as linearly with an
increase in the number of Egress PEs.
An increase in the number of P2MP PW SHOULD not cause the P router to
increase its forwarding table linearly.
The P2MP PW multiplexed/demultiplexed to P2MP PSN Tunnel can improve
the scalability.
Jounay et al. Expires January 2010 [Page 10]
Internet Draft P2MP PW Requirements July 2009
3.8. Order of Magnitude
This section will be filled in a future version.
Number of Egress PE, TAII per Egress PE, dynamicity (Leaf
Grafting/Pruning) required, etc.
4. P2MP MS-PW Requirements
4.1. P2MP MS-PW Pseudowire Reference Model
Figure 3 describes the P2MP MS-PW reference model which is derived
from [MS-PW ARCH] to support P2MP emulated services.
|<-----------P2MP MS-PW------------>|
Native | | Native
Service | |<-PSN1-->| |<--PSN2->| | Service
(AC) V V V V V V (AC)
| +----+ +-----+ +----+ |
| |T-PE| |S-PE |=========|T-PE| | +----+
| | 1 | | ......PW2.....>2 |---------->|CE4 |
| | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+ |
+----+ | | | | . |=========|T-PE| | +----+
|CE1 |-------->|........PW1......>......PW3.....>3.|---------->|CE5 |
+----+ | | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+ |
| | | | . |=========|T-PE| | +----+
+----+ | | | | . | ......>4.|---------->|CE6 |
|CE2 |<--------| | | . | . | | | +----+
+----+ | | | | ....PW4.. +----+ |
| | | | . | . +----+ |
| | | | . | . |T-PE| | +----+
| | | | . | ......>5.|---------->|CE7 |
| | | | . |=========| | | +----+
| | | | . | | | | +----+
| | | | . | | |---------->|CE8 |
| | | | . | +----+ | +----+
| | | | . |
| | | | . | +----+
| | | | .>|----->|CE3 |
| +----+ +-----+ +----+
Figure 3 P2MP MS-PW Reference Model
Jounay et al. Expires January 2010 [Page 11]
Internet Draft P2MP PW Requirements July 2009
Figure 3 extends the P2MP SS-PW architecture of Figure 1 to a multi-
segment configuration. In a P2P MS-PW configuration as described in
[RFC5254] the S-PE is responsible to switch a MS-PW from one input
segment to only one output segment, based on the PW identifier. Here
in a P2MP MS-PW configuration the S-PE is responsible to switch a MS-
PW from one input segment to one or several output segments.
Referring to Figure 3 T-PE1 is the Ingress T-PE and T-PE2, T-PE3, T-
PE4 and T-PE5 are the Egress T-PEs. In the reference model, the
Egress T-PEs are assumed to be located in the same PSN (PSN2), but it
could be envisioned that each output PW is located in a different PSN
(PSN2, PSN3, PSN4). The S-PE plays the role of branch S-PE since it
is in charge of switching simultaneously the input PW1 segment to the
output PW2, PW3, PW4 segments.
Referring to Figure 3, CE2, CE3, CE7 and CE8 MAY want to receive
multicast traffic from CE1. P2MP MS-PW solution MUST support such an
operational case where one or more ACs are connected to the same PE
and local replication is needed. A PE providing P2MP PW MUST support
the following functions:
- S-PE MUST support traffic replication over its directly connected
ACs toward receiver CEs if necessary, acting therefore as Egress T-
PE.
- Ingress T-PE MUST support traffic replication over its directly
connected ACs toward receiver CEs if necessary, in addition to PSN
transport.
- Egress T-E MUST support traffic replication over its directly
connected ACs toward receiver CEs if necessary.
A P2MP MS-PW MAY obviously transit through more than one S-PE along
its path.
A P2MP MS-PW, PW segment, can also be supported over a P2MP PSN
tunnel or a P2P PSN tunnel.
4.2. P2MP SS-PW Underlying Layer
Figure 4 describes an example of P2MP MS-PW topology relying on a
combination of both P2P and P2MP LSPs as PSN tunnels. PW segment over
P2P LSP MAY address inter-provider requirement. The PW tree is
composed of one Ingress PE (i1) and several Egress PEs (e1, e2, e3,
e4). The branch S-PEs are represented as b1, b2, b3, b4, b5. In that
case the traffic replication along the path of the PW tree is
performed at the PW level. For instance the branch S-PE b5 MUST
replicate incoming packets or data received from b2 and send them to
Egress T-PEs e3 and e4.
However giving the fact that some PW segments MAY be supported over a
P2MP LSP, the traffic replication along the path of these PW segments
can be performed as well at the underlying LSP level.
Jounay et al. Expires January 2010 [Page 12]
Internet Draft P2MP PW Requirements July 2009
Figure 4 describes the case where each segment is supported over a
P2P LSP except for the b1-b3 and b1-b4 segments which are conveyed
over a P2MP LSP on this section.
i1
/ \
b1 b2
/ \
/ \
/\ \
/ \ \
b3 b4 b5
/ \ / \
e1 e2 e3 e4
Figure 4 Example of P2P and P2MP underlying Layer for P2MP MS-PW
The P2MP PSN MAY be signaled with P2MP RSVP-TE [RFC4875] or MLDP
[MLDP].
4.3. P2MP MS-PW Signaling Requirements
4.3.1. Dynamically Instantiated P2MP MS-PW
The PW tree could be statically configured at the T-PEs and each S-PE
crossed. However it is RECOMMENDED that a solution provides the
ability to dynamically setup a MS-PW tree, by allowing the MS-PW
segments to be dynamically discovered.
During the PW tree setup, a branch S-PE SHOULD be capable to inform
the upstream PEs, including the Ingress T-PE that a set of Egress T-
PEs and associated leaves are not reachable.
4.3.2. P2MP MS-PW Setup Mechanisms
The requirements described in this section assume that dynamic setup
of MS-PW segments allows the T-PE and S-PEs to dynamically signal MS-
PW segments and stitch these segments in order to build the MS-PW
tree.
4.3.3. PW type mismatch
As described for P2MP SS-PW, the P2MP MS-PW requires ACs of the same
PW type. Therefore the segments composing the P2MP MS-PW MUST be also
of the same PW type [RFC4446]. The S-PE MAY only support switching
Jounay et al. Expires January 2010 [Page 13]
Internet Draft P2MP PW Requirements July 2009
PWs of the same PW type. In case of a different type, the passive PE
(S-PE or T-PE) MUST support mechanisms to reject attempts to
establish the P2MP MS-PW.
4.3.4. Interface Parameters sub-TLV
The section 3.4.2 is also relevant to P2MP MS-PW. When applicable,
the Egress T-PE or the Ingress T-PE MUST signal respectively its AC'
interface parameters to the Ingress T-PE or to the Egress T-PE so as
to make sure that AC at the Egress T-PE is capable to support traffic
coming from AC at the Ingress T-PE. In the P2MP MS-PW case, S-PEs
MUST propagate correctly this information.
In case of mismatch, the passive T-PE (Ingress or Egress T-PE,
depending on the signaling process) MUST support mechanisms to reject
attempts to establish the P2MP MS-PW.
4.3.5. Leaf Grafting/Pruning
Once the PW tree is setup, the solution MUST allow the addition or
removal of a leaf, or a subset of leaves to/from the existing tree,
without any impact on the PW tree (data and control planes) for the
remaining leaves.
4.3.6. Explicit Routing
The P2MP MS-PW signaling solution MUST provide a means of
establishing arbitrary P2MP MS-PW, according to pre-computed and
configured S-PE paths as well as dynamically computed S-PE paths on
the Ingress PE.
To support setup of explicitly routed MS-PW tree, the signaling
solution SHOULD support some source-based control that can explicitly
define particular S-PE nodes as branch S-PEs for the PW tree.
The solution SHOULD let possible Explicit Path Loose Hops (to be
defined). Therefore the P2MP MS-PW MAY be partially specified with
only a subset of intermediate branch S-PEs.
4.4. Failure Detection and Reporting
The solution SHOULD rely on specific OAM mechanisms to detect a node
(T-PE and S-PE) or segment failure of a PW tree. The solution SHOULD
also support the ability to inform the Ingress T-PE of the failure as
well as to indicate the identity of affected Egress T-PEs and
associated leaves.
Based on these failure notifications the solution MUST allow the
Ingress T-PE to update the remaining Egress PEs and associated leaves
of the PW tree.
Jounay et al. Expires January 2010 [Page 14]
Internet Draft P2MP PW Requirements July 2009
- 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.
- In case of failure, it SHOULD correctly report which Egress T-PEs
and branch S-PEs are affected. This SHOULD be realized by enhancing
existing unicast PW methods, such as LDP Notification for seamless
and familiar operation. The notification message SHOULD include the
type of fault (P2MP PW, AC or PSN tunnel).
- A solution MAY support OAM message mapping at T-PE if failure
happens i.e., mapping between AC service OAM and P2MP PW OAM. (Need
more discussion: in particular, when upstream T-PE AC fails, it can
be mapped to all downstream connection. Meanwhile downstream T-PE AC
failure does not impose other T-PEs AC.)
4.5. Protection and Restoration
The solution SHOULD provide mechanisms to recover as fast as possible
following a failure event. The fast protection/recovery is typically
dedicated to P2MP applications sensitive to traffic disruption.
Considering (i) a source-initiated PW tree setup and (ii) that a
local repair (PSN-tunnel or PW segment-based) is not feasible after a
failure event and that (iii) the PE upstream to the failure receives
by means of OAM mechanisms a message indicating that a subset of
Egress T-PEs are detached from the PW tree, the solution SHOULD allow
the upstream PE to re-compute the path to those particular Egress T-
PEs. If the upstream PE failed to compute an alternative path, the
procedure SHOULD be propagated upstream until the Ingress-PE is
reached.
It is also assumed that recovery procedures can be implemented at the
underlying P2P or P2MP LSP layer, using standard MPLS-based recovery
techniques. These procedures could be used to provide faster recovery
time in case of link or node failure affecting this layer.
A mechanism SHOULD be implemented to avoid race conditions between
recovery at the PSN level and recovery at the PW level.
4.6. Scalability
In definition of solution for P2MP MS-PW a particular attention MUST
be dedicated to scalability.
The solution MUST be designed to scale as well as linearly with an
increase in the number of leaves, Egress T-PEs, branch S-PEs. The
scalability issues MUST be addressed for the control plane (e.g.
Jounay et al. Expires January 2010 [Page 15]
Internet Draft P2MP PW Requirements July 2009
addressing of PW endpoints, number of signaling sessions, etc) and
for data plane (e.g. duplication of PW segments, OAM mechanism, etc).
4.7. Order of Magnitude
This section will be filled in a future version.
Number of Egress T-PE per tree, TAII per Egress T-PE, S-PE crossed,
replication supported per S-PE, dynamicity (Leaf Grafting/Pruning)
required, etc.
5. Manageability considerations
The solution SHOULD provide a simple provisioning procedure to build
a P2MP SS-PW or a P2MP MS-PW.
The solution MUST take into consideration the situation where the
Ingress PE and Egress PEs are not managed by a single NMS.
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 Ingress
PE.
6. Backward Compatibility
The solution SHOULD be completely backward compatible with
the current PW standards. The solution SHOULD take into account the
capability advertisement and negotiation procedures for the PEs
implementing P2MP PW endpoints.
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.
A solution MUST NOT allow PW connection with non-compliant PEs. It
MUST have a mechanism to report an error for non-compliant PEs. In
this case, it SHOULD report which PE (S-PE and T-PEs) are not
compliant.
In some cases, upstream traffic is required from downstream CE to
upstream CE.
A solution SHOULD allow co-existing operation with point-to-point PW
that provides upstream connection.
In particular, it is expected to be allowed that the same ACs are
shared between downstream and upstream direction. For downstream, a
CE receives from its connected AC traffic originated by the ingress
PE transported over a P2MP PW. For upstream, the CE MAY also send
Jounay et al. Expires January 2010 [Page 16]
Internet Draft P2MP PW Requirements July 2009
over the same AC traffic destined to the same remote PE transported
over point-to-point PW.
7. Security Considerations
This section will be added in a future version.
8. IANA Considerations
This draft does not define any new protocol element, and hence does
not require any IANA action.
9. Acknowledgments
The authors thank the contributors of [RFC4461] since the structure
and content of this document were, for some sections, largely
inspired by [RFC4461].
Many thanks to JL Le Roux and A. Cauvin for the discussions, comments
and support.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, March 1997.
[RFC3916] McPherson, D.,Pate, P., Xiao, X., "Requirements for
Pseudo-Wire Emulation Edge-to-Edge", September 2004
[RFC3985] Bryant, S., Pate, P. "PWE3 Architecture", March 2005
[RFC4461] Aggarwal, R., Farrel, A., Jork, M., Kamite, Y.,
Kullberg, A., Le Roux, JL., Malis, A., Papadimitriou,
D., Vasseur, JP., Yasukawa, S., "Signaling Requirements
for P2MP TE MPLS LSPs",April 2006
[RFC4875] Aggarwal, R., Papadimitriou, D., Yasukawa, S.,
"Extensions to RSVP-TE for Point-to-Multipoint TE LSPs",
MAY 2007
[RFC4446] Martini, L. "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", April 2006
[RFC5254] Bitar, N., Bocci, M., and Martini, L., "Requirements for
inter domain Pseudo-Wires", June 2008
Jounay et al. Expires January 2010 [Page 17]
Internet Draft P2MP PW Requirements July 2009
[RFC5332] Rosen, E. et al., "MPLS Multicast Encapsulations",
August 2008
10.2. Informative References
[MS-PW ARCH] Bocci, M., and Bryant, S.,T., " An Architecture for
Multi-Segment Pseudo Wire Emulation Edge-to-Edge",
Internet Draft, draft-ietf-pwe3-ms-pw-arch-06.txt,
February 2009
[SEG PW] Martini et al, "Segmented Pseudo Wire", Internet
Draft, draft-ietf-pwe3-segmented-pw-12.txt, June 2009
[MLDP] Minei, I., Wijnands, I., Thomas, B., "Label
Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", Internet Draft, draft-ietf-mpls-ldp-p2mp-07,
July 2009
[VPMS REQ] Kamite, Y., Jounay, F. "Framework and Requirements for
Virtual Private Multicast Service (VPMS)", Internet
Draft, draft-l2vpn-vpms-frmwk-requirements-01, July
2009
Author's Addresses
Frederic Jounay
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: frederic.jounay@orange-ftgroup.com
Philippe Niger
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: philippe.niger@orange-ftgroup.com
Yuji Kamite
NTT Communications Corporation
Tokyo Opera City Tower
3-20-2 Nishi Shinjuku, Shinjuku-ku
Tokyo 163-1421
Japan
Email: y.kamite@ntt.com
Jounay et al. Expires January 2010 [Page 18]
Internet Draft P2MP PW Requirements July 2009
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
EMail: lmartini@cisco.com
Giles Heron
Tellabs
Abbey Place
24-28 Easton Street
High Wycombe
Bucks
HP11 1NT
UK
EMail: giles.heron@tellabs.com
Simon Delord
Uecomm
658 Church St
Richmond, VIC, 3121, Australia
E-mail: sdelord@uecomm.com.au
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
Martin Vigoureux
Alcatel-Lucent France
Route de Villejust
91620 Nozay
FRANCE
Email: martin.vigoureux@alcatel-lucent.fr
Matthew Bocci
Alcatel-Lucent Telecom Ltd,
Voyager Place
Shoppenhangers Road
Maidenhead
Berks, UK
E-mail: matthew.bocci@alcatel-lucent.co.uk
Lizhong JIN
Jounay et al. Expires January 2010 [Page 19]
Internet Draft P2MP PW Requirements July 2009
Nokia Siemens Networks
Building 89, 1122 North QinZhou Road,
Shanghai, 200211, P.R.China
Email: lizhong.jin@nsn.com
Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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.
Jounay et al. Expires January 2010 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-21 03:19:52 |