Network Working Group F. Jounay (Editor)
Internet Draft P. Niger
Category: Standards Track France Telecom
Expires: September 2009
Y. Kamite
L. Jin NTT Communications
Nokia Siemens
L. Ciavaglia
M. Vigoureux
Alcatel-Lucent March 09, 2009
LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire
draft-jounay-niger-pwe3-source-initiated-p2mp-pw-02.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 September 09, 2009.
Abstract
This document provides a solution to extend Label Distribution
Protocol (LDP) signaling in order to allow set up and maintenance of
Point-to-Multipoint Pseudowire (P2MP PW). Such an extension of
existing point to point Pseudowire is made necessary by new
Jounay et al. Expires September, 2009 [Page 1]
Internet Draft Source-initiated P2MP PW Setup March 2009
applications. The document deals with the source-initiated P2MP PW
setup and maintenance.
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. Terminology.....................................................3
2. Preliminary Notes...............................................3
3. Introduction....................................................3
4. P2MP SS-PW Setup Mechanism......................................3
4.1. P2MP SS-PW Reference Model....................................3
4.2. Overview of the P2MP SS-PW Setup..............................4
4.3. LDP...........................................................5
4.4. P2MP Generalized ID FEC Element...............................5
4.4.1. P2MP GID FEC Element........................................6
4.4.2. TAII Leaf Sub-TLV...........................................8
4.5. Signaling for P2MP SS-PW.....................................10
4.5.1. Configuration/Provisioning.................................10
4.5.2. Capability Negotiation Procedure...........................10
4.5.3. Signaling Process..........................................10
4.5.4. Leaf Attachment Notification Message.......................11
4.5.5. PW Type Mismatch...........................................12
4.5.6. Interface Parameters.......................................12
4.5.7. Interface ID (Underlying P2MP PSN tunnel)..................12
4.5.8. Leaf Grafting/Pruning......................................14
4.6. Failure Reporting (to be completed)..........................14
4.7. Protection and Restoration...................................15
5. Security Considerations........................................15
6. IANA Considerations............................................15
6.1. LDP FEC Type.................................................16
6.2. LDP Status Codes.............................................16
7. Acknowledgments................................................16
8. References.....................................................16
8.1. Normative References.........................................16
8.2. Informative References.......................................17
Authors' Addresses................................................17
Intellectual Property and Copyright Statements....................18
Jounay et al. Expires September 9, 2009 [Page 2]
Internet Draft Source-initiated P2MP PW Setup March 2009
1. Terminology
This document uses acronyms and terminologies defined in [RFC5036],
[RFC3985], [P2MP PW REQ] and [RFC5254].
2. Preliminary Notes
The current version of the document does not cover:
- Leaf-initiated unidirectional P2MP PW setup, Leaf-initiated
grafting/pruning. This mode is described in a separate document [LEAF
INIT P2MP PW].
- Downstream Label Assignment for the P2MP PW label. The solution
relies on [LDP UPSTREAM] for the PW Label Assignment since the
underlying layer is assumed to be a P2MP PSN tunnel. For the MS-PW
architectures which do not imply the use of an underlying P2MP LSP to
support the PW segment but a P2P LSP this mode is not necessary. The
P2MP PW Downstream Label Assignment and detailed procedures for
setting up a P2MP PW over a P2P LSP will be described in a future
version.
The Working Group feedback is required on the points described above.
3. Introduction
[RFC4447] describes a mechanism for establishing Point-to-Point
Single-Segment Pseudowire (P2P SS-PW). [DYN MS-PW] describes a
mechanism for establishing P2P Multi-Segment Pseudowire (P2P MS-PW).
These specifications do not provide a solution for setting up a
point-to-multipoint Pseudowire (P2MP PW).
This document defines extensions to the LDP protocol [RFC5036],
[RFC4447], to support P2MP PW satisfying the set of requirements
described in [P2MP PW REQ].
The document presents first a solution to setup a P2MP SS-PW. The
proposed solution relies on the definition of a P2MP FEC element
derived from the FEC129 used the single-side provisioning of a P2P PW
setup.
4. P2MP SS-PW Setup Mechanism
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 one
Jounay et al. Expires September 9, 2009 [Page 3]
Internet Draft Source-initiated P2MP PW Setup March 2009
or more Egress PEs connected to traffic receivers. The PW endpoints
connect the PW to its attachment circuits (AC). As for a P2P PW
[RFC3985], 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. Note that the use of P2MP PW is only relevant for
multicast native protocol.
Figure 1 describes the P2MP SS-PW reference model which is extracted
from [P2MP PW REQ] 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
This architecture applies to the case where a P2MP PSN tunnel extends
among 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. The Ingress PE supports traffic replication over
its directly connected ACs toward receiver CEs if necessary, in
addition to PSN transport. The Egress PE supports traffic replication
over its directly connected ACs toward receiver CEs if necessary.
4.2. Overview of the P2MP SS-PW Setup
[RFC4447] defines the LDP signaling for establishing a P2P PW. When a
PW is set up, the LDP signaling messages include a forwarding
equivalence class (FEC) element containing information about the PW
Jounay et al. Expires September 9, 2009 [Page 4]
Internet Draft Source-initiated P2MP PW Setup March 2009
type and an endpoint identifier used by the Ingress and Egress PEs
for the selection of the PW forwarder that binds the PW to the
attachment circuit at each end.
There are two types of FEC elements in [RFC4447] defined for this
purpose: PWid FEC (type 128) and the Generalized ID (GID) FEC (type
129). The FEC128 and the FEC129 are used respectively for the double-
side provisioning or the single-side provisioning of a P2P PW setup
This document defines a P2MP PW FEC element derived from the FEC129
to setup a P2MP SS-PW.
The Ingress PE maintains one signaling LDP session with every Egress
PE. Since the P2MP PW is unidirectional and to avoid replication,
after a negotiation procedure between Ingress and Egress PEs, the
Upstream Label Assignment [LDP UPSTREAM] MUST be used for the PW
label allocation. In case of source-initiated PW tree setup, the
Ingress PE initiates the LDP Label Mapping message to announce the PW
label used to convey the traffic to the Egress PEs.
As represented in Figure 1 the unidirectional P2MP SS-PW relies on
the usage of P2MP LSP (s) as PSN tunnel(s) underlying layer,
established between the Ingress PE and all Egress PEs.
4.3. LDP
The PW label bindings are distributed using the LDP upstream
unsolicited label distribution, liberal label retention mode
described in [LDP UPSTREAM] and [RFC5036]. The Ingress PEs will
establish LDP session using the Extended Discovery mechanism
described in [RFC5036] with each Egress PEs. For setting up and
maintaining pseudowires, each FEC TLV MUST contain exactly one FEC
element.
Note that the Ingress PE does not need to receive a Label Request
from the Egress PE to send the Upstream Label Mapping message.
In this specification, we define a FEC Element TLVs to be used for
identifying point-to-multipoint pseudowires.
4.4. P2MP Generalized ID FEC Element
The P2MP GID FEC element is derived from the GID FEC (FEC129) element
defined in [RFC4447].Based on the PW AII address type, the GID FEC
used for P2P PW setup is extended to propose:
- a P2MP GID (Generalized ID) FEC element containing a VPN
identifier, a P2MP identifier and a P2MP PW source address (SAII)
Jounay et al. Expires September 9, 2009 [Page 5]
Internet Draft Source-initiated P2MP PW Setup March 2009
- a TAII Leaf sub-TLV containing the list of the P2MP PW destination
addresses (leaf nodes identified by AIIs) to be attached to the PW
tree.
4.4.1. P2MP GID FEC Element
The P2MP GID FEC Element is derived from the format of the GID FEC
Element (FEC129) defined in [RFC4447].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP GID (TBD)|C| PW Type |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP Id | Length | P2MP Id Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ P2MP Id Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a Notification message have to be exchanged between peer PEs
(see below detailed fo a detail description of procedures), the P2MP
GID FEC MUST be included in the LDP Notification message to identify
the PW tree to which it applies.
The AGI (Attachment Group Identifier) is VPN-id, which plays the same
role as for the GID FEC. The same AGI value MUST be configured at all
endpoints of the PW tree (Ingress and Egress PEs). Note that the AGI
SHOULD be used to identify the VPMS instance as outlined in
[VPMS REQ].
The AGI is a four-octet number and is unique within the scope of the
PE.
The SAII (Source Attachment Individual Identifier) is attached to the
Ingress PE and identifies the PW tree source. In other words the PW
tree is rooted with one Attachment Circuit (AC) at the ingress PE.
The attachment circuit address type is derived from [RFC5003] AII
type 2 shown here:
Jounay et al. Expires September 9, 2009 [Page 6]
Internet Draft Source-initiated P2MP PW Setup March 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (contd.) | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (contd.) | AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AGI and the SAII have the same structure than for the FEC 129
defined in [RFC4447] and [RFC5003].
In P2MP GID FEC element, the TAII field structure that was defined in
Section 5.3.2 of [RFC4447] is now replaced with a P2MP Identifier
(P2MP Id). The PW tree is identified by means of the pair (SAI, P2MP
Identifier).The P2MP identifier is required in particular for some
P2MP make-before-break function (see 4.8 section).
The P2MP Id is a four-octet number.
In some cases an operator may offer a VPMS delivering multicast
content to several customers (wholesale). In such a case P2MP ID
allows to assign one P2MP PW per wholesale customer (or other service
entity) while considering a single VPMS (AGI1). In that scenario the
operator provides a single VPMS for the service delivery but make a
customer differentiation thanks to the P2MP ID. The P2MP ID allows
the operator to consider two different P2MP PW to guarantee a
specific SLA per customer. The specific SLA MAY rely on a different
QoS marking or the use of a different P2MP PSN tunnel (TE and not TE
LSP). In the Figure below, PE4 and PE5 are Egress PEs connected to
wholesale customer A, PE6 and PE7 Egress PEs to wholesale customer B.
Wholesale customers A and B receive the same traffic from different
P2MP PW since the traffic is received for both P2MP PWs from the same
SAII.
|(SAII)
P2MP PW1 PE P2MP PW2
(AGI1, SAII, P2MP1) .../ \.... (AGI1, SAII, P2MP2)
/ \
P2 P3
/ \ / \
/ \ / \
/ \ / \
PE4 PE5 PE6 PE7
|(TAII)| |(TAII)|
wholesale wholesale
customer A customer B
Jounay et al. Expires September 9, 2009 [Page 7]
Internet Draft Source-initiated P2MP PW Setup March 2009
All remaining fields are unchanged compared to their definition in
[RFC4447], including the Control Word (C bit).
4.4.2. TAII Leaf Sub-TLV
A TAII Leaf sub-TLV is defined in order to carry the information
regarding the P2MP PW destination addresses at the Egress PE(s) to be
connected to the PW tree.
The AII type 2 format defined in [RFC5003] and reminded in section
4.4.1 is also used as the address type of the TAII Leaf sub-TLV.
The TAII Leaf sub-TLV has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| TAII Leaf Type TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ ------------------- ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ U-bit
Unknown TLV bit
U is clear (=0), upon receipt of an unknown TLV, a notification with
status code "unknown TLV" MUST be returned to the message originator
and the entire message MUST be ignored
+ F-bit
Forward unknown TLV bit
F is clear (=0), the unknown TLV is not forwarded with the containing
message;
Jounay et al. Expires September 9, 2009 [Page 8]
Internet Draft Source-initiated P2MP PW Setup March 2009
The TAII has the same structure than in the FEC 129 defined in
[RFC4447]. The TAII Leaf sub-TLV comprises a list of one or more TAII
Leaf identifiers.
The TAII Leaf sub-TLV MUST be included in the Label Mapping message
initiated by the Ingress PE.
The TAII Leaf sub-TLV is carried as follows in the Label Mapping
message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ P2MP Generalized ID FEC +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Parameters |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Generic Label (0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Assigned Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW Status (0x096A) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| TAII Leaf Type TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Interface ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that in the SS-PW topology, the Ingress PE MUST maintain one
signaling session with each Egress PE. The TAII Leaf sub-TLV for a
given signaling session conveys the TAII leaves related to the
corresponding Egress PE. For instance if the Egress PE supports only
one AII associated to the PW tree, the TAII Leaf sub-TLV will include
only one TAII.
Jounay et al. Expires September 9, 2009 [Page 9]
Internet Draft Source-initiated P2MP PW Setup March 2009
4.5. Signaling for P2MP SS-PW
4.5.1. Configuration/Provisioning
Referring to Figure 1, if the P2MP GID FEC is used the Ingress PE
(PE1) MUST be configured with the AGI, SAII and P2MP Id. SAI is
considered as the Source Attachment Identifier of the PW tree. Each
Egress PE MUST be configured with one or more leaf-TAII corresponding
to one or more leaves of the PW tree. The AGI and P2MP Id MUST be the
same for all endpoints of the PW tree. Once the ACs are configured at
all endpoints, the provisioning next step for the PW tree
establishment consists in specifying at the Ingress PE all the leaf-
TAIIs identifying the leaves of the PW tree at the Egress PE(s).
The IP address of the Egress PEs where the Attachment Circuits are
connected can be configured manually or learnt dynamically by means
of auto discovery protocol at Ingress PE. Detailed mechanism of such
auto discovery protocol is out of scope of this document.
4.5.2. Capability Negotiation Procedure
To achieve the capability negotiation the solution MUST follow the
LDP capability advertisement mechanism described in [LDP CAPA].
The PEs belonging to the PW tree MUST support the same P2MP PW FEC
element. Procedures defined in [RFC5036] must apply in case of FEC
element mismatch.
The unidirectional P2MP SS-PW is supported over a P2MP LSP(s), so
Upstream Label Assignment as defined in [LDP UPSTREAM] MUST be used
to prevent replication at the PW level. This also guarantees not to
waste the network bandwidth. A PE, which supports upstream label
assignment, can advertise its capability by inserting an Upstream
Label Assignment Capability sub-TLV in the LDP Capability TLV, as
defined in [LDP UPSTREAM]
The Ingress PE SHOULD also negotiate with its remote Egress PEs the
capability of supporting the PW status TLV [RFC4447]. This
negotiation is a key element in order to allow the Egress PEs to
announce some status information later on to the Ingress PE.
4.5.3. Signaling Process
After the Ingress PE is manually configured or discovers dynamically
by means of an auto-discovery protocol its peer PEs, it initiates a
signaling with every Egress PE.
For P2MP GID FEC-based PW
i. A Label Mapping message is sent to every Egress PE containing
the SAII configured as the source at the Ingress PE. The TAII
Jounay et al. Expires September 9, 2009 [Page 10]
Internet Draft Source-initiated P2MP PW Setup March 2009
Leaf sub-TLV includes one or more AII associated to the
Attachment Circuits of the Egress PE(s) defined as leaves of
the PW tree.
4.5.4. Leaf Attachment Notification Message
When the Egress PE receives and processes the Label Mapping message,
it verifies the P2MP GID/leaf-TAII(s) and checks if it matches one of
its configured Forwarders.
For P2MP GID FEC-based PW
i. The (AGI, P2MP Id) fields from the P2MP GID FEC Element in
the Label Mapping message must be the same as the ones
configured on the Egress PE. If not, the Label Mapping is
retained according to LDP liberal label retention
procedure.
In the case the matching is correct the following procedure
must be followed:
ii. If at least one matching is found among the TAII Leaves,
the Egress PE carries on the process by responding with a
PW Status Notification message to the Ingress PE in order
to inform it about its tree attachment. The PW status TLV
informs the Ingress PE that the Egress PE and some
associated leaf(ves) is from now on part of the PW tree.
For that purpose the TAII Leaf sub-TLV is attached to the
LDP Notification message. The TAII Leaf sub-TLV contains
the TAII leaves successfully connected to the PW tree.
Therefore the Ingress and the Egress PEs update their PW-
to-label bindings. Thanks to the TAII Leaf sub-TLV the
Ingress PE can deduce which TAII are connected and which
are not.
iii. When no TAII leaf matches with one of the leaf-TAIIs
configured at the Egress PE, the following procedure must
be applied:
. If the leaf-TAII received by the PE contains the prefix
of a locally provisioned prefix on that PE, but an AC
ID that is not provisioned, then the LDP liberal label
retention procedures apply, and the Label Mapping
message is retained. The Ingress PE will update its PW-
to-label bindings upon receipt of a LDP Notification
message later on.
. If no matching (including the global-ID and prefix) is
found among the TAII Leaves, a LDP Notification MUST be
returned to the PE with a status message of
Unassigned/Unrecognized TAII.
Jounay et al. Expires September 9, 2009 [Page 11]
Internet Draft Source-initiated P2MP PW Setup March 2009
4.5.5. 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 Egress PE MUST abort processing the message, and
send an "Non Compliant PW Type" Notification message to its LDP peer
signaling an error.
"Non Compliant PW Type" TBD
4.5.6. Interface Parameters
Some interface parameters [RFC4446] related to the AC capability
have been defined according to the PW type and are signaled during
the PW setup from the Egress PE to the Ingress PE.
Note that the Interface Parameters are carried in a separate TLV in
the LDP Label Mapping message as outlined in [RFC4447] section 5.5.
This mechanism used for the P2P PW setup SHOULD 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.
Note that the signaling of such parameters is not mandatory and can
also be configured statically at PW endpoints.
When the interface parameters are signalled by the Ingress PE, the
Egress PE must check if its configured value(s) is inferior or equal
to the threshold value fixed by the Ingress PE (e.g. MTU size
(Ethernet), number max of concatenated ATM cells, etc)). For other
interface parameters like CEP/TDM Payload bytes (TDM), the value
MUST match exactly at the Ingress and at the Egress PEs. If the
value configured at the Egress PE is not appropriate to receive the
traffic, a LDP Notification MUST be returned to the T-PE with a
status message indicating the appropriate "interface parameters
incompatibility" as defined in [RFC4446].
4.5.7. Interface ID (Underlying P2MP PSN tunnel)
The P2MP SS-PW implies a P2MP underlying tunnel(s). Figure 2
extracted from [P2MP PW REQ] 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 tunnel MAY be signaled with P2MP RSVP-TE [RFC4875] or
MLDP [MLDP].
Jounay et al. Expires September 9, 2009 [Page 12]
Internet Draft Source-initiated P2MP PW Setup March 2009
i1
/
/ \
/ \
/ \
/\ \
/ \ \
/ \ \
/ \ / \
e1 e2 e3 e4
Figure 2 Example of P2MP Underlying Layer for P2MP SS-PW
When the Egress PE updates its PW-to-label bindings table, it MUST
verify that an underlying layer (P2MP PSN tunnel) is setup to receive
traffic coming from the Ingress PE.
For that purpose the LDP Label mapping initiated by the Ingress PE
MUST provide the Interface ID TLV as defined in [LDP UPSTREAM].
The Interface ID TLV is used by the egress PE(s) to determine which
PSN Tunnel (MLDP or RSVP-TE P2MP LSP) the P2MP PW is associated to.
If the Interface ID is not indicated in the LDP Label Mapping, the
P2MP PW can not be setup.
The Interface ID TLV for RSVP-TE P2MP LSP is defined in [LDP
UPSTREAM].
1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE
P2MP Session Object and the P2MP Sender Template Object
[RFC4875]. Both objects are required at the Egress PE to identify
the RSVP-TE P2MP LSP.
Note that PHP must be disabled on the underlying P2MP PSN tunnel so
as to allow an Egress PE to know on which PSN tunnel a packet is
received.
The P2MP PSN tunnel associated to the P2MP PW can be selected either
by user configuration or by dynamically using the
multiplexing/demultiplexing mechanism described below.
The P2MP PW multiplexing will be based on the overlap rate between
P2MP LSP and P2MP PW. The users should determine whether the P2MP PW
can accept partially multiplexing with P2MP LSP, and a minimum
congruency rate may be defined. The congruency rate reflects the
amount of overlap in the Egress PE of P2MP PW that is multiplexed to
a P2MP LSP. If there is a complete overlap, the congruency is perfect
and the rate is 100%. The Ingress PE can determine whether P2MP PW
can multiplex to a P2MP LSP according to the congruency rate. It is
also possible to extend P2MP LSP to do P2MP PW multiplexing, but this
will reduce the current congruency rate that the P2MP PW is currently
taken. The multiplexing should ensure that the P2MP PW congruency
that is currently taken under P2MP LSP should be larger than minimum
congruency that is configured.
Jounay et al. Expires September 9, 2009 [Page 13]
Internet Draft Source-initiated P2MP PW Setup March 2009
This is a trade-off we have already expressed in the P2MP bypass
draft.
With this procedure a P2MP PW is nested within a P2MP PSN tunnel.
This allows multiplexing several PWs over a common P2MP PSN tunnel.
Prior to the P2MP PW signaling phase, the Ingress PE MUST determine
which PSN tunnel will be used for this P2MP PW. The PSN Tunnel can be
an existing PSN tunnel or the Ingress PE can create an new P2MP PSN
tunnel.
. If the P2MP LSP is based on RSVP-TE, since the Ingress PE knows
the Egress PEs, if the P2MP LSP is not yet setup, it MAY setup
the P2MP LSP at the same time as the PW tree setup, or after
receiving the PW status TLVs from the Egress PEs which informs
the Ingress PE of their attachment to the tree.
Note that in the latter case the LDP Label Mapping MUST convey the
Interface ID even though the P2MP LSP has not been yet
established.
. If the P2MP LSP is based on [MLDP], the P2MP LSP may be setup
once the Egress PE retrieves the P2MP LDP FEC from the Interface
ID TLV. It may also be setup before. This P2MP FEC is used by
the Egress PE to associate the corresponding P2MP LSP with P2MP
PW.
How to do P2MP PW multiplexing over mLDP based P2MP PSN tunnel is
still under study.
4.5.8. Leaf Grafting/Pruning
Since the grafting/pruning is source-initiated, the Ingress PE MUST
send a Label Mapping message to the Egress PE for grafting the new
leaf to the PW tree, or a Label Withdraw message for pruning the
existing leaf from the PW tree.
Note that with P2MP GID FEC element, the Label Release is sent only
if the Leaf is the only leaf belonging to the PW tree remaining on
the Egress PE. If some TAII are still part from the PW tree on that
Egress PE, a LDP Notification with a Success Status code message
should be sent to the Ingress PE with an the TAII sub-TLV updated
accordingly.
4.6. Failure Reporting (to be completed)
If a PW tree endpoint configured on an Egress PE or the corresponding
AC fails, the Egress PE MUST report by means of PW status TLV
transported in a LDP Notification message to the Ingress PE (as
defined in [RFC4447]) that the associated leaf is no more reachable .
The TAII Leaf sub-TLV is used to identify the leaf.
If the Egress PE itself fails, specific OAM features MUST be used
(TBD: LDP status or extended VCCV BFD).
Jounay et al. Expires September 9, 2009 [Page 14]
Internet Draft Source-initiated P2MP PW Setup March 2009
4.7. Protection and Restoration
The P2MP SS-PW is supported over a P2MP PSN LSP. If required a first
level of protection/restoration MUST be implemented at the LSP layer
with classic recovery techniques.
|(SAII)
PE1
/ \
/ \
P2 P3
/ \ / \
//--\--/ \
// \-----\\
PE4 PE5
|(TAII) |(TAII)
An alternative protection scheme may rely on the PW layer. Egress PEs
may be protected via a P2MP PW redundancy mechanism.
In that case a backup P2MP PW over P2MP LSP1 will be used to protect
the primary P2MP PW over P2MP LSP2.
In the example depicted below, a backup P2MP PW (AGI1, SAII, P2MP2)
is used to protect the primary P2MP (AGI1, SAII, P2MP1).
|(SAII)
P2MP PW1 PE P2MP PW2
(SAII, P2MP1).../ \...._(SAII, P2MP2)
/ \
P2 P3
/ \ / \
/ \ / \
/ \ / \
PE4 PE5 PE6 PE7
|(TAII)| |(TAII)|
A mechanism should be implemented to avoid race conditions between
recovery at the PSN level and recovery at the PW level.
5. Security Considerations
This section will be added in a future version.
6. IANA Considerations
Jounay et al. Expires September 9, 2009 [Page 15]
Internet Draft Source-initiated P2MP PW Setup March 2009
6.1. LDP FEC Type
This document uses a new FEC element type, FEC P2MP GID, from the
'FEC Type Name Space' for the label Distribution Protocol (LDP RFC
5036).
The following values are suggested for assignment:
FEC P2MP GID : 0x82
6.2. LDP Status Codes
This document uses several new LDP status codes; IANA already
maintains a registry of name 'STATUS CODE NAME SPACE' defined by
RFC5036. The following values are suggested for assignment:
Range/Value E Description Reference
------------- ----- ---------------------- ---------
LDP Capabilities
7. Acknowledgments
Many thanks to JL Le Roux for the discussions, comments and support.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, March 1997.
[RFC4447] El-Aawar, N., Heron, G., Martini, L., Smith, T., Rosen,
E., "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", April 2006
[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
Thomas, B., "LDP Specification", October 2008.
[RFC3985] Bryant, S., Pate, P. "PWE3 Architecture", March 2005
[RFC5254] Bitar, N., Bocci, M., and Martini, L., "Requirements for
inter domain Pseudo-Wires", October 2008
[RFC4875] Aggarwal, R., Papadimitriou, D., Yasukawa, S.,
"Extensions to RSVP-TE for Point-to-Multipoint TE
LSPs", May 2007
[RFC5003] Metz, C. and all, "Attachment Individual Identifier
(AII) Types for Aggregation", September 2007
Jounay et al. Expires September 9, 2009 [Page 16]
Internet Draft Source-initiated P2MP PW Setup March 2009
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", April 2006
8.2. Informative References
[P2MP PW REQ] Jounay, F., Niger, P, Kamite, Y., Martini L.,
Delord, S. Heron, G., "Use Cases and signaling
requirements for Point-to-Multipoint PW",
Internet Draft, draft-ietf-pwe3-p2mp-pw-
requirements-00.txt, September 2008
[DYN MS-PW] Balus, F., Bocci, M., Martini. L, " Dynamic
Placement of Multi Segment Pseudo Wires",
Internet Draft, draft-ietf-pwe3-dynamic-ms-pw-
08.txt, July 2008
[LDP UPSTREAM] Aggarwal, R., Le Roux, JL., "MPLS Upstream Label
Assignment for LDP", Internet Draft, draft-ietf-
mpls-ldp-upstream-03.txt, July 2008
[MLDP] Minei, I., Kompella, K., Thomas, B., Wijnands,
I. "Label Distribution Protocol Extensions for
Point-to-Multipoint and Multipoint-to-
Multipoint Label Switched Paths", Internet
Draft, draft-ietf-mpls-ldp-p2mp-05, May 2008
[LDP CAPA] Aggarwal, R., Le Roux, JL., Thomas, B., "LDP
Capabilities" draft-thomas-mpls-ldp-
capabilities-02.txt, April 2008
[LEAF INIT P2MP PW] Jounay, F., Kamite, Y., Le Roux, JL., Niger, P.,
"LDP Extensions for Leaf-initiated Point-to-
Multipoint Pseudowire" draft-jounay-pwe3-leaf-
initiated-p2mp-pw-01.txt, November 2008
[VPMS REQ] Kamite, Y., Jounay, F., Niven-Jenkins, B.,
Brungard, D., Jin. L, "Framework and
Requirements for Virtual Private Multicast
Service (VPMS)" draft-kamite-l2vpn-vpms-frmwk-
requirements-02.txt, December 2008
Author's Addresses
Frederic Jounay
France Telecom
2, avenue Pierre-Marzin
Jounay et al. Expires September 9, 2009 [Page 17]
Internet Draft Source-initiated P2MP PW Setup March 2009
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
Lizhong Jin
Nokia Siemens Networks
Building 89, 1122 North QinZhou Road,
Shanghai, 200233
P.R.China
Email: lizhong.jin@nsn.com
Martin Vigoureux
Alcatel-Lucent
Email: martin.vigoureux@alcatel-lucent.com
Laurent Ciavaglia
Alcatel-Lucent
Email: Laurent.Ciavaglia@alcatel-lucent.com
Derivative Works and Publication Limitations
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.
Copyright and License Notice
Jounay et al. Expires September 9, 2009 [Page 18]
Internet Draft Source-initiated P2MP PW Setup March 2009
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.
Jounay et al. Expires September 9, 2009 [Page 19]