Internet DRAFT - draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps

draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps



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