One document matched: draft-jounay-pwe3-p2mp-pw-requirements-01.txt
Differences from draft-jounay-pwe3-p2mp-pw-requirements-00.txt
Network Working Group F. Jounay
Internet Draft P. Niger
Category: Informational Track France Telecom
Expires: May 2008
Y. Kamite
L. Martini NTT Communications
Cisco
S. Delord
G. Heron Uecomm
Tellabs
L. Wang
R. Aggarwal Telenor
Juniper Networks
November 20, 2007
Use Cases and signaling requirements for Point-to-Multipoint PW
draft-jounay-pwe3-p2mp-pw-requirements-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 May 20, 2008.
Abstract
This document provides some use cases advocating for the definition
of a unidirectional Point-to-Multipoint Pseudowire (P2MP PW) and its
relevant Virtual Private P2MP Service (VPMS). Based on these use
cases it also presents a set of requirements for the set up and
Jounay et al. Expires May 20, 2008 [Page 1]
Internet Draft P2MP PW Requirements November 2007
maintenance of P2MP PW, proposed as guidelines for possible
solutions.
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. Use Cases for P2MP PW...........................................5
3.1. Ethernet-based Use Case.......................................5
3.2. TDM-based Use Case............................................6
3.3. ATM-based Use Case............................................6
4. P2MP SS-PW Requirements.........................................7
4.1. P2MP SS-PW Reference Model....................................7
4.2. P2MP SS-PW Underlying Layer...................................8
4.3. P2MP SS-PW Signaling Requirements.............................9
4.3.1. Leaf Grafting/Pruning.......................................9
4.4. Failure Reporting and Processing..............................9
4.5. Advertisement of P2MP Capability..............................9
4.6. Scalability..................................................10
4.7. Order of Magnitude...........................................10
5. P2MP MS-PW Requirements........................................10
5.1. P2MP MS-PW Pseudowire Reference Model........................10
5.2. P2MP SS-PW Underlying Layer..................................11
5.3. P2MP MS-PW Signaling Requirements............................12
5.3.1. Dynamically Instantiated P2MP MS-PW........................12
5.3.2. P2MP MS-PW Setup Mechanisms................................12
5.3.3. Leaf Grafting/Pruning......................................12
5.3.4. Explicit Routing...........................................12
5.4. Failure Reporting............................................13
5.5. Protection and Restoration...................................13
5.6. Advertisement of P2MP Capability.............................14
5.7. Scalability..................................................14
5.8. Order of Magnitude...........................................14
6. Manageability considerations...................................14
7. Backward Compatibility.........................................15
8. Security Considerations........................................15
9. IANA Considerations............................................15
10. Acknowledgments...............................................15
11. References....................................................15
11.1. Normative References........................................15
Jounay et al. Expires May 20, 2008 [Page 2]
Internet Draft P2MP PW Requirements November 2007
11.2. Informative References......................................16
Authors' Addresses................................................17
Intellectual Property and Copyright Statements....................18
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.
For some use cases described hereafter, some P2MP services require
the use of Pseudowire for their encapsulation capabilities. This
could be achieved using a set of point to point PWs, with traffic
replication on the CE, but faces obvious bandwidth limitation issues,
as traffic is carried multiple time on shared links.
This document defines the use of a Point-to-Multipoint PW (P2MP PW).
A Point-to-Multipoint (P2MP) Pseudo Wire (PW) is a mechanism that
emulates the essential attributes of a unidirectional 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. They follow the PWE3 architecture as
described in [RFC3985] with modifications as outlined in this
document. One notable difference between point-to-point (P2P) PWs as
outlined in [RFC3985] and P2MP PWs is that the former emulate a
bidirectional service whereas the latter emulate a unidirectional
service.
This document aims at describing possible use cases for P2MP PW and
defining the associated requirements related to the P2MP PW setup and
maintenance.
It is intended that solutions that specify procedures and protocols
or extensions to existing protocols for the signaling of P2MP
Pseudowire satisfy these requirements.
Jounay et al. Expires May 20, 2008 [Page 3]
Internet Draft P2MP PW Requirements November 2007
1.2. Scope of the document
The first part of the document aims at listing a set of use cases
which would take benefits of the use of VPMS based a unidirectional
P2MP Pseudowire rather than multiple VPWS based point to point
Pseudowires.
The second part describes the 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, maintenance, etc,
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
VPMS: Virtual Private P2MP Unidirectional Service
2.2. Terminology
This document uses terminology described in [MS-PW REQ], [MS-PW
ARCH], [SEG PW].
It also introduces additional terms needed in the context of
unidirectional 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
Jounay et al. Expires May 20, 2008 [Page 4]
Internet Draft P2MP PW Requirements November 2007
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.
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.
3. Use Cases for P2MP PW
3.1. Ethernet-based Use Case
P2MP PWs enable a L2VPN with Ethernet CEs to provide a unidirectional
Virtual Private P2MP multicast service (VPMS). This may be in
addition to the Virtual Private Wire Service (VPWS) provided by the
L2VPN. Such a service may be required when Virtual Private LAN
Emulation Service (VPLS) is not desired and there is a requirement to
deliver a unidirectional P2MP multicast service in addition to the
VPWS service. Currently the only possible service that a Service
Provider (SP) can offer to a customer that requires a P2MP
unidirectional Ethernet service over a PSN is a VPLS service. VPLS
natively requires MAC-based learning and forwarding. However video
distribution applications generally require a P2MP distribution and
may not require the added expense of MAC learning.
VPLS natively provides any-to-any connectivity between the CEs as it
emulates a LAN, but for some applications that provide just point-to-
multipoint type transport, traffic from receiver to sender is not
needed, and traffic between different receivers directly are not
Jounay et al. Expires May 20, 2008 [Page 5]
Internet Draft P2MP PW Requirements November 2007
needed, either. In this case, P2MP VPMS provides much simpler
operation to it.
Note that P2MP PW has a limitation in the point of its uni-
directional service model. If the application layer needs bi-
directional communication at CE, some additional techniques may be
necessary to support.
3.2. TDM-based Use Case
In a PSN environment, PWs allow supporting 2G/3G mobile backhauling
(e.g. TDM traffic for GSM's Abis interface, ATM traffic for Release
99 UMTS's Iub interface). At the time being, the Mobile backhauling
architecture is always built as a star topology between the 2G/3G
controller (e.g. BSC or RNC) and the 2G/3G Base Stations (BTS or
NodeB). Therefore P2P PWs are used between each Base Station and
their corresponding controller and nothing more is required.
As far as synchronization in a PSN environment is concerned,
different mechanisms can be considered to provide frequency and phase
clock required in the 2G/3G Mobile environment to guarantee mobile
handover and strict QoS. One of them consists in using Adaptive Clock
Distribution and Recovery. With this method a Master element
distributes a reference clock at protocol level by regularly sending
TDM PW packets (SAToP, CESoPSN or TDMoIP) to Slave elements. This
process is based on the fact that the volume of transmitted data
arrival is considered as an indication of the source frequency that
could be used by the Slave element to recover the source clock
frequency. Consequently, with the current methods, the PE connected
to the Master must setup and maintain as many P2P PWs as we have
Slave elements, and the Master has to replicate the traffic. A better
solution to deliver the clock frequency would be to use a VPMS based
on P2MP PW. This may scale much more than P2P PWs with regards to the
forwarding plane at the Master since the traffic is no more
replicated to the P2P PWs but only to the AC associated to the P2MP
PW. It may ease the provisioning process since only one PW source
endpoint must be configured at the Ingress PE. This alleviated
provisioning process would be particularly appreciated for the
introduction of new Base Stations. The main gain would be to avoid
replication on the Master and hence save bandwidth consumed by the
synchronization traffic which typically requires the highest level of
QoS. This kind of traffic will be competing with equivalent QOS
traffic like VoIP, that is why it is significant to save the
slightest bandwidth.
3.3. ATM-based Use Case
A use case of ATM-based P2MP PW could be to offer the capability for
service providers to support IP multicast wholesale services over ATM
in case the wholesale customer relies on ATM infrastructure. The PW
Jounay et al. Expires May 20, 2008 [Page 6]
Internet Draft P2MP PW Requirements November 2007
P2MP alleviates the constraint in terms of replication for ATM to
support IP multicast services. Today most video distribution networks
require point-to-multipoint as well as point-to-point transport for
live broadcasting and non-live contents distribution. As for point-
to-multipoint traffic, there are some traditional approaches to
convey it, for example, by ATM based duplication (point-to-multipoint
PVP/PVCs). Terminal CE devices in such environment support legacy
protocol interfaces only as such. However, the trend to migrate such
an old network onto MPLS/IP-based backbone is still growing now.
Hence it is expected that a standard Pseudo Wire setup/encapsulation
method will support point-to-multipoint transport of various kinds of
conventional protocols.
4. P2MP SS-PW Requirements
4.1. P2MP SS-PW Reference Model
A unidirectional 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 DLCI, an ATM VPI/VC, an Ethernet port, a
VLAN, a HDLC link, a PPP connection on a physical interface.
Figure 1 describes the P2MP SS-PW reference model which is derived
from [RFC3985] to support P2MP emulated services.
|<-----------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
Jounay et al. Expires May 20, 2008 [Page 7]
Internet Draft P2MP PW Requirements November 2007
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. P Router is joining P2MP PSN tunnel operation but
is free from signaling of P2MP PW. P2MP PW operation is associated
with PE1, PE2, PE3 and PE4.
Referring to Figure 1, CE2 and CE5CE6 may want to receive multicast
traffic from CE1. A PE providing VPMS 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.
P2MP SS-PW and P2MP MS-PW outlined in section 5 solution MUST support
such an operational case where one or more ACs are connected to the
same PE and local replication is needed.
4.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).
Depending on the Traffic-Engineering requirements, the P2MP PSN will
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
Jounay et al. Expires May 20, 2008 [Page 8]
Internet Draft P2MP PW Requirements November 2007
4.3. P2MP SS-PW Signaling Requirements
4.3.1. 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.4. Failure Reporting and Processing
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 in-band or 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.
- In case of failure, it SHOULD correctly report which leaf PEs are
affected. It SHOULD be realized by enhancing existing unicast PW
methods, such as VCCV for seamless and familiar operation.
- A solution MAY support OAM message mapping at PE if failure happens
i.e., mapping AC service OAM between P2MP PW OAM. (This needs more
discussion)
In addition it is assumed that if recovery procedures are required
the P2MP LSP will support the classic recovery techniques mainly
based on RSVP-TE. A mechanism should be implemented to avoid race
conditions between recovery at the PSN level and recovery at the PW
level.
4.5. Advertisement of P2MP Capability
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 SS-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.
Jounay et al. Expires May 20, 2008 [Page 9]
Internet Draft P2MP PW Requirements November 2007
4.6. Scalability
The solution should scale at least as well as linearly with an
increase in the number of Egress PEs.
The solution SHOULD provide a simple provisioning procedure to build
a P2MP SS-PW. This is related to manageability not scalability.
4.7. 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.
5. P2MP MS-PW Requirements
5.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.|-----------|CE2 |
| | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+ |
+----+ | | | | . |=========|T-PE| | +----+
|CE1 |---------|........PW1.........|...PW3......3.|-----------|CE3 |
+----+ | | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+ |
| | | | . |=========|T-PE| | +----+
| | | | . | .......4.|-----------|CE4 |
| | | | . | . | | | +----+
| | | | ....PW4.. +----+ |
| | | | | . +----+ |
| | | | | . |T-PE| | +----+
| | | | | .......5.|-----------|CE5 |
| | | | |=========| | | +----+
| +----+ +-----+ +----+ |
Figure 3 P2MP MS-PW Reference Model
Jounay et al. Expires May 20, 2008 [Page 10]
Internet Draft P2MP PW Requirements November 2007
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
[MS-PW REQ] 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.
Note that a P2MP MS-PW may obviously transit through more than one S-
PE along its path.
Note that if the P2MP SS-PW case mandatory implies the use of P2MP
PSN tunnel (underlying layer) between the edge nodes, the P2MP MS-PW
does not imply such a requirement since each PW segment can be
supported over a P2P PSN tunnel. However as we will see hereafter,
the coexistence of both kind of PSN tunnel (P2P and P2MP) MUST be
considered, as described in Figure 3 where the P2MP PW3 segment is
supported over P2MP LSP.
5.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. 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.
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.
Jounay et al. Expires May 20, 2008 [Page 11]
Internet Draft P2MP PW Requirements November 2007
i1
/ \
b1 b2
/ \
/ \
/\ \
/ \ \
b3 b4 b5
/ \ / \
e1 e2 e3 e4
Figure 4 Example of P2P and P2MP underlying Layer for P2MP MS-PW
Depending on the Traffic-Engineering requirements, the P2MP PSN may
be signaled with P2MP RSVP-TE [P2MP-RSVP-TE or MLDP [MLDP].
As for the P2MP SS-PW and for the same purpose the PHP (Penultimate
Hop Popping) must be deactivated on the P2MP LSP as described in 4.2.
5.3. P2MP MS-PW Signaling Requirements
5.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 stitched.
5.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.
It is RECOMMENDED that the solution provides various optimization
options in the P2MP MS-PW construction (Traffic-Engineered P2MP MS-
PW).
5.3.3. 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.
5.3.4. Explicit Routing
The P2MP MS-PW signaling solution MUST provide a means of
establishing arbitrary P2MP MS-PW, according to pre-computed and
Jounay et al. Expires May 20, 2008 [Page 12]
Internet Draft P2MP PW Requirements November 2007
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.
5.4. Failure 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.
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 in accordance with the
local PW addresses routing table.
- A solution MUST support in-band OAM mechanism to detect failures:
unidirectional point-to-multipoint traffic failure.
- In case of failure, it SHOULD correctly report which leaf T-PEs and
branch S-PEs are affected. It SHOULD be realized by enhancing
existing unicast PW methods, such as VCCV for seamless and familiar
operation.
- A solution MAY support OAM message mapping at T-PE if failure
happens i.e., mapping AC service OAM between 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.)
5.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
Jounay et al. Expires May 20, 2008 [Page 13]
Internet Draft P2MP PW Requirements November 2007
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 classic 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.
5.6. Advertisement of P2MP Capability
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 T-PEs
implementing P2MP MS-PW endpoints and branch S-PEs.
Implementation of OAM mechanisms also implies the advertisement of PE
capabilities to support specific OAM features. The solution MAY allow
advertising P2MP OAM PW capabilities.
5.7. Scalability
In definition of solution for P2MP MS-PW a particular attention must
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.
addressing of PW endpoints, number of signaling sessions, etc) and
for data plane (e.g. duplication of PW segments, OAM mechanism, etc).
5.8. 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.
6. Manageability considerations
This section will be added in a future version.
Jounay et al. Expires May 20, 2008 [Page 14]
Internet Draft P2MP PW Requirements November 2007
7. Backward Compatibility
- 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.
- (Potential work item: Performance Management)
- (Potential work item: Upstream traffic handling)
In some cases, upstream traffic is required from downstream CE to
upstream PE.
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 traffic from its connected AC that traversed over P2MP
PW. For upstream, the CE can also send traffic over the same AC to
PE and it is transported over point-to-point PW.
8. Security Considerations
This section will be added in a future version.
9. IANA Considerations
This draft does not define any new protocol element, and hence does
not require any IANA action.
10. 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.
11. References
11.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
Jounay et al. Expires May 20, 2008 [Page 15]
Internet Draft P2MP PW Requirements November 2007
[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
11.2. Informative References
[MS-PW REQ] Bitar, N., Bocci, M., and Martini, L., "Requirements
for inter domain Pseudo-Wires", Internet Draft, draft-
ietf-pwe3-ms-pw-requirements-05.txt, March 2007
[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-03.txt,
June 2007
[SEG PW] Martini et al, "Segmented Pseudo Wire", Internet
Draft, draft-ietf-pwe3-segmented-pw-05.txt, July
2007
[VPLS MCAST REQ] Fang, L., Morin, T., Kamite, Y., Serbest, Y.,
"Requirements for Multicast Support in Virtual Private
LAN Services", Internet Draft, draft-ietf-l2vpn-vpls-
mcast-reqts-05.txt, September 2007
[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-03,
July 2007
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
Jounay et al. Expires May 20, 2008 [Page 16]
Internet Draft P2MP PW Requirements November 2007
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
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
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
Jounay et al. Expires May 20, 2008 [Page 17]
Internet Draft P2MP PW Requirements November 2007
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jounay et al. Expires May 20, 2008 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-22 09:13:47 |