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