IETF Internet Draft Seisho Yasukawa NTT Corporation Expires: April 2006 Adrian Farrel Old Dog Consulting October 2005 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt Support of LDP Multicast Label Switched Paths over Point-to-Multipoint Label Switched Path Tunnels and on Multi-Access Links 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, Yasukawa and Farrel Page 1 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 it is common practice for the traffic to be placed in tunnels. This document examines the requirements to carry multicast LDP traffic across a provider network within P2MP MPLS tunnels, and introduces solution models that meet those requirements. Note that the requirements and solutions discussed in this document are also applicable to the use of multicast LDP on multi-access networks. 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 need to 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 multicast LDP LSP signaling described in [P2MP-LDP]. Throughout this document, "P2MP" is used to refer to point-to-multipoint traffic engineered LSPs, while "multicast" is used to refer to LDP LSPs established in support of multicast traffic flows. Yasukawa and Farrel Page 2 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 Contents 1. Introduction ................................................... 4 2. Requirements ................................................... 4 2.1. Requirements for the use of Multi-Access Links ............... 6 3. Problem Statement .............................................. 7 4. Overview of Potential Solutions ................................ 8 5. Upstream Label Allocation ...................................... 8 5.1. Operational Procedures ....................................... 8 5.1.1. Agreement to Use Upstream Label Allocation ................. 9 5.1.2. Label Distribution ......................................... 9 5.1.3. Label Solicitation ......................................... 9 5.1.4. Determining the Participating Downstream LSRs .............. 9 5.1.5. Processing of Received Labels .............................. 9 5.2. Comparison with Previous LDP Mechanisms ..................... 10 5.3. Applicability ............................................... 10 5.3.1. P2MP TE Tunnels ........................................... 10 5.3.2. Multi-Access Links ........................................ 12 5.3.3. Mixing Upstream-Capable and Non-Upstream Capable LSRs ..... 12 5.4. Issues and Open Questions ................................... 13 6. Upstream Label Suggestion ..................................... 14 6.1. Operational Procedures ...................................... 14 6.1.1. Agreement to Use Upstream Label Suggestion ................ 14 6.1.2. Label Distribution ........................................ 15 6.1.3. Downstream on Demand ...................................... 15 6.1.4. Determining the Participating Downstream LSRs ............. 16 6.1.5. Processing of Received Labels ............................. 16 6.2. Protocol Extensions ......................................... 16 6.3. Comparison with Previous LDP Mechanisms ..................... 17 6.4. Applicability ............................................... 18 6.4.1. P2MP TE Tunnels ........................................... 18 6.4.2. Multi-Access Links ........................................ 19 6.4.3. Mixing Suggestion-Capable and Non-Suggestion Capable LSRs . 19 6.5. Issues and Open Questions ................................... 19 7. LSP Stitching ................................................. 21 7.1. Operational Procedures ...................................... 22 7.1.1. Dynamic Establishment and Maintenance of P2MP TE LSP ...... 22 7.1.2. Pre-Provisioned P2MP TE LSPs .............................. 23 7.2. Protocol Extensions ......................................... 24 7.3. Applicability ............................................... 24 7.3.1. Applicability to Multi-Access Links ....................... 25 8. Security Considerations ....................................... 25 9. IANA Considerations ........................................... 25 10. Acknowledgements ............................................. 25 11. Intellectual Property Considerations ......................... 26 12. Normative References ......................................... 26 13. Informational References ..................................... 27 14. Authors' Addresses ........................................... 27 15. Full Copyright Statement ..................................... 28 Yasukawa and Farrel Page 3 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 1. Introduction The Label Distribution Protocol (LDP) [RFC3036] is a set of procedures by which Label Switching Routers (LSRs) distribute labels to support Multi Protocol Label Switching (MPLS) [RFC3031] forwarding of unicast traffic along routing paths set by an IP unicast routing protocol. Label Switched Paths(LSPs) are established to carry traffic that is identified by its Forwarding Equivalence Class (FEC). LDP has been extended [P2MP-LDP] to distribute labels to support MPLS forwarding of multicast traffic by forming "multicast LSPs." The establishment and use of point-to-point (P2P) MPLS Traffic Engineered (TE) LSPs is described in [RFC3209]. These LSPs may be treated as P2P tunnels across the network. The techniques described in [RFC3209] have been extended to support 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 networks where P2P LDP LSPs may be carried across a core network in P2P TE LSPs [RFC3031]. This document examines the requirements to carry multicast LDP LSPs across a provider network within P2MP MPLS tunnels, and introduces solution models that meet those requirements with text clarifying the applicability of the solutions to different environments and requirements. The problems associated with supporting multicast LDP LSPs over P2MP MPLS-TE LSPs can be observed to be very similar to the problems of supporting multicast LDP LSPs on multi-access links. This document also examines the applicability of the solutions it introduces to multi-access environments. 2. Requirements Details of specific requirements for multicast LDP can be found in [P2MP-LDP, P2MP-LDP-REQ]. Further details of the requirements for P2MP TE LSPs can be found in [P2MP-SIG-REQ]. These requirements are not directly within the scope of this document. By way of illustration, the figure below demonstrates the type of network to be considered. An MPLS TE network (LSRs A through G) lies within an LDP network (LSRs s, r1 through r7, and a through h). A multicast LDP 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. Yasukawa and Farrel Page 4 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 ............ r2 : : | : -D--c--d--r3 : / : : / : s--a--b--A---B---C---E--e--r4 | : \ : | : \ : r1 : F----G--f--g--r5 : : | ........... h--r6 | r7 The requirements to transport multicast LDP LSPs using P2MP TE LSPs may be simply stated. - Aggregation. If the ratio 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 and label swapping actions 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] and is usually achieved by tunneling LDP LSPs within MPLS-TE LSPs. The solutions described in this document extend such tunneling techniques for the use of multicast LDP LSPs. - Resource Reservation. [RFC3209] allows resources to be allocated and dedicated to the traffic of a particular P2P TE LSP. Not only does this mechanism facilitate improved traffic engineering, but it provides a means to offer quality of service guarantees for LSPs that traverse a core network. This function is not available in LDP [RFC3036] and may be enabled by tunneling LDP LSPs within MPLS-TE LSPs. The solutions described in this document extend such resource reservation techniques by tunneling multicast LDP LSPs through P2MP MPLS-TE LSPs which also allow resource reservation [P2MP-RSVP]. There may also be resource savings associated with the aggregation of multiple multicast LDP LSPs into a single P2MP TE LSP because assumptions can be made about average traffic flows. Yasukawa and Farrel Page 5 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 - Protection and Other Services. P2P MPLS-TE LSPs [RFC3209] can provide a range of high-function services such as end-to-end protection, segment protection, and layered networking through a range of extensions to the base protocol. These extensions are similarly available to P2MP MPLS-TE LSPs since the signaling of these LSPs [P2MP-RSVP] is based on the protocols described for P2P MPLS-TE LSPs [RFC3209]. These services are not available in LDP [RFC3036] and are often achieved by tunneling LDP LSPs within MPLS-TE LSPs (for example, fast re-route [RFC4090]). The solutions described in this document extend such tunneling techniques for the use of multicast LDP LSPs tunneled within P2MP MPLS-TE LSPs. These requirements are no different from the requirements applied in P2P MPLS. They do not need further description here, but can be seen in further detail as applied to P2P MPLS in [RFC3031]. Note, however, that the mechanisms for meeting these requirements are constrained by the problem statement stated in section 3. This means that the mechanisms used for the support of P2P LDP LSPs over P2P MPLS-TE LSPs are not optimal. Some further reasons for the existence and use of P2MP TE LSPs can be found in [P2MP-SIG-REQ]. 2.1. Requirements for the use of Multi-Access Links Multi-access links (such as Ethernet links) are present to a limited degree in some provider networks. Where multicast LDP is used there is a resultant need to be able to establish multicast LDP LSPs that traverse these multi-access links. The figure in section 2 may be modified to show how a multicast LDP LSP needs to be carried over a multi-access link. ............ r2 : : | : -----D--c--d--r3 : | : : | : s--a--b--A-----+-----E--e--r4 | : | : | : | : r1 : -----G--f--g--r5 : : | ........... h--r6 | r7 Yasukawa and Farrel Page 6 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 It will be observed that, for an individual flow, a multi-access link presents many of the same characteristics as a P2MP tunnel. That is, there is a single entry point onto the link for the flow (this corresponds to the ingress of the P2MP tunnel) and one or more exit points from the link (corresponding to the leaves of the P2MP tunnel). In general, there may be some scaling differences between a network in which P2MP tunnels are used, and a multi-access link. A multi-access link in a provider network is likely to have a relatively small number of stations, while P2MP tunnels may have very many leaves, and an individual leaf may be present on very many tunnels established from a large number of different roots. 3. Problem Statement Multicast LSP traffic can be carried over an MPLS-TE network or a multi-access link by having the upstream node replicate each packet for each of the downstream nodes. Thus, on a multi-access link, the upstream LSR would send a separate packet to each of the LSRs on the link that participate in the multicast flow. Similarly, individual P2P TE LSPs could be established through an MPLS-TE network to carry the traffic across the network to remote LDP peers. However, in both of these cases inefficient use is made of the network resources and this may result in congestion on the links or in the sending node. The intention is to avoid this problem by using a P2MP TE LSP in the MPLS-TE network or utilizing the multicast facilities of the layer 2 technology of the multi-access link. If this is done, only a single copy of the packet needs to be transmitted, and the packet will be carried to all receivers in the most efficient way. It should be obvious that if only one copy of an LDP packet is transmitted, it can only carry one LDP label. Since this packet will be replicated by the underlying technology (the P2MP TE LSP or the layer 2 transfer mechanism) an identical copy of the packet will be received by all next-hop LDP LSRs. That means that each next-hop LDP LSR will be required to process the same label for the multicast flow. LDP labels are conventionally assigned by the downstream LSR [RFC3031, RFC3036] which means that to efficiently carry multicast LDP traffic over P2MP TE LSPs or multi-access links we need some additional mechanism to ensure that the downstream next-hop LDP LSRs can all use the same label for the same multicast flow. Yasukawa and Farrel Page 7 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 4. Overview of Potential Solutions This document examines three categories of solution. - Upstream label allocation is proposed in [UPSTREAM]. In this solution, which is applicable to P2MP TE tunnels and to multi-access links, the upstream LSR is responsible for coordinating, allocating, and distributing the labels used by the downstream LSRs so that a single copy of the labeled packet may be sent to all downstream LSRs. - Upstream label suggestion re-uses the label suggestion procedures of [RFC3473] to allow the upstream LSR to coordinate label allocation through suggestion, but leaves the responsibility for label allocation and distribution with the downstream LSR as in [RFC3036]. This solution is also applicable to P2MP TE tunnels and to multi-access links. - The third solution is applicable only to P2MP TE LSPs, and involves stitching multicast LSP segments to P2MP TE LSPs. This technique avoids the requirement for label coordination by the upstream LSR, but looses some of the benefits of aggregation within P2MP TE LSPs in the core network. Note that the procedures described in this document are such that upstream label allocation, upstream label suggestion, and LSP stitching could be used in other circumstances, but this document is limited to considerations of multicast LSPs operating over P2MP tunnels and multi-access links. 5. Upstream Label Allocation A technique to solve the issue of coordination of labels between downstream LSRs for multicast LDP LSPs is to have those labels allocated and advertised by the upstream LSR [UPSTREAM]. This represents a change to the MPLS architecture [RFC3031] where labels were assigned and advertised only by the downstream LSR, and this change is documented in [UPSTREAM-ARCH]. 5.1. Operational Procedures The operational procedures for this solution are described fully in [UPSTREAM] and are only summarized here for comparison with the other suggested solutions. The reader should refer to [UPSTREAM] for a definitive description of these procedures. Yasukawa and Farrel Page 8 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 5.1.1. Agreement to Use Upstream Label Allocation LDP peers agree that upstream label allocation may be used between them by exchanging a capability indication on the LDP Hello message. Neither LDP peer may use upstream label allocation unless both peers have indicated that they support upstream label allocation. 5.1.2. Label Distribution Labels for a particular multicast flow are allocated and distributed by the upstream LSR. A new TLV is used to identify the label as an upstream label allocation, and this is sent together with the multicast FEC [P2MP-LDP] on a LabelMapping message from the upstream LSR to each of the downstream LSRs. 5.1.3. Label Solicitation A downstream LSR may request upstream label allocation for a specific multicast FEC by sending a LabelRequest message to the upstream LSR containing the multicast FEC TLV and a new TLV that requests upstream label allocation. The upstream LSR responds using the procedures described in 5.1.2. 5.1.4. Determining the Participating Downstream LSRs To alternatives may be used. In the first case, the upstream LSR may wait for a specific request for a label for a multicast flow. In this case the downstream LSR determines that it is part of the multicast flow, determines which is its upstream neighbor, and sends a LabelRequest message as described in section 5.1.2. This procedure may be termed Upstream-On-Demand label distribution. Alternatively, the upstream LSR may distribute labels to all connected downstream LSRs as described in section 5.1.2. This procedure may be termed Upstream-Unsolicited label distribution. 5.1.5. Processing of Received Labels An LSR that receives a labeled packet must determine the context for the label before performing switching operations. If the LSR supports its own label allocation (downstream label allocation) and also supports label allocation by its upstream neighbor, it is possible that the same label will be allocated by the LSR and its upstream neighbor for different LSPs on the same link. The labels (and so the LSPs) can be differentiated by the use of different Ethertypes that indicate whether the labeled packet that is carried in a layer 2 frame uses an upstream or downstream allocated label. Yasukawa and Farrel Page 9 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 Since a downstream LSR may have more than one upstream neighbor on the same interface (either because the interface connects to a multi-access link, or because the interface connects to a network in which P2MP TE LSPs are used) and since these upstream neighbors assign upstream labels independently, it is possible for two LSPs to use the same incoming, upstream-allocated label on the same interface. In order to distinguish the LSPs, the labels must be managed according to the upstream neighbor; this gives rise to the concept of "per-neighbor label spaces." 5.2. Comparison with Previous LDP Mechanisms - As is made clear in [UPSTREAM-ARCH], upstream label allocation represents a change to the MPLS architecture [RFC3031] in that labels may now also be allocated and distributed by the upstream LSR. - As described in section 5.1.4, upstream label allocation requires the use of the layer 2 Ethertype to distinguish LSPs using upstream allocated labels from LSPs using downstream allocated labels. - As described in section 5.1.4, upstream label allocation requires the use of per-neighbor label spaces to differentiate LSPs using labels allocated by different upstream neighbors. - Upstream label distribution (on-demand or unsolicited) re-uses the LabelRequest and LabelMapping messages (and all other LDP messages) with their semantics preserved. It should be noted, however, that the direction of exchange of such messages is reversed in upstream label distribution compared to LDP as specified in [RFC3036]. That is, the LabelRequest message is used by an LSR to request label allocation, and the LabelMapping message is used by an LSR to supply a label. The direction of flow these messages and of all other label control LDP messages is altered depending on whether it is the upstream or downstream LSR that allocates the label. 5.3. Applicability 5.3.1. P2MP TE Tunnels The upstream label allocation technique is applicable to the use of multicast LDP over P2MP TE Tunnels. In this case the upstream LSR is the root of the tunnel, and the downstream LSRs are the leaves of the tunnel. The root must have a targeted LDP session with each of the leaves of the tunnel which means that the root must know about each of the leaves, but this is normal for P2MP MPLS-TE tunnels. Yasukawa and Farrel Page 10 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 Each leaf may be the leaf of multiple tunnels from the same root. In this case, it is not necessary for the leaf to maintain a separate label space for each tunnel as the upstream neighbor is the same in each case. An alternative implementation would be to treat each tunnel as an interface and to manage labels per interface. This might give better scaling properties where very many multicast LDP flows are aggregated onto each tunnel, but would, however, require a separate LDP session per tunnel which might negate any scaling benefits. Each leaf may also be the leaf of multiple tunnels from different roots. In this case, each root is a different upstream neighbor and its labels are managed from separate per-neighbor label spaces. The P2MP TE LSPs used to carry LDP multicast LSPs may be dynamically established or pre-provisioned. 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. Alternatively, when an upstream LSR receives a targeted LabelRequest message requesting an upstream label allocation for a new multicast LSP as described in section 5.1.4, 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, 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 LabelRequest message, which other leaves will participate in the multicast LDP 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 to an existing P2MP TE LSP is functional. 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 multicast LDP 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. A P2MP TE LSP can be provisioned on demand according to the requirements of the multicast LDP 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 11 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 - The upstream LSR that receives a LabelRequest message for a multicast LDP 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 LabelRequest 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 no longer participate in any multicast LDP LSPs that use the P2MP TE LSP. 5.3.2. Multi-Access Links Upstream label allocation is applicable to, and was developed specifically for use on multi-access links. In this case, the upstream LSR is just one hop away from the downstream LSRs across the multi-access link. The upstream LSR has a normal LDP session with each of the downstream LSRs which must be configured. Each station on the multi-access link may act as an upstream LSR for one or more multicast LSPs, and each may be a downstream LSR in one or more multicast LSPs. 5.3.3. Mixing Upstream-Capable and Non-Upstream Capable LSRs It is possible that an upstream LSR will have LDP sessions with downstream LSRs some of which are capable of supporting upstream label allocation, and some of which are not. On a multi-access link this can be resolved. The upstream LSR uses an upstream allocated label when sending a single packet for receipt by all downstream LSRs that are capable of receiving such a label, and uses pre-existing downstream label allocation techniques for all other downstream LSRs. In this way packets are duplicated on the link only for those downstream LSRs that cannot handle upstream allocated labels. Note, however, that because of the nature of the multi-access link, a downstream LSR that is not capable of handling upstream allocated labels will still receive packets from the upstream LSR labeled with the upstream label if it is used for other downstream LSRs. This can be overcome either by establishing specific broadcast groups for the upstream label allocation capable LSRs within the layer 2 technology, or by identifying the packets that carry upstream-allocated labels through a new Ethertype: this second option is used in [UPSTREAM]. Yasukawa and Farrel Page 12 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 It is not possible to mix LSRs (leaves) that support upstream label allocation with those that don't on P2MP TE tunnels because all packets injected into the tunnel are delivered to all leaves (there is no unicast technique within the tunnel as there is on a multi-access link). If there is a requirement to support TE tunneling of multicast LDP traffic from a root to a set of leaves some of which can support upstream label allocation and some of which cannot, a P2MP TE tunnel would be used between the root and all those leaves that can support upstream label allocation, and individual P2P TE tunnels would be used from the root to each of the leaves that did not support the function. 5.4. Issues and Open Questions Several questions remain unanswered in the current version of [UPSTREAM]. The inclusion of these questions here does not imply a criticism of this technique, but is provided to help complete the analysis of this mechanism and to compare it to others. 1. How is the label space (upstream neighbor) identified within the forwarding plane? The issue here is that the downstream LSR must disambiguate labels on received packets according to the upstream neighbor in order to apply the per-neighbor label space. It knows that it must do this because of the received Ethertype. An option here is to use the source address from the layer 2 frame in which the packet was received. This assumes that this information is available in the layer 2 frame and is accessible to the MPLS component. 2. How is an upstream allocated label identified within a label stack? While the use of an upstream label can be easily detected using the new Ethertype if the label is at the top of the label stack, this is not possible for labels lower down the stack (for example when multicast LDP flows are carried within P2MP MPLS-TE tunnels). It remains important to make this distinction to correctly process the labels. An option is to restrict the use of labels within a tunnel to be only upstream allocated, or only downstream allocated. This information can be exchanged during the signaling that establishes the tunnel. Yasukawa and Farrel Page 13 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 3. How does upstream label allocation work for Fast Re-Route? This is probably relatively simple to achieve, but needs specification. 4. What are the procedures if a downstream LSR rejects an upstream allocated label? This may happen if, for some reason, the downstream LSR cannot process the supplied label value. In this case the downstream LSR would reject the supplied label and the upstream LSR could either move the entire LSP to a new label, or establish a P2P LSP hop for the uncooperative downstream LSR. 6. Upstream Label Suggestion At first glance, upstream label suggestion looks similar to upstream label allocation in that the labels are coordinated by the upstream LSR, but the mechanism borrows from label suggestion techniques developed in GMPLS [RFC3473] while preserving the MPLS architecture by retaining label allocation at the downstream LSR. In these ways, upstream label suggestion is actually considerably different from upstream label allocation and should be considered as a separate technique, not a derivative solution. Note that GMPLS includes the concept of an Upstream Label, but in GMPLS, this concept applies to the label used for the reverse flow of a bidirectional LSP. Care must be taken to avoid confusing the two concepts. 6.1. Operational Procedures The procedures for upstream label suggestion are currently supplied in this document. 6.1.1. Agreement to Use Upstream Label Suggestion Upstream label suggestion is requested on a per-LSP basis by the downstream LSR (see subsequent sections). No prior agreement to use upstream label suggestion is needed. A downstream LSR that does not support the process will simply not request its use. An upstream LSR that does not support the process will reject the requested process as unknown. Yasukawa and Farrel Page 14 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 6.1.2. Label Distribution Label distribution for this model is from the downstream LSR. The downstream LSR must, however, seek help from the upstream LSR to coordinate the choice of a single label across multiple downstream LSRs. 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 using a targeted LDP session and including the appropriate multicast FEC. However, instead of advertising the label it wishes to see used for incoming traffic, it uses a special label value (TBD) from the reserved range 0 to 15 to indicate that it wishes the upstream LSR to suggest a label. When the upstream LSR receives a LabelMapping containing a multicast FEC and the label value that indicates that an upstream label suggestion 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 and the special label value. 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". At any time, the downstream LSR may decide to allocate a label itself without coordination through the upstream LSR - in this case, the upstream LSR will use that label for traffic to the downstream LSR even if that means it must replicate packets. In this way, no change to the sense of the LDP messages is required, but an additional message exchange is needed. The label distribution is essentially Downstream Unsolicited, but an extra consultation exchange is used to achieve coordination of the allocated labels. 6.1.3. Downstream on Demand An upstream LSR may also request label allocation by a downstream LSR in Downstream On-Demand mode. If the upstream LSR is aware of the need for a label for a multicast LDP to a particular downstream neighbor it may send a LabelMapping with a Suggested Label TLV without waiting for a LabelRequest message. The downstream LSR responds as described in the previous section. Yasukawa and Farrel Page 15 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 6.1.4. Determining the Participating Downstream LSRs To alternatives may be used. In the first case, the upstream LSR may wait for a specific request for a label for a multicast flow. In this case the downstream LSR determines that it is part of the multicast flow, determines which is its upstream neighbor, and sends a LabelMapping message as described in section 6.1.2. This procedure may be termed Downstream Unsolicited With Suggestion label distribution. Alternatively, the upstream LSR may suggest and request labels from all connected downstream LSRs as described in section 6.1.3. This procedure may be termed Downstream On-Demand With Suggestion label distribution. 6.1.5. Processing of Received Labels There is no substantial change to the processing of received labeled packets described in section 5.1.5 except to note that because the labels are allocated by the downstream LSR it is able to chose whether or not it maintains per-neighbor or per-interface label spaces. Further, this choice can even be made per-LSP. The trade-off of packet replication versus per-neighbor label spaces is obvious, but in this mode, the choice can be made by the downstream LSR. Note that if it is determined to use per-neighbor label spaces then the comparison between upstream label allocation and upstream label suggestion may be simply made and depends on message flows and architectural considerations, and not on data plane factors. 6.2. Protocol Extensions An overview of protocol extensions is included here because there is currently no other document describing this process. The procedures described above require several minor protocol extensions to LDP as described in [RFC3036] and [P2MP-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]) 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. Yasukawa and Farrel Page 16 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 - The definition of a new status code for use on an advisory Notification message as follows: Status Code E Status Data Suggested Label not/ x TBD Accepted 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 bit is set and the F bit is 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 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|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. 6.3. Comparison with Previous LDP Mechanisms - Upstream label suggestion does not require a change to the MPLS architecture. Labels are allocated and advertised by the downstream LSR. - Despite the fact that all labels are downstream allocated, it may be necessary to distinguish between multicast and unicast labels using a new layer 2 Ethertype so that a downstream LSR that does not support these procedures can tell that it should ignore a labeled packet on a multi-cast link. - Per-neighbor label spaces may be used to differentiate LSPs using labels allocated by different upstream neighbors. - The semantics and direction of flow of the LDP messages are retained and the LDP state machine may be preserved with only very minor changes. - A new message exchange is required over the existing LDP procedures. The message exchange for Downstream Unsolicited With Suggestion label distribution is shown in the figure below. It should be contrasted with Downstream Unsolicited label distribution where only the third message is used, and Downstream On-Demand label distribution where the second and third messages are used. Yasukawa and Farrel Page 17 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 Upstream LSR Downstream LSR | | | LabelMapping (special label) | (request a suggestion) |<------------------------------| | | | LabelRequest (Suggested Label)| (make a suggestion) |------------------------------>| | | | LabelMapping (label) | (advertise a label) |<------------------------------| 6.4. Applicability 6.4.1. P2MP TE Tunnels The technique of upstream label suggestion is applicable to the use of multicast LDP over P2MP TE Tunnels. In this case the upstream LSR is the root of the tunnel, and the downstream LSRs are the leaves of the tunnel. The root must have a targeted LDP session with each of the leaves of the tunnel which means that the root must know about each of the leaves, but this is normal for P2MP MPLS-TE tunnels. Each leaf may be the leaf of multiple tunnels from the same root. In this case, it is not necessary for the leaf to maintain a separate label space for each tunnel as the upstream neighbor is the same in each case. An alternative implementation would be to treat each tunnel as an interface and to manage labels per interface. This might give better scaling properties where very many multicast LDP flows are aggregated onto each tunnel, but would, however, require a separate LDP session per tunnel which might negate any scaling benefits. Each leaf may also be the leaf of multiple tunnels from different roots. In this case, each root is a different upstream neighbor and its labels may be managed from separate label spaces. As described for upstream label allocation, the P2MP TE LSPs used to carry multicast LDP LSPs may be dynamically established or pre-provisioned. The trigger for selection of a tunnel or dynamic establishment of a new MPLS TE LSP is the receipt at the upstream LSR of a targeted LabelMapping message requesting an upstream label suggestion for a new multicast LDP LSP. The same issue about the pre-knowledge of leaves exists and can be approached in the same way as described in section 5.3.1. Yasukawa and Farrel Page 18 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 6.4.2. Multi-Access Links Upstream label suggestion is also applicable to use on multi-access links. In this case, the upstream LSR is just one hop away from the downstream LSRs across the multi-access link. The upstream LSR has a normal LDP session with each of the downstream LSRs. Each station on the multi-access link may act as an upstream LSR for one or more multicast LSPs, and each may be a downstream LSR in one or more multicast LSPs. 6.4.3. Mixing Suggestion-Capable and Non-Suggestion Capable LSRs It is possible that an upstream LSR will have LDP sessions with downstream LSRs some of which are capable of supporting upstream label suggestion, and some of which are not. On a multi-access link this does not cause any problems. The downstream LSRs that want to use upstream label suggestion will request its use, while the others will use existing [RFC3036] behavior. In this way packets are duplicated on the link only for those downstream LSRs that cannot handle upstream suggested labels. Note, however, that because of the nature of the multi-access link, a downstream LSR that is not capable of handling upstream suggested labels will still receive packets from the upstream LSR labeled with the suggested label if it is used for other downstream LSRs. This can be overcome either by establishing specific broadcast groups for the suggestion-capable LSRs within the layer 2 technology, or by identifying the packets that carry these labels through a new Ethertype as for upstream allocated labels described in section 5. P2MP TE tunnels have the same issue as described for upstream allocated labels in section 5.3.3. That is, only a single label can be used for the multicast LDP traffic for a given flow when it is carried in the tunnel. The solutions are as described in section 5.3.3. 6.5. Issues and Open Questions As with upstream label allocation, several questions remain unanswered in the work on upstream label suggestion to date. Some of these questions are common with upstream label allocation because the techniques have some elements in common. The inclusion of these questions here does not imply a criticism of this technique, but is provided to help complete the analysis of this mechanism and to compare it to others. Yasukawa and Farrel Page 19 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 1. How is the label space (upstream neighbor) identified within the forwarding plane? The issue here is the same as for upstream label allocation (section 5.4, issue 1), but does not necessarily arise at all in upstream label suggestion. That is, although the labels are suggested on a per-neighbor basis, they are actually allocated by the downstream LSR. Thus the downstream LSR can choose to maintain per-interface or even global label spaces. In this case it is neither necessary to identify that the label belongs to a per-neighbor label space (using a new Ethertype) nor to identify the neighbor itself. There are obvious trade-offs to not using per-neighbor label spaces that manifest themselves in the potential for more packet duplication, more "label negotiation" during LSP establishment, and increased configuration. 2. How do label stacks work? As commented in the previous issue, labels are allocated by the downstream LSR and may be taken from per-interface or global label spaces (that is, not from per-neighbor label spaces). This means that there is no requirement to identify that the label belongs to a per-neighbor label space nor to identify the neighbor. This makes label stacking operate as normal. 3. How does Fast Re-Route work? More text is required to describe FRR, but because the labels are allocated by the downstream LSRs, this is probably relatively simple to achieve. 4. What are the procedures if a downstream LSR rejects an upstream suggested label? These procedures are described in section 6.1. 5. How is label contention handled? Upstream label allocation with per-root-neighbor label space resolves label contention by forcing coordination through the upstream LSR. Upstream label suggestion avoids certain issues with upstream label allocation, but the price is that 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 LSP's leaves cannot utilize the suggested label. In order to understand the scope of this issue it is necessary to examine the circumstances under which it can arise. Yasukawa and Farrel Page 20 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 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 TBD, but it should be noted that GMPLS signaling [RFC3473] contains mechanisms for label set negotiation and indication of acceptable label sets. 7. 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 is applicable to the transport of a multicast LDP 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 Yasukawa and Farrel Page 21 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 segments may be stitched to the P2MP TE LSP at the edges of the network. By way of illustration, the figure in section 2 may be used. Recall that 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 D, E, and G. Modifications to existing operational and signaling procedures are required as described below. 7.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 LDP LSP as necessary. 7.1.1. Dynamic Establishment and Maintenance of P2MP TE LSP Consider the first receiver wishing to join a multicast LDP LSP. It advertises its availability and a label using the mechanisms described in [P2MP-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 TE LSP, in our example, LSR A. LSR E, therefore, establishes a targeted LDP session with LSR A and advertises the multicast FEC 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 TE LSP has been fully established, it continues the multicast LDP advertisement upstream, and stitches the LDP multicast LSP to the P2MP TE LSP. 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 Yasukawa and Farrel Page 22 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 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 a multicast LDP 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 session 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. 7.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: all that is required is that the LSPs should be stitched. Note that care is needed 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 scope 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 protocol procedures. Again, the root of the P2MP TE LSP will need to take care when processing a received LabelWithdraw since it SHOULD only prune those leaves that were added dynamically. Yasukawa and Farrel Page 23 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 7.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. This issue should be compared with the similar issue expressed in [STITCHING] and may be solved by allowing the downstream LSR (the leaf) to proceed with LDP label allocation and advertisement as normal, and having the upstream LSR (the root) ignore the advertised label. The details of this mechanism are to be completed depending on the developments of [P2MP-LDP] and [STITCHING]. - 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]. Note that as an alternative, the S2L SUB-LSP Objects [P2MP-RSVP] could be defined to allow TLVs. The required information could then be included in a TLV in this object. 7.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, but aggregation is also one of the objectives identified in section 2. 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. Yasukawa and Farrel Page 24 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 Note that in many circumstances the choice of a suitable P2MP TE LSP to carry multiple multicast LDP LSPs may be ambiguous because each multicast LDP LSP may have a different set of receivers requiring different leaves for the P2MP TE LSP. In this case a 1:1 relationship between P2MP TE LSP and LDP multicast LSP may not be considered an impediment. 7.3.1. Applicability to Multi-Access Links The stitching solution is not immediately applicable to multi-access links because it depends on the existence of a transit P2MP TE LSP. It is possible to consider installing P2MP TE LSPs on the multi-access link however, this will simply push all of the questions and issues into the signaling procedures for that LSP. For example, the P2MP TE LSP will need to be established so that only a single packet is sent on the multi-access link and this will require coordination of labels within the signaling used for the P2MP TE LSP (RSVP-TE). [UPSTREAM] starts to suggest some appropriate signaling extensions for RSVP-TE on multi-access links for upstream label allocation, and the label suggestion techniques of [RFC3473] might be used to offer upstream label suggestion. The only obvious advantage to this approach would be if it proved to be necessary to extend only one protocol for upstream label allocation/suggestion. That is, if stitching was selected as the only solution for carrying multicast LDP over P2MP TE LSPs and multi-access links, and if RSVP-TE needed anyway to be extended to establish P2MP TE LSPs over multi-access links. 8. Security Considerations TBD This section will need to evaluate the comparative security issues for all three proposed solutions. 9. 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. 10. Acknowledgements The authors would like to thank Dean Cheng, Ina Minei and Eric Rosen for their comments on this document. Yasukawa and Farrel Page 25 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 11. 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. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [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 and Multipoint-to-Multipoint Label Switched Paths", draft-minei-wijnands-mpls-ldp-p2mp, work in progress. [STITCHING] Ayyangar, A., and Vasseur, J-P., "LSP Stitching with Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching, work in progress. Yasukawa and Farrel Page 26 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 [UPSTREAM] Aggarwal, R., and Le Roux, J-L., "MPLS Upstream Label Assignment for LDP", draft-raggarwa-mpls-ldp-upstream work in progress. [UPSTREAM-ARCH] Aggarwal, R., Rekhter, Y., and Rosen, E., "MPLS Upstream Label Assignment and Context Specific Label Space", draft-raggarwa-mpls-upstream-label, work in progress. 13. 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. [P2MP-LDP-REQ] J-L. Le Roux et al,. "Requirements for point-to-multipoint extensions to the Label Distribution Protocol", draft-leroux-mpls-mp-ldp-reqs work in progress. 14. 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 27 draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt October 2005 15. 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 28