One document matched: draft-jounay-niger-pwe3-source-initiated-p2mp-pw-03.txt
Differences from draft-jounay-niger-pwe3-source-initiated-p2mp-pw-02.txt
Network Working Group F. Jounay (Editor)
Internet Draft P. Niger
Category: Standards Track France Telecom
Expires: January 2010
Y. Kamite
L. Jin NTT Communications
Nokia Siemens
S. Delord
L. Ciavaglia Telstra
M. Vigoureux
Alcatel-Lucent July 13, 2009
LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire
draft-jounay-niger-pwe3-source-initiated-p2mp-pw-03.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2010.
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 January, 2010 [Page 1]
Internet Draft Source-initiated P2MP PW Setup July 2009
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. Introduction....................................................3
3. P2MP SS-PW Setup Mechanism......................................3
3.1. P2MP SS-PW Reference Model....................................3
3.2. Overview of the P2MP SS-PW Setup..............................4
3.3. LDP...........................................................5
3.4. P2MP Generalized ID FEC Element...............................5
3.4.1. P2MP GID FEC Element........................................5
3.4.2. TAII Leaf TLV...............................................8
3.5. Signaling for P2MP SS-PW.....................................10
3.5.1. Configuration/Provisioning.................................10
3.5.2. Capability Negotiation Procedure...........................10
3.5.3. Signaling Process..........................................11
3.5.4. Leaf Attachment Notification Message.......................11
3.5.5. PW Type Mismatch...........................................12
3.5.6. Interface Parameters.......................................13
3.5.7. Interface ID (Underlying P2MP PSN tunnel)..................13
3.5.8. Leaf Grafting/Pruning......................................15
4. Security Considerations........................................15
5. IANA Considerations............................................15
5.1. LDP FEC Type.................................................15
5.2. LDP TLV Type.................................................15
5.3. LDP Status Codes.............................................16
6. Acknowledgments................................................16
7. References.....................................................16
7.1. Normative References.........................................16
7.2. Informative References.......................................17
Authors' Addresses................................................ 18
Copyright and Licence Notice...................................... 19
Jounay et al. Expires January 13, 2010 [Page 2]
Internet Draft Source-initiated P2MP PW Setup July 2009
1. Terminology
This document uses acronyms and terminologies defined in [RFC5036],
[RFC3985], [P2MP PW REQ] and [RFC5254].
2. Introduction
[RFC4447] describes a mechanism for establishing Point-to-Point
Single-Segment Pseudowire (P2P SS-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 a solution to setup a P2MP SS-PW. The solution
relies on the definition of a P2MP GID FEC element derived from the
FEC129 used for the single-side provisioning of a P2P PW setup
[RFC4447]. The P2MP MS-PW is outside the scope of this document.
3. P2MP SS-PW Setup Mechanism
3.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
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 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.
Jounay et al. Expires January 13, 2010 [Page 3]
Internet Draft Source-initiated P2MP PW Setup July 2009
|<-----------P2MP SS-PW------------>|
Native | | Native
Service | |<----P2MP PSN tunnel --->| | Service
(AC) V V V V (AC)
| +----+ +-----+ +----+ |
| |PE1 | | P |=========|PE2 |AC3 | +----+
| | | | ......PW1.......>|---------->|CE3 |
| | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+ |
+----+ | AC1 | | | . |=========|PE3 |AC4 | +----+
|CE1 |-------->|........PW1.............PW1.......>|---------->|CE4 |
+----+ | | | | . |=========| | | +----+
| | | | . | +----+ |
+----+ |AC2 | |=========| . | |
| CE2|<--------| | | . | +----+AC5 | +----+
+----+ | | | | . |=========|PE4 |---------->|CE5 |
| | | | ......PW1.......>| | +----+
| | | | |=========| |AC6 | +----+
| | | | | | |---------->| CE6|
| +----+ +-----+ +----+ | +----+
Figure 1 P2MP SS-PW Reference Model
This architecture applies to the case where a P2MP PSN tunnel extends
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.
3.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 defines a P2MP GID FEC element derived from the FEC129
to setup a P2MP SS-PW.
Jounay et al. Expires January 13, 2010 [Page 4]
Internet Draft Source-initiated P2MP PW Setup July 2009
The Ingress PE maintains one signaling LDP session with every Egress
PE. Since the P2MP PW is unidirectional and to avoid replication, the
Upstream Label Assignment [LDP UPSTREAM], [RFC5331] MUST be used for
the PW label assignment. 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 traffic
transmission and replication relies on the usage of P2MP LSP (s) as
PSN tunnel(s) underlying layer, established between the Ingress PE
and all Egress PEs.
3.3. LDP
The PW label bindings are distributed using the LDP upstream
unsolicited label distribution, liberal label retention mode
described in [LDP UPSTREAM], [RFC5331] 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, a FEC Element TLVs is defined to be used for
identifying point-to-multipoint pseudowires.
3.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)
- a TAII Leaf TLV containing the list of the PW addresses (TAII) at
the leaves AIIs to be attached to the PW tree.
3.4.1. P2MP GID FEC Element
The P2MP GID FEC Element format is derived as below.
Jounay et al. Expires January 13, 2010 [Page 5]
Internet Draft Source-initiated P2MP PW Setup July 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP GID(0x82)|C| PW Type |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP Id | Length | P2MP Id Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ P2MP Id Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a Notification message have to be exchanged between peer PEs
(see below for a detailed 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. 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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jounay et al. Expires January 13, 2010 [Page 6]
Internet Draft Source-initiated P2MP PW Setup July 2009
In P2MP GID FEC element, the TAII field structure that was defined in
Section 5.3.2 of [RFC4447] is replaced with a P2MP Identifier (P2MP
Id). The PW tree is identified by means of the pair (SAI, P2MP
Identifier). The P2MP Id is a four-octet number.
The P2MP identifier is required in particular for some P2MP make-
before-break function.
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).
CE1
|(SAII)
P2MP PW1 PE P2MP PW2
(SAII, P2MP1).../ \...._(SAII, P2MP2)
/ \
P2 P3
/ \ / \
/ \ / \
/ \ / \
PE4 PE5 PE6 PE7
AII1 AII2 AII3 AII4
| \ / |
\ CE2 /
\ /
-------CE3------
A mechanism should be implemented to avoid race conditions between
recovery at the PSN level and recovery at the PW level.
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 makes 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.
Jounay et al. Expires January 13, 2010 [Page 7]
Internet Draft Source-initiated P2MP PW Setup July 2009
|(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
All remaining fields are unchanged compared to their definition in
[RFC4447], including the Control Word (C bit).
3.4.2. TAII Leaf TLV
A TAII Leaf TLV is defined in order to carry the information
regarding the P2MP PW 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
3.4.1 is also used as the address type of the TAII Leaf TLV.
The TAII Leaf 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 (IANA) | 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.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jounay et al. Expires January 13, 2010 [Page 8]
Internet Draft Source-initiated P2MP PW Setup July 2009
+ 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;
The TAII has the same structure than in the FEC 129 defined in
[RFC4447]. The TAII Leaf TLV comprises a list of one or more TAII
Leaf identifiers.
The TAII Leaf TLV MUST be included in the Label Mapping message
initiated by the Ingress PE.
The TAII Leaf 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| TAII Leaf Type (IANA) | 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 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 TLV will include only one TAII.
Jounay et al. Expires January 13, 2010 [Page 9]
Internet Draft Source-initiated P2MP PW Setup July 2009
3.5. Signaling for P2MP SS-PW
3.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. SAII is
considered as the Source Attachment Identifier of the PW tree. Each
Egress PE MUST be configured with one or more leaf-TAIIs
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 MUST 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.
3.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 P2MP GID 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], [RFC5331]
MUST be used to prevent replication at the PW level. Upstream-
assigned label bindings MUST NOT be used unless it is known that the
Egress PEs support them. This guarantees not to waste the network
bandwidth. Egress 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 NOT initiate the P2MP PW setup unless it is
known that the Egress PEs support the PW Status TLV [RFC4447].
An Egress PE which supports the PW Status TLV can advertise its
capability by inserting an PW Status Capability sub-TLV in the LDP
Capability TLV. This negotiation is a key element in the procedure
since it can allow the Ingress PE to adjust P2MP PSN tunnel (P2MP TE-
LSP) topology upon receipt of Leaf Attachment Notification at the PW
layer from Egress PEs. The PW status is also required to allow the
Egress/Ingress PEs to announce some status information later on to
the Ingress/Egress PE.
Jounay et al. Expires January 13, 2010 [Page 10]
Internet Draft Source-initiated P2MP PW Setup July 2009
For an Egress PE which does not support the PW Status TLV, some
communication mechanism SHOULD allow the Ingress PE to adjust the
P2MP PSN tunnel topology. Definition of such communication mechanisms
are outside the scope of this document but a potential candidate
could be G-ACH adapted for P2MP topology. Upon detection of a failure
of the Egress PE, the Ingress PE could adjust the P2MP PSN tunnel
topology.
Following is the format of the PW Status Capability Parameter:
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| PW Status Cap (IANA) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved |
+-+-+-+-+-+-+-+-+
If a PE includes the PW Status Capability in LDP Initialization
Messages it implies that the PE is capable of both distributing and
receiving Status Messages. The reserved bits MUST be set to zero on
transmission and ignored on receipt. The PW Status Capability
Parameter can be exchanged only in LDP initialization messages.
3.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.
i. A Label Mapping message is sent to every Egress PE containing
the SAII configured as the source at the Ingress PE. The TAII
Leaf TLV includes one or more AII associated to the Attachment
Circuits of the Egress PE(s) defined as leaves of the PW tree.
3.5.4. Leaf Attachment Notification Message
The Ingress PE requires the successful leaf information to choose a
suitable existing MLDP P2MP LSP or RSVP-TE P2MP LSP for multiplexing.
When the Egress PE receives and processes the Label Mapping message,
it verifies the P2MP GID/ (optionally leaf-TAIIs), and checks if it
matches one of its configured Forwarders.
Jounay et al. Expires January 13, 2010 [Page 11]
Internet Draft Source-initiated P2MP PW Setup July 2009
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 "success PW attachment" 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 TLV is
attached to the LDP Notification message. The TAII Leaf
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 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.
3.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
MUST send a PW Status message of 0x00000001 - Pseudowire Not
Forwarding to its LDP peer signaling an error.
Jounay et al. Expires January 13, 2010 [Page 12]
Internet Draft Source-initiated P2MP PW Setup July 2009
3.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.
When applicable, this mechanism MUST be used to to ascertain that AC
at the Egress PE is capable to support traffic coming from AC at the
Ingress PE.
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, the Egress PE MUST send a PW Status message of 0x00000001 -
Pseudowire Not Forwarding to its LDP peer signaling an error.
3.5.7. Interface ID (Underlying P2MP PSN tunnel)
The P2MP SS-PW implies a P2MP underlying tunnel(s) as outlined in
[P2MP PW ENCAPS]. 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].
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.
Jounay et al. Expires January 13, 2010 [Page 13]
Internet Draft Source-initiated P2MP PW Setup July 2009
For that purpose the LDP Label mapping initiated by the Ingress PE
MUST provide the Interface ID TLV as defined in [LDP UPSTREAM] and
[RFC3472].
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
[RFC5331]. In other words the Interface ID contains information about
the label space used at the Egress PE to perform the inner (PW) label
lookup. 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.
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.
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.
Jounay et al. Expires January 13, 2010 [Page 14]
Internet Draft Source-initiated P2MP PW Setup July 2009
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
outside the scope of this document.
3.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 PW Attachment" code
message should be sent to the Ingress PE with an the TAII TLV updated
accordingly.
4. Security Considerations
This section will be added in a future version.
5. IANA Considerations
5.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 value is suggested for assignment:
FEC P2MP GID : 0x82
5.2. LDP TLV Type
This document uses a new LDP TLV type, from the "TLV TYPE NAME SPACE"
for the Label Distribution Protocol (LDP [RFC5036]).
The following value is suggested for assignment:
TLV Type Description
IANA assigned TAII Leaf
Jounay et al. Expires January 13, 2010 [Page 15]
Internet Draft Source-initiated P2MP PW Setup July 2009
This document defines a new PW Status Capability Parameter. The
following value is suggested for assignment: IANA Assigned
5.3. 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
------------- ----- ---------------------- ---------
"Success PW Attachment"
6. Acknowledgments
Many thanks to JL Le Roux for the discussions, comments and support.
The authors wish to thank Luca Martini for his comments.
7. References
7.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
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", April 2006
Jounay et al. Expires January 13, 2010 [Page 16]
Internet Draft Source-initiated P2MP PW Setup July 2009
[RFC5331] Aggarwal, R. and all, "MPLS Upstream Label Assignment
and Context-Specific Label Space", August 2008
[RFC3472] Berger, L., all, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Constraint-based Routed
Label Distribution Protocol (CR-LDP) Extensions",
January 2003
7.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-01.txt, July 2009
[LDP UPSTREAM] Aggarwal, R., Le Roux, JL., "MPLS Upstream Label
Assignment for LDP", Internet Draft, draft-ietf-
mpls-ldp-upstream-04.txt, July 2009
[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-07, July 2009
[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
[P2MP PW ENCAPS] Aggarwal, R., "Point-to-Multipoint Pseudo-Wire
Encapsulation", draft-raggarwa-pwe3-p2mp-pw-
encaps-01.txt
Jounay et al. Expires January 13, 2010 [Page 17]
Internet Draft Source-initiated P2MP PW Setup July 2009
Author's Addresses
Frederic Jounay
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: frederic.jounay@orange-ftgroup.com
Philippe Niger
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: philippe.niger@orange-ftgroup.com
Yuji Kamite
NTT Communications Corporation
Tokyo Opera City Tower
3-20-2 Nishi Shinjuku, Shinjuku-ku
Tokyo 163-1421
Japan
Email: y.kamite@ntt.com
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
Route de Villejust
Nozay, 91620
France
Email: martin.vigoureux@alcatel-lucent.com
Laurent Ciavaglia
Alcatel-Lucent
Route de Villejust
Nozay, 91620
France
Email: Laurent.Ciavaglia@alcatel-lucent.com
Simon Delord
Telstra
242 Exhibition Street
Melbourne, VIC, 3000, Australia
E-mail: simon.a.delord@team.telstra.com
Jounay et al. Expires January 13, 2010 [Page 18]
Internet Draft Source-initiated P2MP PW Setup July 2009
Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Jounay et al. Expires January 13, 2010 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 00:44:43 |