IETF Internet Draft Seisho Yasukawa
Proposed Status: Informational NTT Corporation
Expires: November 2005
Adrian Farrel
Old Dog Consulting
May 2005
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt
Support of LDP Multicast Label Switched Paths over
Point-to-Multipoint Label Switched Path Tunnels
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.
Abstract
Multiprotocol Label Switching (MPLS) includes the facility to
provision point-to-multipoint (P2MP) Traffic Engineered (TE) Label
Switched Paths (LSPs) which can be used to construct P2MP tunnels
across MPLS networks.
The Label Distribution Protocol (LDP) has also been extended to
support label distribution for multicast traffic by forming multicast
LSPs.
When traffic for a user network is carried across a provider network,
it is common practice for the traffic to be placed in tunnels. This
document examines the requirements to carry multicast MPLS traffic
across a provider network within P2MP MPLS tunnels, and sets out
solutions that meet those requirements.
Yasukawa and Farrel Page 1
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
Contents
1. Introduction .................................................. 3
2. Requirements .................................................. 3
3. Overview of Potential Solutions ............................... 4
4. Point-to-Multipoint Tunnels ................................... 5
4.1. Carrying Multicast LSPs in P2MP TE LSPs ..................... 5
4.2. Upstream Label Allocation ................................... 5
4.2.1. Operational Procedures .................................... 5
4.2.2. Protocol Extensions ....................................... 6
4.2.3. Applicability ............................................. 7
4.3. Tunnel Management ........................................... 7
4.3.1. Pre-Provisioned P2MP TE LSPs .............................. 7
4.3.2. Dynamic Provisioning of P2MP TE LSPs ...................... 7
4.3.3. Applicability ............................................. 8
4.4. Label Set Negotiation ....................................... 8
4.4.1. Operational Procedures .................................... 9
4.4.2. Protocol Extensions ....................................... 9
4.4.3. Applicability ............................................ 10
5. LSP Stitching ................................................ 10
5.1. Operational Procedures ..................................... 11
5.1.1. Dynamic Establishment and Maintenance of P2MP TE LSP ..... 11
5.1.2. Pre-Provisioned P2MP TE LSPs ............................. 12
5.2. Protocol Extensions ........................................ 13
5.3. Applicability .............................................. 13
6. Security Considerations ...................................... 14
7. IANA Considerations .......................................... 14
8. Acknowledgements ............................................. 14
9. Intellectual Property Considerations ......................... 14
10. Normative References ........................................ 14
11. Informational References .................................... 15
12. Authors' Addresses .......................................... 15
13. Full Copyright Statement .................................... 16
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 RFC 2119 [RFC2119].
Readers should be familiar with the concepts of MPLS set out in
[RFC3031], with the mechanics of MPLS P2MP TE LSP establishment
described in [P2MP-RSVP], and with the proposals for LDP multicast
LSP signaling described in [P2MP-LDP] and [MCAST-LDP].
Yasukawa and Farrel Page 2
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
1. Introduction
The Label Distribution Protocol (LDP) supports the signaling of
hop-by-hop for point-to-point Label Switched Paths (LSPs) in support
of flows based on Forwarding Equivalence Classes (FECs) [RFC3036].
LDP has been extended to support label distribution for multicast
traffic by forming multicast LSPs [P2MP-LDP] and [MCAST-LDP].
The establishment and use of Multiprotocol Label Switching (MPLS)
Traffic Engineered (TE) LSPs is described in [RFC3209]. These
techniques have been extended to include the facility to provision
point-to-multipoint (P2MP) MPLS TE LSPs which can be used to
construct P2MP tunnels across MPLS networks [P2MP-RSVP].
When traffic for a user network is carried across a provider network,
it is common practice for the traffic to be placed in tunnels. This
is an established practice within MPLS where point-to-point LDP LSPs
may be carried across a core network in point-to-point TE LSPs
[RFC3031].
This document examines the requirements to carry multicast MPLS
traffic across a provider network within P2MP MPLS tunnels, and sets
out solutions that meet those requirements.
This document does not examine the issues of carrying
multipoint-to-multipoint LDP LSP, nor to the use of
multipoint-to-multipoint TE LSPs.
2. Requirements
The requirements to transport LDP multicast LSPs using P2MP TE LSPs
may be simply stated.
- Aggregation.
If the ration of transporting LSPs to transported LSPs is better
than 1:1 then there are processing savings in the core network.
These savings apply in the control plane where less LSP state needs
to be maintained, and in the data plane where fewer labels are
required.
- Explicit Path Control.
The procedures for P2MP TE LSP establishment and maintenance
[P2MP-RSVP] allow for control of the path that the P2MP TE LSP
follows. This facilitates traffic engineering such that LSPs can be
routed around network faults or hot-spots. This facility is not
available in LDP [RFC3036] or the multicast extensions [P2MP-LDP]
and [MCAST-LDP].
Yasukawa and Farrel Page 3
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
- Resource Reservation.
[P2MP-RSVP] allows resources to be allocated and dedicated to the
traffic of a particular P2MP TE LSP. Not only does this mechanism
facilitate improved traffic engineering, but it provides a means to
offer quality of service guarantees for LDP multicast LSPs that
traverse a core network. This function is not available in LDP
[RFC3036] or the multicast extensions [P2MP-LDP] and [MCAST-LDP].
There may also be resource savings associated with the aggregation
of multiple LDP multicast LSPs into a single P2MP TE LSP because
assumptions can be made about average traffic flows.
- Protection and Other Services.
P2MP TE LSPs have access to a range of high-function services such
as end-to-end protection, segment protection, and layered
networking that are achieved through extensions to RSVP-TE
[RFC3209] upon which the signaling of these LSPs is based
[P2MP-RSVP]. These services are not available in LDP [RFC3036] or
the multicast extensions [P2MP-LDP] and [MCAST-LDP].
These requirements are no different from the requirements applied in
point-to-point MPLS. They do not need further description here, but
can be seen in further detail as applied to point-to-point MPLS in
[RFC3031]. Some of the reasons for the existence and use of P2MP TE
LSPs can be found in [P2MP-SIG-REQ].
3. Overview of Potential Solutions
Two approaches to the use of P2MP TE LSPs to carry LDP multicast LSPs
are described in this document. The first is tunneling in which one
or more LSPs is 'nested' within another LSP. The second is stitching
in which a single end-to-end LSP uses some other LSP as a middle
segment.
These techniques are described in greater detail in the sections that
follow where comments are made on the requirements that drive these
approaches and on the applicability of the solutions that they
supply.
Yasukawa and Farrel Page 4
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
4. Point-to-Multipoint Tunnels
This section examines the use of P2MP TE LSPs as tunnels for one or
more LDP multicast LSPs.
4.1. Carrying Multicast LSPs in P2MP TE LSPs
P2MP TE LSPs may be used as tunnels to carry LDP multicast LSPs by
using standard label stacking techniques. That is, when a packet for
the LDP multicast LSP enters the tunnel an additional label is added
to the label stack, and it is this label that is used to switch the
data as it traverses the tunnel. At the end of the tunnel the
additional label is removed revealing the original lower label which
has not been changed as the data traversed the tunnel.
There is nothing special about this process as applied to P2MP TE
LSPs or LDP multicast LSPs.
4.2. Upstream Label Allocation
A feature of the use of a tunnel to carry MPLS traffic is that the
packets exit the tunnel with the same label as that used when they
entered the tunnel. That is, any label imposed on the label stack for
the purpose of traversing the tunnel is stripped from the stack
exposing the original label.
For traffic carried over a P2MP tunnel this means that all packets
arriving at the tunnel's end-points will have the same label. That
is, multiple downstream LSRs will receive traffic for the same
multicast flow, and that traffic will be labeled identically.
This causes an obvious issue for the downstream LSRs each of which is
expecting to advertise its own label for the flow. Clearly some form
of coordination is required so that each LSR can expect the same
label.
One solution to this problem, Upstream label Advertisement, is
described below.
4.2.1. Operational Procedures
The upstream LSR cannot simply advertise labels for the multicast FEC
because it does not know about the FEC, nor does it know which
downstream LSRs wish to participate in the multicast LSP. Therefore,
it must wait until it receives an indication from its downstream
neighbor. The mechanism described here draws heavily on the protocol
exchanges that already exist in LDP [RFC3036] and the modifications
for advertising labels for multicast FECs as described in [P2MP-LDP]
and [MCAST-LDP].
Yasukawa and Farrel Page 5
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
An LSR that wishes to use an LDP multicast LSP over a P2MP tunnel (or
over a multi-access link) sends a LabelMapping message to its
upstream neighbor (the root of the tunnel) using a targeted LDP
adjacency. However, instead of advertising the label it wishes to see
used for incoming traffic, it uses a special label value (TBD) to
indicate that it wishes the upstream LSR to allocate a label. In this
way, no change to the LabelMapping message is needed to support this
function.
When the upstream LSR receives a LabelMapping containing a multicast
FEC and the label value that indicates that an upstream label
allocation is required, it responds with a LabelRequest message. A
new "Suggested Label" TLV is added to the message (see definition
below), and the message MUST also contain the multicast FEC as
received in the LabelMapping message. If the upstream LSR is unable
or unwilling to suggest a label, it MUST respond with a LabelRelease
message indicating the received multicast FEC.
When a downstream LSR receives a LabelRequest message carrying a
Suggested Label TLV, it responds with a LabelMapping message using
that label if it is appropriate and suitable, or with an advisory
Notification message indicating the new status code "Suggested Label
not Accepted".
The act of sending a LabelRequest in response to a received
LabelMapping message is a change to the state machines of an LDP
implementation, but is triggered in very specific circumstances.
Otherwise, the state machines are unchanged by this procedure.
Note that the procedures described above are constructed such that
upstream label allocation and label suggestion could be used in other
circumstances, but this document is limited to considerations of
multicast LSPs operating over P2MP tunnels.
4.2.2. Protocol Extensions
The procedures described above require several minor protocol
extensions to LDP as described in [RFC3036], [P2MP-LDP] and
[MCAST-LDP].
- Allocation of a reserved label value to indicate that upstream
label allocation is request. The value TBD is suggested.
- Acceptance of the Multicast FEC (as defined by [P2MP-LDP] and
[MCAST-LDP]) on a LabelRequest message.
- Definition of a new Suggested Label TLV for inclusion on a
LabelRequest message. The format of this TLV is shown below.
- The definition of a new status code for use on an advisory
Notification message as follows:
Status Code E Status Data
Suggested Label not/ 0 TBD
Accepted
Yasukawa and Farrel Page 6
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
The Suggested Label TLV has the following format. The TLV type number
is TBD; it is suggested that it comes from the range 0x0200-0x02FF.
Note that the U and F bits are clear.
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| Suggested Label (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Suggested Label
This is a 20-bit label value as specified in [RFC3032] represented
as a 20-bit number in a 4 octet field.
4.2.3. Applicability
These procedures are fully applicable to the use of a P2MP TE LSP to
carry one or more LDP multicast LSPs. Note, however, that the
following sections on Tunnel Management and Label Set Negotiation
introduce some issues that constrain the applicability of these
techniques.
4.3. Tunnel Management
The P2MP TE LSPs used to carry LDP multicast LSPs may be dynamically
established or pre-provisioned.
4.3.1. Pre-Provisioned P2MP TE LSPs
P2MP TE LSPs can be pre-provisioned according to management requests.
For example, such LSPs can be set up to connect LSRs that have
targeted LDP adjacencies.
When an LSR receives a targeted LabelMapping message requesting an
upstream label allocation for a new multicast LSP as described in
section 4.2, it SHOULD select a suitable P2MP TE LSP to carry it. The
mechanism for such a selection is out of scope of this document,
however, see the comments in section 4.3.3 on the applicability of
this approach.
4.3.2. Dynamic Provisioning of P2MP TE LSPs
A P2MP TE LSP can be provisioned on demand according to the
requirements of the LDP multicast LSPs that it carries. If no
suitable pre-provisioned (either through configuration or through
dynamic operation) P2MP TE LSP exists, a new one can be established
in reaction to the exchange of LDP messages according to the
following rules.
Yasukawa and Farrel Page 7
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
The upstream LSR that receives a LabelMapping message for an LDP
multicast LSP and cannot select an existing P2MP TE LSP, establishes
a new P2MP TE LSP with itself as the root and its remote LDP peer as
the only leaf. Once this LSP has been established, the LDP message
exchange can continue as previously described.
As new remote LDP peers send further LabelMapping messages for the
same LDP multicast LSP, the root of the P2MP TE LSP can simply add
leaves to the P2MP TE LSP. Leaves can also be pruned from the P2MP TE
LSP when they have withdrawn all of the labels that they advertised
and when they no longer participate in any LDP multicast LSPs that
use the P2MP TE LSP.
The mechanism for adding and pruning leaves is equally applicable to
P2MP TE LSPs that were created on demand or through operator action.
4.3.3. Applicability
A significant issue with the dynamic choice between existing P2MP TE
LSPs is that it is not known, at the time of receipt of the first
LabelMapping message, which other leaves will participate in the LDP
multicast LSP. It is important that a P2MP TE LSP be chosen that
reaches each of the leaves that will require to receive the LDP
multicast LSP. The option of adding new leaves is functional from the
perspective of the new LDP multicast LSP, but means that traffic for
all of the other LDP multicast LSPs will now be delivered to leaves
that do not wish to see it.
A better applicability may be realized with the knowledge that core
networks typically serve to deliver traffic between remote sites that
have a strong association (for example, between sites of a multicast
VPN). In this case, a P2MP TE LSP may be sensibly pre-established
between the source site and each of the receiver sites, and all LDP
multicast LSPs associated with the VPN may be assigned to that
tunnel. Leaves may be added to or pruned from the P2MP TE LSP either
dynamically depending on demand from the LDP messages, or more
probably as a management action.
4.4. Label Set Negotiation
A potential issue with upstream label allocation as described above
arises from the fact that each downstream LSR (that is, each leaf of
the P2MP TE LSP) must be prepared to receive traffic for an LDP
multicast LSP with the same label. Although the process described in
the previous sections can arrange for the same label to be allocated,
it cannot handle the case where one of the LSPs cannot utilize the
suggested label.
Yasukawa and Farrel Page 8
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
In order to understand the scope of this issue it is necessary to
examine the circumstances under which it can arise.
a If a downstream LSR is using the global label space, it is very
possible that a suggested label is already in use for some other
LSP.
b If devices have significantly different switching capabilities it
is possible that they will support only subsets of the full label
range and those subsets might not overlap.
c If there are multiple upstream LSRs that can communicate with the
same (or an overlapping) set of downstream LSRs then per-interface
label spaces do not solve the problem a., above. This might arise
on a multi-access network, but it can also occur where multiple
P2MP TE LSPs from different roots include the same leaf since those
roots are all upstream LDP neighbors of the leaf and are accessed
through the same interface.
It may be argued that problem b. is not a soluble problem, but that
it is also unlikely to occur with MPLS packet switches that can
usually handle the full range of labels.
A solution to the remaining issues is to arrange for some form of
label set negotiation between the leaves and the root of any P2MP TE
LSP that may carry an LDP multicast LSP. This negotiation makes the
set of suitable labels for any LDP multicast LSP a property of the
P2MP TE LSP that is, a property of the P2MP tunnel that connects the
root to the leaves. With the knowledge of this label set (which is
the intersection of the label sets that each leaf is willing to see
used for an LDP multicast LSP), the root is able to select a suitable
label and suggest it using the techniques described above.
A mechanism for label set negotiation for each P2MP TE LSP is
described below.
4.4.1. Operational Procedures
TBD
4.4.2. Protocol Extensions
TBD
Yasukawa and Farrel Page 9
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
4.4.3. Applicability
This solution of label set negotiation is applicable on top of the
tunneling technique described in section 4.2.
The technique described here is best applied to pre-established P2MP
TE LSPs that connect a stable set of remote LDP peers, such as might
happen when the P2MP TE LSP leaves provide access to VPN sites. In
this case the P2MP TE LSP can be expected to stable and it is
reasonable to apply label set negotiation per P2MP TE LSP.
It is not clear that this technique would be of any value when
applied to dynamic P2MP TE LSPs (that is ones to which new leaves can
be added) since the label selected for the existing leaves might
prove to be unsuitable for any new leaf.
5. LSP Stitching
LSP Stitching is defined in [STITCHING] as a mechanism where an
end-to-end MPLS LSP can use an intermediate LSP to provide a segment
of the path. Within the control plane the techniques applied are
similar to those used for tunneling, but within the data plane the
LSP segments are 'stitched' together so that there is a one-to-one
relationship between LSP segments and no tunneling is used. In a
packet network, the use of stitching does not result in the
imposition of an additional label. LSP stitching may be applicable to
the transport of a multicast LSP across a network that supports P2MP
MPLS traffic engineering. In particular, a P2MP MPLS TE LSP may be
established across the core network, and the multicast LDP LSP
segments may be stitched to the P2MP TE LSP at the edges of the
network.
By way of illustration, the figure below shows an MPLS TE network
containing the LSRs A through G. A multicast LSP is to be established
from source s to receivers r1 through r7. A P2MP TE LSP is
established from A to the leaves D, E and G as shown in the figure.
The multicast LSP is established as shown and is stitched to the P2MP
TE LSP at the root (A) and at the leaves.
Yasukawa and Farrel Page 10
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
............ r2
: : |
: -D--c--d--r3
: / :
: / :
s--a--b--A---B---C---E--e--r4
| : \ :
| : \ :
r1 : F----G--f--g--r5
: : |
........... h--r6
|
r7
Modifications to existing operational and signaling procedures are
required as described below.
5.1. Operational Procedures
This section sets out the operational mechanisms necessary to support
stitching of multicast LSPs to P2MP TE LSPs. Two approaches are
presented: in the first, the P2MP TE LSP is established and
maintained on demand; in the second, the P2MP TE LSP is
pre-provisioned (perhaps through management action) and is used by
the multicast LSP as necessary.
5.1.1. Dynamic Establishment and Maintenance of P2MP TE LSP
Consider the first receiver wishing to join an LDP multicast LSP. It
advertises its availability and a label using the mechanisms
described in [P2MP-LDP] or [MCAST-LDP]. For example, in the figure
above, r4 may advertise a label to LSR e. In its turn, LSR e will
advertise a label to LSR E.
When the multicast LDP label advertisement reaches the LSR at the
edge of the TE network, it is necessary to establish the TE LSP, but
this must be done using the processes described in [P2MP-RSVP] which
are initiated by the root of the LSP, in our example, LSR A. LSR E,
therefore, establishes a targeted LDP adjacency with LSR A and
advertises the multicast LSP as for normal multicast LDP. The LSR on
the other side of the TE network (LSR A) then establishes the P2MP TE
LSP back across the network (from LSR A to LSR E). When the leaf of
the P2MP TE LSP (LSR E) returns a Resv message to say that it has
established the LSP, it stitches the P2MP TE LSP to the LDP multicast
LSP making the appropriate entries in its LFIB. When the root of the
P2MP TE LSP (LSR A) receives the Resv to say that the LSP has been
fully established, it continues the multicast LDP advertisement
upstream, and stitches the LDP multicast LSP to the P2MP TE LSP.
Yasukawa and Farrel Page 11
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
Further leaves are added to the P2MP TE LSP using the same process.
If the root of the P2MP TE LSP receives a targeted LabelMapping
message from an LDP peer advertising another branch to the LDP
multicast LSP it simply adds a new leaf to the P2MP TE LSP using the
techniques described in [P2MP-RSVP]. The new leaf will stitch the
LSPs together, and no further action will be required at the root of
the P2MP TE LSP.
Pruning operations follow similar principles. When the root of a P2MP
TE LSP receives a LabelWithdraw for an LDP multicast LSP it prunes
the associated leaf form the P2MP TE LSP. Note that a root MAY choose
to delay this pruning operation if it believes that there is a high
likelihood of a new receiver causing the leaf to re-join the P2MP TE
LSP. Unstitching activity happens at the P2MP TE LSP leaf as a
condition of it sending the LabelWithdraw, and at the P2MP TE LSP
root when it removes the final leaf from the P2MP TE LSP (that is,
when it tears the LSP down).
Note that it is assumed that the downstream leaf LSR (LSR E in the
example) knows how to find the upstream root (LSR A) and to establish
a targeted LDP adjacency across the TE network. This process is
similar to the way in which a downstream router determines the
upstream router that is the next hop on the path towards a multicast
source, and may be achieved through configuration or routing
protocols, but is outside the scope of this document. The targeted
LDP sessions MAY be established ahead of time as a result of
configuration or some membership protocol exchange, or MAY be
established on-demand.
5.1.2. Pre-Provisioned P2MP TE LSPs
The stitching technique described here can also make use of
pre-provisioned P2MP TE LSPs. Such LSPs can be set up as a result of
management action, and when a leaf sends a targeted LabelMapping
message to the root, there is no further requirement for RSVP-TE
signaling and all that is required is that the LSPs should be
stitched.
Note that some special care is taken when a targeted LabeWithdraw is
received at the root of the P2MP TE LSP since it SHOULD NOT prune the
associated leaf from a pre-provisioned P2MP TE LSP. This feature,
however, is a matter for the implementation and is outside the socpe
of any protocol procedures.
Note further that it is possible to mix the techniques described in
this section with the dynamic mechanism set out in the previous
section. That is, it is possible to dynamically add leaves to a
pre-provisioned LSP, and this can be done without requiring any
additional procedures. Again, the root of the P2MP TE LSP will want
to take care when processing a received LabelWithdraw since it SHOULD
only prune those leaves that were added dynamically.
Yasukawa and Farrel Page 12
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
5.2. Protocol Extensions
Two protocol extensions are required for this technique.
- The targeted Label Advertisement from the P2MP TE LSP leaf to root
does not need to carry a label since the labels used will be
advertised using the P2MP RSVP-TE procedures. Thus a special label
value of TDB is used in the LabelMapping message. The details of
this mechanism are to be completed depending on the developments of
[P2MP-LDP] and [MCAST-LDP].
- The P2MP TE LSP leaf must be able to correlate the new P2MP TE LSP
with the LabelMapping message that it previously send to the P2MP
TE LSP root. This is achieved by adding a new, optional piece of
information to the destination-specific information signaled in the
Path message extensions defined in [P2MP-RSVP].
A new object, the Multicast FEC Payload object, is defined to carry
the multicast FEC as advertised in the LabelMapping. The precise
format of this object is for future study depending on the
developments of [P2MP-LDP] and [MCAST-LDP].
Note that as an alternative, the S2L SUB-LSP Objects could be
defined to allow TLVs. The required information could then be
included in a TLV in this object.
5.3. Applicability
Note that upstream label choice is not an issue in this technique,
and this is a considerable advantage. That is, there is no need to
coordinate the labels used to send traffic to each of the leaves of
the P2MP TE LSP because the P2MP TE LSP is not being used as a
tunnel.
On the other hand, it is in the nature of LSP stitching that traffic
cannot be aggregated. That is, each P2MP TE LSP can carry the traffic
for precisely one multicast LSP. In some circumstances this may be
considered a major disadvantage.
This mechanism, therefore, is a benefit where there is a desire to
provide advanced network functions (traffic engineering, protection,
resource reservations, etc.) for multicast MPLS traffic as it is
carried across the core, but is of no value where it is important to
collect that traffic together to achieve benefits of aggregation.
Note further the comments in section 4.3.3 on the applicability of a
single P2MP TE LSP to carry multiple LDP multicast LSPs. In many
circumstances the choice of a suitable P2MP TE LSP may be ambiguous,
in which case a 1:1 relationship between P2MP TE LSP and LDP
multicast LSP may not be considered an impediment.
Yasukawa and Farrel Page 13
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
6. Security Considerations
TBD
7. IANA Considerations
This document will propose some minor extensions to LDP that may
require the allocation of new code points under the care of IANA. A
future version of this document will include the relevant
information.
8. Acknowledgements
TBD
9. Intellectual Property Considerations
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.
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[P2MP-RSVP] Aggarwal, R., Papadimitriou, D., and Yasukawa, S.,
"Extensions to RSVP-TE for Point to Multipoint TE
LSPs", draft-ietf-mpls-rsvp-te-p2mp, work in progress.
[P2MP-LDP] Minei, I., et al., "Label Distribution Protocol
Extensions for Point-to-Multipoint Label Switched
Paths", draft-minei-mpls-ldp-p2mp, work in progress.
Yasukawa and Farrel Page 14
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
[MCAST-LDP] Wijnands, IJ., et al., "Multicast Extensions for LDP",
draft-wijnands-mpls-ldp-mcast-ext, work in progress.
11. Informational References
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol Label Switching Architecture",
RFC 3031, January 2001.
[RFC3036] Andersson, L. et al., "LDP Specification", RFC 3036,
January 2001.
[RFC3209] Awduche, et al, "Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[P2MP-SIG-REQ] Yasukawa, S. (Editor), "Signaling Requirements for
Point to Multipoint Traffic Engineered MPLS LSPs",
draft-ietf-mpls-p2mp-sig-requirement, work in
progress.
[STITCHING] Ayyangar, A., and Vasseur, J-P., "LSP Stitching with
Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching,
work in progress.
[UPSTREAM] Aggarwal, R., Rekhter, Y., and Rosen, E., "MPLS
Upstream Label Assignment and Context Specific Label
Space", draft-raggarwa-mpls-upstream-label, work in
progress.
12. Authors' Addresses
Seisho Yasukawa
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585,
Japan
Phone: +81 422 59 4769
Email: yasukawa.seisho@lab.ntt.co.jp
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
Yasukawa and Farrel Page 15
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt May 2005
13. Full Copyright Statement
Copyright (C) The Internet Society (2005). 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.
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 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.
Yasukawa and Farrel Page 16