Network Working Group F. Jounay
Internet Draft P. Niger
Category: Standards Track France Telecom
Expires: April 2009
Y. Kamite
NTT Communications
November 3, 2008
LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire
draft-jounay-niger-pwe3-source-initiated-p2mp-pw-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-Daft will expire on April 3, 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
applications. The document deals with the source-initiated P2MP PW
setup and maintenance.
Jounay et al. Expires April 3, 2009 [Page 1]
Internet Draft Source-initiated P2MP PW Setup November 2008
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......................................4
4.1. P2MP SS-PW Reference Model....................................4
4.2. Overview of the P2MP SS-PW Setup..............................5
4.3. P2MP PWid FEC Element.........................................5
4.4. P2MP Generalized ID FEC Element...............................6
4.4.1. P2MP GID FEC TLV............................................6
4.4.2. TAII Leaf Sub-TLV...........................................7
4.5. Signaling for P2MP SS-PW......................................8
4.5.1. Configuration/Provisioning..................................8
4.5.2. Capability Negotiation Procedure............................9
4.5.3. Signaling Process...........................................9
4.5.4. Underlying LSP Setup.......................................10
4.5.5. Leaf Grafting/Pruning......................................12
4.6. Failure Reporting (to be completed)..........................12
4.7. Protection and Restoration...................................12
5. P2MP MS-PW Setup Mechanism with P2MP PSN tunnel................12
5.1. P2MP MS-PW Reference Model...................................12
5.2. Overview of the P2MP MS-PW Setup.............................14
5.3. Signaling for P2MP MS-PW.....................................14
5.3.1. Configuration/Provisioning.................................14
5.3.2. Capability Negotiation Procedure...........................15
5.3.3. Signaling Process..........................................15
5.3.4. Explicit Routing...........................................17
5.3.5. Underlying LSP Setup.......................................17
5.3.6. Leaf Grafting/Pruning......................................18
5.4. Failure Reporting............................................19
5.5. Protection and Restoration...................................19
6. Security Considerations........................................19
7. IANA Considerations............................................19
7.1. LDP FEC Type.................................................19
7.2. LDP Status Codes.............................................20
8. Acknowledgments................................................20
9. References.....................................................20
9.1. Normative References.........................................20
9.2. Informative References.......................................20
Authors' Addresses................................................21
Intellectual Property and Copyright Statements....................22
Jounay et al. Expires April 3, 2009 [Page 2]
Internet Draft Source-initiated P2MP PW Setup November 2008
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 two new P2MP FEC
elements derived from the FEC128 and the FEC129 used respectively for
the double-side provisioning and the single-side provisioning of a
P2P PW setup
The document also presents a solution to setup a P2MP MS-PW. Due to
the End-to-End dynamic setup requirement for P2MP MS-PW, the proposed
solution relies on the same FEC129-derived P2MP FEC element
previously defined for the P2MP SS-PW setup.
Jounay et al. Expires April 3, 2009 [Page 3]
Internet Draft Source-initiated P2MP PW Setup November 2008
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 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 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 | | +----+
| | | | ......PW1........|-----------|CE2 |
| | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+ |
+----+ | | | | . |=========|PE3 | | +----+
|CE1 |---------|........PW1.........|...PW1........|-----------|CE3 |
+----+ | | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+ |
| | | | . |=========|PE4 | | +----+
| | | | ......PW1........|-----------|CE4 |
| | | | |=========| | | +----+
| +----+ +-----+ +----+ |
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.
Jounay et al. Expires April 3, 2009 [Page 4]
Internet Draft Source-initiated P2MP PW Setup November 2008
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
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 proposes two P2MP PW FEC elements to setup a P2MP SS-
PW, one derived from the FEC128 and the other one from the FEC129.
As represented in Figure 1 the unidirectional P2MP SS-PW relies on
the use of P2MP LSP as PSN tunnel underlying layer, setup between the
Ingress PE and all Egress PEs.
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.
Note : Whatever the signaling initialization is (leaf or source-
initiated), the use of the P2MP PWiD FEC to setup the P2MP SS-PW has
no particular effect on the required provisioning procedure, since
both sides (source and leaves) MUST be configured with the P2MP PWid
and the IP address of the remote PE. However when the P2MP GID FEC is
used for the PW tree setup, the document describes below a preferred
solution based on a source-initiated process, since the single sided
configuration alleviates considerably the required provisioning
procedure.
4.3. P2MP PWid FEC Element
A new FEC element is defined and is derived from the PWid FEC element
defined in [RFC4447]. The P2MP PWid FEC is defined as follows:
Jounay et al. Expires April 3, 2009 [Page 5]
Internet Draft Source-initiated P2MP PW Setup November 2008
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 PWid (TBD)|C| P2MP PW type |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Parameter Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The P2MP PWid defines the new FEC Element. All remaining fields are
unchanged compared to their definition in [RFC4447].
4.4. P2MP Generalized ID FEC Element
Based on the benefit provided by the PW AII addresses, the FEC129
used for P2P PW setup is extended to propose:
- a new P2MP GID FEC element containing a P2MP identifier and a PW
source address (SAII)
- a new TAII Leaf sub-TLV containing the list of leaves (identified
by AIIs) to be attached to the PW tree.
4.4.1. P2MP GID FEC TLV
The P2MP GID FEC is derived from the format of the GID FEC (FEC129)
defined in [RFC4447].
The AGI 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).
The SAII (Source Attachment Individual Identifier) is attached to the
Ingress PE and identifies the PW tree source.
The AGI and the SAII have the same structure than for the FEC 129.
The TAII is replaced by a P2MP Identifier (P2MP Id). The PW tree is
identified by means of the pair [SAI, P2MP Identifier].
Jounay et al. Expires April 3, 2009 [Page 6]
Internet Draft Source-initiated P2MP PW Setup November 2008
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 | 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 description of procedures), the P2MP GID FEC MUST
be included in the message to identify the PW tree to which it
applies.
4.4.2. TAII Leaf Sub-TLV
In order to carry the information regarding the leaves to be
connected to the tree, a new TAII Leaf sub-TLV is defined.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| TAII Leaf Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ ------------------- ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | TAII Value |
Jounay et al. Expires April 3, 2009 [Page 7]
Internet Draft Source-initiated P2MP PW Setup November 2008
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TAII have the same structure than for the FEC 129. The TAII Leaf
sub-TLV comprises a list of one or more TAII Leaves.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW Status (0x096A) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| TAII Leaf Type | 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.
4.5. Signaling for P2MP SS-PW
4.5.1. Configuration/Provisioning
Referring to Figure 1, if the P2MP PWid FEC is used, the Ingress PE
(PE1) and the Egress PEs (PE2, PE3 and PE4) MUST be configured with
the same P2MP PWid.
Jounay et al. Expires April 3, 2009 [Page 8]
Internet Draft Source-initiated P2MP PW Setup November 2008
Referring to Figure 1, if the P2MP GID FEC is used the Ingress PE
(PE1) MUST be configured with the AGI and SAII. SAI is considered as
the Source Attachment Identifier of the PW tree. Each Egress PE MUST
be configured with one or more TAII corresponding to one or more
leaves of the PW tree. The AGI MUST be the same for all endpoints of
the PW tree. Once the AIs are configured at all endpoints, the
provisioning next step for the PW tree establishment consists in
specifying at the Ingress PE all the TAIIs identifying the leaves of
the PW tree.
Regardless of the FEC element used, the IP address of the Egress PEs
where the TAII are attached can be configured manually or learnt
dynamically by means of auto discovery protocol at Ingress PE.
4.5.2. Capability Negotiation Procedure
To achieve the capability negotiation the solution MUST follow the
LDP capability advertisement mechanism described in [LDP CAPA]. New
code points if required SHOULD be defined.
The PEs belonging to the PW tree MUST support the same P2MP PW FEC
element.
The unidirectional P2MP SS-PW is supported over a P2MP LSP, so
Upstream Label Assignment as defined in [LDP UPSTREAM] MUST be used
to prevent replication at the PW level. So that guarantees not to
waste the network bandwidth. An Upstream Label Assignment Capability
sub-TLV is introduced to signal a PE's support of upstream label
assignment, to its LDP peers. This sub-TLV is carried in the LDP
Capability TLV.
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 session with every Egress PE.
If the P2MP PWid FEC is used, the same Label Mapping message is sent
to every Egress PE containing the same P2MP PWid.
If the P2MP GID FEC is used, a Label Mapping message is sent to every
Egress PE containing the SAII configured as the source at the Ingress
PE. The TAII Leaf sub-TLV includes one or more AII associated to the
Egress PE defined as leaves of the tree.
Jounay et al. Expires April 3, 2009 [Page 9]
Internet Draft Source-initiated P2MP PW Setup November 2008
The Label Mapping message MUST include an upstream assigned PW label
carried within the Upstream Assigned Label TLV. The Ingress PE MUST
NOT distribute the Upstream Assigned Label TLV to the Egress PE if
the Egress PE had not previously advertised the Upstream Label
Assignment Capability in its LDP Initialization messages.
Note that the Ingress PE does not need to receive a Label Request
from the Egress PE to send the Label Mapping message.
When the Egress PE receives and processes the Label Mapping message,
it verifies the PWid or the TAII(s) and checks if it matches to one
of its configured Forwarders.
If a matching is found for the PWid, the Egress PE carries on the
process by responding with a PW status TLV to the Ingress PE. The PW
status TLV informs the Ingress PE that the Egress PE and associated
leaf(ves) is from now part of the PW tree. For this purpose a Success
Status Code is used. Therefore the Ingress and the Egress PEs update
their PW-to-label bindings. If no matching is found the Egress PE
sends a Label Release message. The FEC TLV sent in a Label Release is
the same FEC TLV received in the Label Mapping message initiated by
the Ingress PE.
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 part of the PW tree.
Therefore the Ingress and the Egress PEs update their PW-to-label
bindings. When some TAII leaves do not match with ones configured at
the Egress PE, an error procedure must be applied as defined in [SEG
PW]. If no matching is found among the TAII leaves, the Egress PE
sends a Label Release message. The FEC TLV sent in a Label Release is
the same FEC TLV received in the Label Mapping message initiated by
the Ingress PE.
Note that a matching addresses the PWid or the TAII-sub TLV for the
GID but other parameters are also checked as described in [RFC4447]
(Type, possible interface parameters).
4.5.4. Underlying LSP Setup
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. If it is not the case the Egress
PE MUST join the P2MP PSN tunnel. Two possible options are described
hereafter.
The P2MP SS-PW implies a P2MP underlying tunnel. Figure 2 extracted
from [P2MP PW REQ] gives an example of P2MP SS-PW topology relying on
Jounay et al. Expires April 3, 2009 [Page 10]
Internet Draft Source-initiated P2MP PW Setup November 2008
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 LSP set
up will be based on [RFC4875] or [MLDP] signaling.
i1
/
/ \
/ \
/ \
/\ \
/ \ \
/ \ \
/ \ / \
e1 e2 e3 e4
Figure 2 Example of P2MP Underlying Layer for P2MP SS-PW
As defined in [LDP UPSTREAM], the Interface ID TLV is used for
signaling the underlying Tunnel Identifier. The Ingress PE MUST
include the identifier of the underlying P2MP LDP or RSVP-TE LSP in
Interface ID TLV in the Label Mapping messages along with the
Upstream Assigned Label TLV.
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.
With this procedure a P2MP PW is nested within a P2MP PSN tunnel.
This allows aggregating several PW LSPs over a common P2MP PSN
tunnel. P2MP PW should be multiplexed and demultiplexed over P2MP PSN
tunnel. Before P2MP PW singaling, ingress PE should determine which
PSN tunnel will be used for this P2MP PW. This PSN Tunnel can be a
new one, or an existing PSN tunnel that can be multiplexed.
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.
If the P2MP LSP is based on [MLDP], the P2MP LSP is 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
join the P2MP LSP by initiating a LDP Label Mapping messages.
Remark: need to check if upstream label assignment procedure works
when the underlying interface is not established in advance.
Jounay et al. Expires April 3, 2009 [Page 11]
Internet Draft Source-initiated P2MP PW Setup November 2008
4.5.5. 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 tree, or a Label Withdraw message for pruning the
existing leaf from the tree. The Egress PE MUST confirms the pruning
by sending a Label Release message.
If the egress PE leave the P2MP PW by some administrative measure,
the egress PE should send a Lable Release message to the ingress PE.
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 AII is used to identify the leaf.
An alternative solution based on in-band OAM could also be used (e.g.
based on BFD/VCCV).
If the Egress PE itself fails, specific OAM features MUST be used
(TBD: LDP status or extended VCCV BFD).
4.7. Protection and Restoration
The P2MP SS-PW is supported over a P2MP LSP. If required a first
level of protection/restoration MUST be implemented at the LSP layer
with classic recovery techniques.
At the PW layer the only equipments to protect are the Ingress PE and
the Egress PEs.
A mechanism should be implemented to avoid race conditions between
recovery at the PSN level and recovery at the PW level.
5. P2MP MS-PW Setup Mechanism with P2MP PSN tunnel
5.1. P2MP MS-PW Reference Model
Figure 3 describes the P2MP MS-PW reference model which is derived
from [P2MP PW REQ] to support P2MP emulated services.
Jounay et al. Expires April 3, 2009 [Page 12]
Internet Draft Source-initiated P2MP PW Setup November 2008
|<-----------P2MP MS-PW------------>|
Native | P2MP P2MP | Native
Service | |<-PSN1-->| |<-PSN2-->| | Service
(AC) V V tunnel V V tunnels V V (AC)
| +----+ +-----+ +----+ |
| |T-PE| |S-PE1|=========|T-PE| | +----+
| | 1 | | ........2.|-----------|CE2 |
| | |=========| | . | | | +----+
| | | ...............PW2 +----+ |
| | | . | | . +----+ |
| | | . | | . |T-PE| | +----+
| | | . | ........3.|-----------|CE3 |
+----+ | | | . | |=========| | | +----+
|CE1 |---------|........PW1 +-----+ +----+ |
+----+ | | | . +-----+ +----+ |
| | | . |S-PE2|=========|T-PE| | +----+
| | | . | | ........4.|-----------|CE4 |
| | | . | | . | | | +----+
| | | . | | . +----+ |
| | | ...............PW3 +----+ |
| | |=========| | . |T-PE| | +----+
| | | | | ........5.|-----------|CE5 |
| | | | |=========| | | +----+
| +----+ +-----+ +----+ |
Figure 3 P2MP MS-PW over P2MP PSN tunnels Reference Model
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 depending
on the underlying layer. In this document the underlying layer is a
P2MP LSP, so the S-PE switches one P2MP input segment to one or
several P2MP output segment.
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. The S-PE1 and S-PE2 play the role
of branch S-PE since they are in charge of switching simultaneously
the input P2MP PW segment PW1 to respectively the output P2MP PW
segments PW2 and PW3 respectively.
Note that a P2MP MS-PW may obviously transit trough 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
Jounay et al. Expires April 3, 2009 [Page 13]
Internet Draft Source-initiated P2MP PW Setup November 2008
does not imply such a requirement since each PW segment can be
supported over a P2P PSN tunnel. The coexistence of both kinds of PSN
tunnel (P2P and P2MP) MUST be considered. The case where the PW
segment composing a MS-PW tree is supported over P2P PSN tunnels will
be described in a future version.
5.2. Overview of the P2MP MS-PW Setup
The P2MP MS-PW setup relies on the use of the P2MP GID FEC Element
defined in 4.4. The solution aims at setting up a unidirectional P2MP
Multi-Segment PW to be capable to extend the P2MP PW to inter-domain.
The principle proposed here relies on a source-initiated P2MP MS-PW
setup. In the proposed approach the source is assumed to know all the
leaves of the PW tree, so the source is able to initiate the
signaling procedure. Another added value of the P2MP MS-PW source
initiated approach is to make possible the implementation of CR
(Constraint-based Routed) MS-PW. In that case an explicit route
defining the PW tree topology is represented as a list of S-PEs that
the P2MP MS-PW must use along the constraint-based route.
The document describes the solution to setup the P2MP MS-PW in the
case the PW segments inside a given PSN are supported over a P2MP PSN
tunnel. Since the P2MP PW segment is unidirectional and to avoid
replication, after a negotiation procedure between Ingress T-PE/S-PE
and S-PE/Egress T-PEs, the Upstream Label Assignment [LDP UPSTREAM]
MUST be used for the PW label assignment.
Note that by definition a P2MP LSP can have a single leaf, so
mechanisms defined in this document apply to P2P PSN Tunnels. But
since the P2P PSN case does not require upstream label assignment
simpler procedures that rely on downstream label assignment will be
defined in a future version.
5.3. Signaling for P2MP MS-PW
5.3.1. Configuration/Provisioning
After configuring on each T-PE of the attached AIIs, it is assumed
that all the PEs (Ingress/Egress T-PEs and all S-PEs) maintain an AII
PW routing table which gives for each AII as entry the "next hop" to
reach that AII. This AII routing table can be filled manually or
updated dynamically by means of some extended routing protocol like
proposed in [DYN MS-PW]. The construction of the table is out of
scope of the present document.
Each PE relies on its AII PW routing table to select the next hop PE
(S-PE or T-PE) to reach a given TAII.
In the source-initiated P2MP MS-PW setup, the provisioning of the PW
tree is only required at the source side, on the Ingress PE instead
Jounay et al. Expires April 3, 2009 [Page 14]
Internet Draft Source-initiated P2MP PW Setup November 2008
of all destination PEs. For the P2MP MS-PW setup the provisioning
task consists in specifying at the Ingress PE all the TAII considered
as the leaves of the tree (information transported in the TAII sub-
TLV for signaling procedure).
5.3.2. Capability Negotiation Procedure
To achieve the capability negotiation the solution MUST follow the
LDP capability advertisement mechanism described in [LDP CAPA]. New
code points are defined in this document (TBC).
The unidirectional P2MP PW segment is supported over a P2MP LSP, so
Upstream Label Assignment as defined in [LDP UPSTREAM] MUST be used
to prevent traffic replication at the PW level. The Upstream Label
Assignment Capability sub-TLV is used to signal a PE's support of
upstream label assignment, to its LDP peers. This sub-TLV is carried
in the LDP Capability TLV.
The PEs belonging to a given P2MP MS-PW MUST support the P2MP GID FEC
Element.
The PEs MUST also negotiate with their remote PEs the capability of
supporting the PW status TLV. This negotiation is a key element in
order to allow these PEs to announce some status information later
on.
5.3.3. Signaling Process
Note: in the next release of the document this paragraph will have to
be changed for a more normative formulation (MUST, SHOULD, etc).
It is assumed to use the Upstream Label Assignment for the PW label
Assignment to set up a P2MP MS-PW since in this document the P2MP PW
segment is assumed to be supported over a P2MP PSN tunnel.
Ingress T-PE
To set up the P2MP MS-PW, the Ingress T-PE initiates a signaling
session with the S-PEs selected to join the TAIIs. If the Ingress T-
PE is attached to several S-PEs, and according to the TAII Leaf sub-
TLV, and the AII routing table, the Ingress T-PE can select a unique
S-PE or several S-PEs. In the last case, several signaling sessions
have to be set up, one with each selected S-PE. Otherwise only one
signalling session is established between the Ingress T-PE and the
next hop S-PE.
The Ingress T-PE sends a Label Mapping message to the S-PE which
contains the P2MP GID TLV and the TAII Leaf sub-TLV which identify
the subset of MS-PW leaves of the multicast tree that are reachable
via the S-PE. A given TAII does not appear in more than once
signaling messages in order to avoid building several branches to the
same leaf via different paths.
Jounay et al. Expires April 3, 2009 [Page 15]
Internet Draft Source-initiated P2MP PW Setup November 2008
Branch S-PE
When a branch S-PE receives a Label Mapping message, it checks if one
or several TAIIs belonging to the TAII Leaf sub-TLV matches to its
AII PW routing table. If at least one matching is found the S-PE
sends a PW Status Notification message to the upstream PE (Ingress T-
PE or S-PE) in order to inform it about its tree attachment. Using
such information the T-PE is able to validate its forwarding plane by
acknowledging its PW-to-Label bindings. If no matching is found or if
some TAIIs are not reachable from the S-PE, an error procedure must
be applied as defined in [SEG PW] and reminded in 5.4.Based on the
result of the matching the S-PE validates as well its PW-to-label
bindings for upstream allocated labels. This ends PW set up between
the S-PE and the upstream node (T-PE or S-PE). Here we assume that
even though all the TAII from the TAI Leaf sub-TLV are not reachable
(which leads to an error message), the PW tree continues to be setup
for those reachable.
In turn the S-PE selects the "next hops" to reach the TAIIs. One or
more next hop PEs can be identified. A next hop can be another S-PE
or directly an Egress T-PE. The S-PE sends one Label Mapping message
to each selected next hop with the same FEC containing the source AII
and the P2MP MS-PW identifier. For each next hop the Label Mapping
message issued by the S-PE carries in TAII Leaf sub-TLV the leaves
that can be reached using the selected next hop. To avoid
inconsistency the sub-TLV includes only the TAIIs which are reachable
using the selected next hop (other TAIIs are pruned from the received
TAII Leaf sub-TLV). The branch S-PE validates its forwarding plane by
specifying that the PW-to-label bindings for this segment is active
only if it receives a successful PW Status Notification message from
its downstream PE (S-PE or Egress T-PE).
This process is repeated hop by hop until the P2MP MS-PW is
completely built, when all reachable leaves are connected to the
source. That means that the last PW segment connecting an Egress T-PE
is set up based on a TAII Leaf TLV containing only the TAIIs that are
attached to this Egress T-PE (only one TAII if there is only one leaf
attached to the Egress T-PE).
Egress PE
When receiving a Label Mapping message an Egress PE checks that the
TAIIs included in the TAII Leaf sub-TLV are configured and could be
associated to a forwarder. If it is the case (at least for one TAII)
the Egress T-PE sends a PW Status Notification message to the
upstream PE (Ingress T-PE or S-PE) in order to inform it about its
tree attachment. The Egress T-PE validates its forwarding plane by
acknowledging the PW-to-label binding for this last segment.
The P2MP MS-PW is then built and the corresponding leaves (TAIIs) are
connected to the source (SAII).
Jounay et al. Expires April 3, 2009 [Page 16]
Internet Draft Source-initiated P2MP PW Setup November 2008
If no AII belonging to the TAII Leaf sub-TLV are configured at the
Egress T-PE, the Egress T-PE generates an error message (Label
Release message) to the upstream S-PE to tear down the PW segment and
prune it from the tree. At turn if this PW segment is the only output
PW segment of the P2MP MS-PW for this S-PE, it generates a Label
Release message to the upstream S-PE (or Ingress T-PE). Since the PW
segment is assumed here P2MP, the S-PE MUST make sure before sending
the Label Release to the upstream PE that no leaf is still attached.
5.3.4. Explicit Routing
The P2MP MS-PW source-initiated approach allows the implementation of
CR (Constraint-based Routed) P2MP MS-PW. In that case an explicit
route determining the P2MP tree topology must be defined. This
explicit route could be represented as the list of S-PEs that the
P2MP MS-PW must use along the constraint-based route.
The implementation of such CR P2MP MS-PW requires an extension of
existing signaling mechanism in order to allow the signaling message
to transport the explicit route used to set up the multicast tree.
This point requires further studies.
5.3.5. Underlying LSP Setup
Figure 4 describes an example of P2MP MS-PW topology relying on P2MP
LSPs as PSN tunnels. The PW tree is composed of one Ingress PE (i1)
and several Egress PEs (e1, e2, e3, e4, e5, e6). The branch S-PEs are
represented as b1,b2. In that case the traffic replication along the
path of the PW tree is performed at the PW level and at the
underlying LSP level. For instance the branch S-PE b2 MUST replicate
incoming packets or data received from i1 and send them to Egress T-
PEs, e3, and e4 via a P2MP PW segment supported over a P2MP PSN
tunnel and to e5 and e6 via another P2MP PSN tunnel.
Figure 4 describes the case where each P2MP PW segment is supported
over a P2MP LSP.
i1
/
/\
/ \
b1 \
/ \
/\ \
/ \ b2
e1 e2 / \
/\ /\
e3e4e5e6
Jounay et al. Expires April 3, 2009 [Page 17]
Internet Draft Source-initiated P2MP PW Setup November 2008
Figure 4 Example of P2MP underlying Layer for P2MP MS-PW
When a PW segment is supported over a P2MP LSP, the way to proceed to
setup the underlying layer is the same as described for SS-PW 4.5.4
except that the procedure applies to a P2MP PW segment and not to a
P2MP End-to-End PW.
P2P PSN is supported by methods defined in this draft but simpler
method specific to P2P PSN will be described in a future version.
5.3.6. Leaf Grafting/Pruning
After a P2MP MS-PW has been established, it MUST be possible to
add/remove one or more individual leaves. It is required to be able
to achieve this addition without damaging the current tree.
Leaf Grafting
In that case the procedure is the same as for the P2MP MS-PW
construction, except that the procedure is applied with only one TAII
identifying the new leaf in the TAII Leaf sub-TLV.
The Ingress T-PE initiates a Label Mapping message with the P2MP GID
FEC [SAI, P2MP Id] of the tree to which the leaf must be added and
the TAII Leaf sub-TLV identifying the leaf. The signaling message is
processed as described above by PEs (T-PEs and S-PEs). The upstream
PE reuses the same upstream label previously assigned for the
existing segments of the P2MP tree identified with the P2MP GID FEC
[SAI, P2MP Id].
Each S-PE checks if an extension of the existing PW tree is required
to reach the TAII. If a PW segment already exists to the next hop the
signaling message is simply propagated to the next hop. A new PW
segment is set up to a next hop only if the next hop was not still
used so far for existing leaves of the PW tree. The extension of the
PW tree is built hop by hop up to the Egress T-PE where the new leaf
is added to the tree. The TAII MUST be configured on the Egress T-PE.
Otherwise an error message is issued by the Egress T-PE in the
reverse direction (as described above). The error message triggers as
well a Label Release message from the Egress T-PE if the given TAII
is the only leaf configured at the Egress T-PE.
Leaf Pruning
The Ingress T-PE initiates a Label Withdraw message with the P2MP GID
FEC [SAI, P2MP Id] of the tree to which the leaf must be removed and
the TAII Leaf sub-TLV identifying the leaf. The Label Withdraw
message must be processed by the receiving T-PE. The S-PE processes
this message only to propagate the message up to the Egress T-PE. It
is proposed that the Label Withdraw is propagated up to the
corresponding Egress T-PE.
Jounay et al. Expires April 3, 2009 [Page 18]
Internet Draft Source-initiated P2MP PW Setup November 2008
The Egress T-PE verifies that the TAII matches with one of its
configured local AII. If it is the case the Egress T-PE removes the
leaf corresponding to the AII from the PW tree. Then the T-PE checks
if the TAII is its only AII attached to the PW tree identified by the
P2MP GID FEC. If it is the case the T-PE sends a Label Release
message to its upstream PE to tear down the PW segment and prune it
from the PW tree. At turn if this PW segment is the only output PW
segment of the P2MP MS-PW for this S-PE, it generates a Label Release
message to the upstream S-PE (or Ingress T-PE).
Note: A Label Withdraw message initiated from the Ingress T-PE which
does not include a TAII Leaf sub-TLV aims at pruning all the PW tree.
The message is processed by all the PEs and propagated up to the
Egress T-PEs.
5.4. Failure Reporting
When a notification message must be sent in the backward direction,
the P2MP GID FEC is added to the message to identify the P2MP tree
concerned. It could be used to announce to the source that a given
leaf is not reachable or is no longer reachable (e.g. the
corresponding TAII does not exist on the Egress T-PE). It could also
be used to send to the source other kinds of information like leaf
status reporting, OAM defect indication, etc.
Solutions on specific OAM features to detect and announce a node or a
segment failure are left for future study.
5.5. Protection and Restoration
This section will be added in a future version.
6. Security Considerations
This section will be added in a future version.
7. IANA Considerations
7.1. LDP FEC Type
This document uses two new FEC element types, FEC P2MP PWid, FEC P2MP
GID , from the "FEC Type Name Space" for the label Distribution
Protocol (LDP RFC 3036).
The following values are suggested for assignment:
FEC P2MP PWid : 0x82
FEC P2MP GID : 0x83
Jounay et al. Expires April 3, 2009 [Page 19]
Internet Draft Source-initiated P2MP PW Setup November 2008
7.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
8. Acknowledgments
Many thanks to JL Le Roux, Jin Lizhong for the discussions, comments
and support.
9. References
9.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
9.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
Jounay et al. Expires April 3, 2009 [Page 20]
Internet Draft Source-initiated P2MP PW Setup November 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
[SEG PW] Martini et al, "Segmented Pseudo Wire", Internet
Draft, draft-ietf-pwe3-segmented-pw-09.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
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 April 3, 2009 [Page 21]
Internet Draft Source-initiated P2MP PW Setup November 2008
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
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 (2008).
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.
Jounay et al. Expires April 3, 2009 [Page 22]