Network Working Group                                    Seisho Yasukawa
Internet Draft                                                       NTT
Category: Standards Track
Expires: March 2007                                       September 2006

       Supporting Multipoint-to-Point Label Switched Paths in
         Multiprotocol Label Switching Traffic Engineering


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 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

   The list of Internet-Draft Shadow Directories can be accessed at


   Traffic engineered Multiprotocol Label Switching (MPLS-TE) uses
   Resource Reservation Protocol traffic engineering extensions
   (RSVP-TE) as the signaling protocol to establish Label Switched Paths
   (LSPs). Although the Resource Reservation Protocol (RSVP) on which
   RSVP-TE is built supports the convergence of traffic flows toward a
   common destination, this concept has not been exploited in MPLS-TE
   which has been limited to point-to-point (P2P) and
   point-to-multipoint (P2MP) LSPs.

   This document describes extensions to RSVP-TE procedures and protocol
   elements to support multipoint-to-point (MP2P) LSPs.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Yasukawa                     Expires March 2006                 [Page 1]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006


   1. Introduction ................................................... 3
   2. Description of MP2P MPLS-TE LSPs ............................... 3
   2.1 Basic Requirements ............................................ 4
   2.1.1 Non-Requirements ............................................ 6
   2.2 Requirement for new Procedures and Extensions ................. 6
   3. Procedures for Signaling MP2P MPLS-TE LSPs ..................... 7
   3.1 Initial P2P LSP Establishment ................................. 7
   3.2 Subsequent LSPs ............................................... 7
   3.3 Processing at Merge Points .................................... 8
   3.3.1 Determining that Merging is Allowed ......................... 8
   3.3.2 Wildcard Filter Style ....................................... 8
   3.3.3 Fixed Filter Style .......................................... 9
   3.3.4 Shared Explicit Style ...................................... 10
   3.3.5 Record Route Processing on Merged Path Messages ............ 11
   3.4 Processing Downstream of a Merge Point ....................... 11
   3.5 Processing at Egress LSRs .................................... 12
   3.6 Resv Processing at Merge Points .............................. 12
   3.7 LSP Teardown ................................................. 12
   3.8 Make-Before-Break Support .................................... 12
   4. Protocol Extensions ........................................... 13
   4.1 Allowing MP2P LSP Merging .................................... 13
   4.2 Message Formats .............................................. 13
   4.2.1 Path Message ............................................... 13
   4.2.2 PathErr Message ............................................ 14
   5. Backward Compatibility ........................................ 14
   5.1 Legacy LSRs .................................................. 15
   5.2 Support of P2P and P2MP LSPs through an MP2P-enabled network . 15
   6. Path Computation Considerations ............................... 15
   7. Manageability Considerations .................................. 15
   7.1 MIB Modules .................................................. 15
   7.2 Operations and Management .................................... 16
   8. Security Considerations ....................................... 16
   9. IANA Considerations ........................................... 16
   10. Acknowledgments .............................................. 16
   11. References ................................................... 16
   11.1 Normative References ........................................ 16
   11.2 Informative References ...................................... 17
   12. Author's Address ............................................. 18
   13. Intellectual Property Statement .............................. 18

Yasukawa                     Expires March 2006                 [Page 2]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

1. Introduction

   The architecture for Multiprotocol Label Switching (MPLS) is
   described in [RFC3031]. The signaling for Label Switched Paths (LSPs)
   in MPLS traffic engineering (MPLS-TE) networks is achieved through
   specific extensions to the Resource Reservation Protocol (RSVP)
   defined in [RFC3209]. Although RSVP includes support for the
   convergence of traffic flows toward a common destination, the traffic
   engineering (TE) extensions to RSVP (RSVP-TE) do not leverage this
   fact, and [RFC3209] only includes support for point-to-point (P2P)

   Additional extensions to RSVP-TE have been defined to support
   point-to-multipoint (P2MP) LSPs in [P2MP-RSVP].

   Multipoint-to-point (MP2P) LSP tunnels offer certain benefits in a
   core MPLS network. For example, they reduce the amount of LSP state
   that protocol implementations must maintain within the network, and
   they may simplify the accounting and prioritization of traffic within
   individual routers.

   This document investigates how MP2P LSPs might be established using
   the protocol elements and procedures inherent in RSVP and RSVP-TE,
   and describes new procedures and protocol elements where necessary.

2. Description of MP2P MPLS-TE LSPs

   MP2P MPLS-TE LSPs are transport tunnels within a core MPLS-TE
   network. An MP2P MPLS-TE LSP delivers traffic from multiple ingress
   Label Switching Routers (LSRs) to a single common egress LSR.

   Identification of the traffic carried by the tunnel with its
   originating ingress LSR is not within the scope of the MP2P LSP. Thus
   the MP2P LSP must be treated as an edge-to-edge tunnel much in the
   manner of hierarchical P2P LSPs described in [RFC4206]. For example,
   directed signaling can be used to exchange labels between egress and
   ingresses so that traffic from each ingress will use a different
   label on the label stack beneath the label used for the MP2P tunnel.

   LSP merging within the network can be carried out in an ad hoc way on
   any LSPs that are allowed to be merged. The judgment of whether two
   LSPs can be merged is dependent on:
   - are the LSPs to the same destination?
   - do the ingresses allow these LSPs to be merged?
   - are the explicit routes downstream of the merge point consistent
     with merging?
   - is the merge point capable of performing merging?
   - are the bandwidth implications of merging supported by the
     downstream network?

Yasukawa                     Expires March 2006                 [Page 3]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

   The ad hoc way of MP2P LSP establishment means that upstream segments
   of the MP2P tree are added when new ingress-to-egress LSPs are
   signaled and coincide with (discover) other existing LSPs to the same
   egress that can be merged according to the above criterions.

   Two models to manage the bandwidth of merged LSPs may be considered.

   - The new upstream segment may be spliced into the MP2P LSP and the
     additional bandwidth required for the traffic from the new ingress
     is added to the bandwidth request for the downstream segment. This
     is most appropriate for MP2P tunnels carrying unassociated traffic
     from the ingress LSRs.

   - The new upstream segment may be spliced into the MP2P LSP and use
     (share) the existing bandwidth on the downstream segment. This may
     be appropriate for certain specific applications where individual
     ingresses send data one at a time (for example, voice

   Additionally, two models of notification to the egress of merging may
   be considered.

   - When a new upstream segment is spliced into an MP2P LSP the new
     ingress LSR is reported to the egress so that it knows all of the
     ingress LSRs on the MP2P tree. This is suitable to some uses of the
     MP2P LSP as a tunnel where forwarding adjacencies (FAs, see
     [RFC4206]) are managed between the end points.

   - When a new upstream segment is spliced into an MP2P LSP no further
     downstream signaling is required, the egress is not informed of the
     addition of a new ingress, and the ingress is told that it is
     connected to the egress. This may be particularly suited to
     bandwidth sharing applications.

   The combination of these two sets of models gives four options for
   signaling MP2P LSPs downstream of a merge point.

2.1 Basic Requirements

   This section lists the basic functional requirements that the
   signaling of MP2P MPLS-TE LSPs must support.

   a. Control of merging function
      The ingress LSR MUST be able to specify through signaling whether
      an LSP may be merged into an MP2P LSP or not. This can currently
      be achieved using the Session object defined in [RFC3209].

   b. Identification of LSPs that can be merged.
      Transit LSRs that are capable of merging LSPs into the MP2P tree
      MUST be able to distinguish which LSPs can be merged and which are

Yasukawa                     Expires March 2006                 [Page 4]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

      to remain distinct. The merging rules of [RFC2205] allow merging
      based on an identical Session object, and this rule can be applied
      with the Session object as modified by [RFC3209].

   c. Resource sharing downstream of merge points
      It is a requirement that the single LSP segment downstream of a
      merge point MUST have sufficient bandwidth allocated to support
      all traffic from the LSP segments upstream of the merge point, and
      that that traffic MUST be able to share the bandwidth on the
      downstream segment.

      This requirement can be met using the features of RSVP [RFC2205]
      where TSpecs for different senders are forwarded to the egress in
      separate Path messages and combined into a single Flowspec that is
      returned on a Resv message.

   d. Explicit route control
      It is a requirement that the ingress LSR MUST be able to control
      the route of the LSP from source to destination. This feature is
      provided by the Explicit Route object of [RFC3209] in conjunction
      with merging rules described in this document.

   e. Label allocation
      Label allocation MUST be supported with a single label on a merged
      downstream segment and individual labels on upstream segments. No
      changes to [RFC3209] are required for this function except to
      clarify how labels are carried on Resv messages where multiple
      FilterSpecs are used, and to clarify how Label Forwarding
      Information Bases (LFIBs) are programmed at merge points.

   f. LSP identification
      Each LSP MUST be uniquely identifiable within the network.
      Further, in order to support diagnostics and OAM, a single
      identifier MUST be used on the LSP for the whole of its path
      between any ingress and the egress. Additionally, a single
      identifier SHOULD be used for the MP2P across the whole of the LSP

   g. Coordination between ingress LSRs
      MP2P operation MUST be possible with minimal or zero coordination
      between ingress LSRs. It is not acceptable to require
      configuration at each ingress LSR in order to specify which other
      ingress LSRs may join the same MP2P LSP (for example, through
      identifying a group). It is acceptable to require:

      - Specific configuration for an individual LSP that it will
        support MP2P merging (see requirement a.)

      - Network-wide configuration of identifiers of "classes" of LSP
        that may be merged.

Yasukawa                     Expires March 2006                 [Page 5]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

      This requirement is hard to reconcile with previous requirements
      and with the assumed use of [RFC2205] and [RFC3209] procedures. In
      order to control merging, the Session objects of all upstream
      segments are required to be the same [RFC2205], but this means
      that the Tunnel ID and Extended Tunnel ID must be coordinated.

      It might be possible to reserve certain Tunnel ID and Extended
      Tunnel ID values to indicate MP2P merging, but this seems
      impractical and unscalable. The alternative (adopted in this
      document) is to define different rules for when LSP merging is
      allowed, and so the resolution of requirement a. as stated above
      is discarded.

   h. Identification of senders at egress.
      It MUST be possible for the egress LSR to determine all of the
      ingress LSRs attached to the MP2P LSP. This requires that
      signaling information from each ingress is passed to the egress
      either in its own Path message or through some form of merging of
      signaling information into a single message.

   i. Route recording
      It MUST be possible to record the path followed by the MP2P LSP
      and pass this information to the end points. The ingress only
      requires to know the path from the ingress to the egress. The
      egress requires to know the path from each ingress to the egress.

      The route reported to the ingress SHOULD indicate which LSRs on
      the route are currently acting as MP2P merge points.

      Some form of information aggregation technique SHOULD be used in
      reporting the recorded route to the egress so that hops that are
      common in the tree form multiple ingress LSRs (that is, hops
      downstream of the merge point) SHOULD NOT be repeated in the
      information present in the signaling message (Path message).

2.1.1 Non-Requirements

   No ingress is required to know of the existence of other ingresses in
   the MP2P LSP.

2.2 Requirement for new Procedures and Extensions

   Section 2.1 summarizes the signaling requirements and shows how many
   of the requirements can be met using the merging techniques of
   [RFC2205] and the LSP identification techniques of [RFC3209]. But the
   last requirements (g, h and i) cannot be met using these techniques.
   Thus new procedures and extensions are needed.

   The remainder of this document introduces new procedures and
   extensions to support signaling MP2P LSPs.

Yasukawa                     Expires March 2006                 [Page 6]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

3. Procedures for Signaling MP2P MPLS-TE LSPs

   The procedures described here are modeled on the reservation styles
   described in [RFC2205]. Further, many ideas are taken from the way
   that FlowSpecs and FilterSpecs may be combined on Resv messages in
   [RFC2205] in recognition that the Resv message in [RFC2205] is
   creating an MP2P flow tree.

   Additions are made to allow control of this MP2P behavior on the Path
   message. The advantage of this over the [RFC2205] techniques is that
   merging is explicitly announced and is the responsibility of the
   merge point not of the egress.

3.1 Initial P2P LSP Establishment

   The initial LSP is signaled as a normal point-to-point LSP would be.
   The ingress LSP cannot know whether future upstream segments will be
   merged into this LSP or not.

   However, the LSP is flagged by the ingress to say whether MP2P
   merging is allowed using a new flag in the LSP_ATTRIBUTES object in
   the Path message. If this flag is not set or is absent, the LSP is
   treated as a normal P2P LSP.

   If MP2P merging is allowed by the ingress, the Path message MUST also
   include the Style object. The Style object was previously only
   allowed on a Resv message, [RFC2205]. The Style object directs the
   merging procedure that is performed at any merge point as described
   in section 3.3.

   When the ingress LSR allows MP2P merging it SHOULD set the Extended
   Tunnel ID in the Session object to a well-known value. The value of
   zero SHOULD be used to allow general merging with other LSPs. Other
   non-zero values MAY be defined according to administrative policy for
   the network to restrict the LSPs that may be merged, perhaps
   according to service or application classification. It is RECOMMENDED
   that only values that do not match valid IP addresses are used for
   this function since [RFC3209] suggests the use of the sender's IP
   address in this field for P2P LSPs.

   Other procedures and encodings are unchanged from [RFC3209].

3.2 Subsequent LSPs

   Subsequent LSPs are actually identical to initial LSPs described in
   the previous section. The ingress LSR is not aware whether other LSPs
   already exist and MP2P merging will happen. Therefore the ingress LSR
   builds its Path message as already described.

Yasukawa                     Expires March 2006                 [Page 7]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

3.3 Processing at Merge Points

   The main difference for MP2P LSP support takes place at the merge
   points. Much of the processing depends on the setting of the Style
   object carried in the received Path messages.

3.3.1 Determining that Merging is Allowed

   When an LSR receives a Path message with the MP2P flag set indicating
   that MP2P merging is allowed for the LSP, and if the LSR is capable
   of supporting MP2P merging it performs the following checks to
   determine an existing LSP with which to merge. The order of the
   checks is implementation-specific.

   - Search all LSP state for LSPs that are allowed to be merged (that
     is, that were signaled with the MP2P flag set).

   - Find any LSPs that have a common destination set in the Session
     object and that have the same Extended Tunnel ID in the Session
     object. Note that the Tunnel ID, Sender and LSP ID do not form part
     of this check.

   - Select those LSPs that have compatible downstream explicit routes.
     In this context, an explicit route is compatible if the path of the
     existing LSP satisfies the Explicit Route object (ERO) carried in
     the new Path message.

   - Select those LSPs that were signaled with the same value of the
     Style object.

   - Select those LSPs for which MP2P merging is allowed according to
     local policy (possibly using the contents of the Policy object
     signaled in the received Path messages). This choice MAY include
     consideration of the hardware capabilities of the merging LSR.

   - If more than one LSP is still a candidate for merging select the
     best LSP to merge according to local policy.

   If no merge candidate is found the LSR processes the Path message as
   normal according to [RFC3209].

   If an LSP is found, merging proceeds according to the reservation
   style carried in the Style object as follows.

3.3.2 Wildcard Filter Style

   In [RFC2205] the Wildcard Filter (WF) reservation style allows
   sharing between all traffic in the same session, that is, to the same

Yasukawa                     Expires March 2006                 [Page 8]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

   Just as in [RFC2205], the WF M2MP LSP may be thought of as a shared
   "pipe", whose "size" is the largest of the resource requests,
   independent of the number of senders using it. In other words, a WF
   style indicates that resource sharing occurs downstream of the merge
   point and this style is applicable to resource sharing applications
   such as voice-conferencing.

   A merge LSR that receives a Path message for a second LSP carries out
   the following processing.

   - If the new LSP requests bandwidth less than or equal to the
     bandwidth already allocated downstream for the existing LSP, the
     merge point immediately generates a Resv for the new LSP, allocates
     a label on the new upstream segment, and sends the Resv upstream
     following normal rules from [RFC3209].

     The merge LSR installs an entry in the LFIB mapping the new label
     on the new upstream interface, to the existing label on the
     downstream interface for the MP2P LSP so that the new LSP is
     spliced into the MP2P LSP.

   - If the new LSP requests bandwidth greater than the bandwidth
     already allocated downstream for the existing LSP, the merge LSR
     sends a trigger Path message downstream with a TSpec that requests
     increased bandwidth. If a Resv message is later received indicating
     that the required bandwidth has been allocated, the merge LSR
     builds and sends a Resv upstream for the new LSP segment only (no
     new Resv is sent upstream for the previously existing LSP
     segments). If the requested bandwidth is not made available, the
     merge LSR sends a PathErr message upstream on the new LSP segment
     just as it would if normal LSP setup had failed owing to lack of
     resources [RFC3209].

   In this mode of operation, the egress does not become aware when new
   ingress LSRs are spliced into the MP2P tree.

3.3.3 Fixed Filter Style

   In [RFC2205] the Fixed Filter (FF) style implies distinct
   reservations for each flow in the session.

   For MP2P LSPs this means that common labels are used on the shared
   downstream segments, but a separate pool of resource is allocated for
   each ingress LSR (sender) that shares the MP2P tree.

   The consequence is that each LSP (that is, each LSP from each
   ingress) must be signaled all the way to the egress carrying a
   distinct LSP identifier and TSpec. Although a possible approach is to
   send a separate Path message for each such LSP (which would be the
   technique used in [RFC2205]) this cannot be done because it would

Yasukawa                     Expires March 2006                 [Page 9]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

   leave the choice of MP2P merging to the egress LSR. This situation is
   OK in [RFC2205] where all routers are capable of merging flows, but
   is not suitable in MP2P MPLS-TE because the merge node needs control
   of whether merging is performed.

   Therefore, the solution is to merge the Path messages. The Path
   message for the first LSP is processed as normal (see section 3.1),
   but once merging has been chosen, the incoming Path message for the
   second LSP is merged, and the trigger Path message sent downstream
   contains information about both senders.

   The mechanism used to achieve this mirrors the information that will
   be carried on the Resv. An <FF sender descriptor list> is used to
   provide a list of Sender Template objects each of which is
   accompanied by a TSpec. AdSpec and Record Route objects may also be
   present. The <FF sender descriptor list> MUST NOT be present unless
   the Style object is present and contains the FF setting. However, the
   observant reader will note that an <FF sender descriptor list> with
   only one element is identical to the <sender descriptor> defined in
   [RFC3209] and used for P2P signaling.

   Each <sender descriptor> in the <FF sender descriptor> is copied from
   the <sender descriptor> on a received Path message. Thus all
   information from received Path messages is conveyed to the egress

3.3.4 Shared Explicit Style

   [RFC2205] describes the Shared Explicit (SE) style as creating a
   single reservation that is shared by selected upstream senders.
   Unlike the WF style, the SE style requires that the senders that
   share the style are explicitly identified, and so each LSP that is
   joined to the MP2P LSP needs to be signaled to the egress.

   The solution is also modeled on the SE signaling used in the Resv
   message in [RFC2205]. An <SE sender descriptor list> is used to
   provide a list of Sender Template objects that are associated with a
   single TSpec. AdSpec and Record Route objects may also be present.
   The <SE sender descriptor list> MUST NOT be present unless the Style
   object is present and contains the SE setting. However, the observant
   reader will note that an <SE sender descriptor list> with only one
   element is identical to the <sender descriptor> defined in [RFC3209]
   and used for P2P signaling.

   Each Sender Template and any Record Route or AdSpec object in the <SE
   sender descriptor> is copied from the a received Path message. Thus
   all information from received Path messages is conveyed to the egress
   LSR. But the traffic parameters in the Sender TSpec object are summed
   to ensure that sufficient bandwidth is allocated on the downstream

Yasukawa                     Expires March 2006                [Page 10]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

3.3.5 Record Route Processing on Merged Path Messages

   The route of an LSP can be recorded in a Record Route object (RRO)
   included in a Path message [RFC3209]. There is no change to this
   procedure up to the merge point for two LSPs.

   Downstream of the merge point, the Path message can include multiple
   RROs: one for each Sender Template object. The presence rules for
   these RROs is that they exist in the <sender descriptor> for a merged
   LSP in a Path message downstream of the merge point if and only if
   the RRO existed in the Path message for the LSP upstream of the merge

   Note that continuing to record the route of an LSP in all RROs in a
   Path message would result in duplicate information that might make
   the Path message too large for convenient processing. In order to
   avoid such duplicate information the following three rules MUST be

   - When creating a <sender descriptor list> for transmission in a Path
     message to a downstream LSR the merge LSR MUST include an RRO in a
     <sender descriptor> if there is one in the corresponding <sender
     descriptor> in the Path message received from upstream.

   - When creating a <sender descriptor list> for transmission in a Path
     message to a downstream LSR, if any <sender descriptor> includes an
     RRO the merge LSR MUST ensure that the first <sender descriptor>
     contains an RRO. This MUST be achieved by appropriate ordering of
     <sender descriptor> items and MUST NOT be achieved by inserting an
     RRO into a <sender descriptor> that would not otherwise include an

   - When adding route record information to a Path message, an LSR MUST
     add the information only to the first RRO in the Path message.

   Thus RROs in Path messages start at ingress LSRs and end at merge
   LSRs, except for the first RRO in the Path message that ends at the
   egress LSR.

3.4 Processing Downstream of a Merge Point

   No special processing for Path messages is necessary at an LSR
   downstream of a merge LSR except for the following points.

   - RROs MUST be handled as described in the previous section.

   - Resources SHOULD be checked based on the contents of the Style

Yasukawa                     Expires March 2006                [Page 11]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

3.5 Processing at Egress LSRs

   Egress LSRs are responsible for converting TSpec objects on Path
   messages into FlowSpec objects on Resv messages. The rules for doing
   this are inherited from [RFC2205] and [RFC3209] applying the
   information received in Path the messages including the value set in
   the Style object.

3.6 Resv Processing at Merge Points

   Resv messages need careful handling at merge points. The contents of
   the Resv needs to be split and sent upstream in separate Resv
   messages according to the Path messages that were received.

   The <flow descriptor list> on the Resv is simply split according to
   the <sender descriptors> received on the Path messages. Where
   bandwidth is shared on downstream links, the merge LSR makes
   appropriate decisions for how much bandwidth to allocate on the
   upstream links according to the TSpecs received in the Path messages.
   Where bandwidth is allocated per sender, this is simply copied from
   the received Resv to the outgoing Resvs.

   Note that an RRO MUST NOT be included in a Resv sent upstream from a
   merge LSR unless an RRO was received in the corresponding Path

3.7 LSP Teardown

   When an ingress LSR decides to tear down an LSP it sends a PathTear
   message. This message is propagated as per [RFC3209] until it reaches
   a merge LSR.

   - If the PathTear is removing the last upstream segment then this is
     not really a merge LSR, and the PathTear MUST be forwarded toward
     the egress as normal.

   - If the LSP uses the WF style, the PathTear MUST be terminated at
     the merge LSR. If the result of removing the associated sender is a
     reduction in the amount of required resource on the downstream LSP,
     the merge LSR MAY send a trigger Path message with a new TSpec, but
     MAY retain the downstream bandwidth according to local policy.

   - If the LSP uses the FF or SE style, the PathTear MUST be terminated
     at the merge LSR and a trigger Path message MUST be sent downstream
     with the associated <sender descriptor> removed.

3.8 Make-Before-Break Support

   Make-before-break is an important aspect of MPLS-TE that allows LSPs
   to be re-routed in a "hitless" way.

Yasukawa                     Expires March 2006                [Page 12]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

   The integration of make-before-break with MP2P LSPs is for future

4. Protocol Extensions

   This section describes the protocol extensions and changes to message
   encodings required to support the function described in section 3.

4.1 Allowing MP2P LSP Merging

   An ingress LSR may allow M2MP LSP merging by setting the "MP2P Merge
   Allowed" flag at bit number xx (TBD by IANA) in the LSP Attributes
   TLV carried in the LSP_ATTRIBUTES object [RFC4420] in the Path
   message that it sends for this LSP. The LSP_ATTRIBUTES object is used
   rather than the LSP_REQUIRED_ATTRIBUTES object because transit LSRs
   that do not support MP2P LSP merging are not required to take any

   An LSR that recognizes the LSP_ATTRIBUTES object, but does not
   recognize the MP2P Merge Allowed flag will ignore the flag according
   to the processing rules in [RFC4420], and MUST forward the flag
   unmodified in any Path message that it sends for this LSP. An LSR
   that recognizes the LSP_ATTRIBUTES object and the MP2P Merge Allowed
   flag, but which does not support MP2P LSP merging or does not wish to
   support MP2P merging for the signaled LSP MUST forward the flag
   unmodified in any Path message that it sends for this LSP.

4.2 Message Formats

   As described in section 3, some changes are required to the existing
   RSVP-TE message formats. These are shown in the sections that follow.

   The following messages are not changed by this document.
   - PathTear
   - Resv
   - ResvTear
   - ResvErr
   - ResvConf

4.2.1 Path Message

   The Path message is extended by the optional inclusion of the Style
   object. If this object is present the <sender descriptor> is replaced
   by a <sender descriptor list>.

Yasukawa                     Expires March 2006                [Page 13]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

   <Path Message> ::=   <Common Header> [ <INTEGRITY> ]
                        <SESSION> <RSVP_HOP>
                      [ <EXPLICIT_ROUTE> ]
                      [ <SESSION_ATTRIBUTE> ]
                      [ <LSP_ATTRIBUTES> ]
                      [ <POLICY_DATA> ... ]
                        <sender descriptor>
                        | <STYLE> <sender descriptor list>

   The new sender descriptor list is defined to mirror the Resv <flow
   descriptor list> as follows.

   <sender descriptor list> ::=   <WF sender descriptor list>
                                | <FF sender descriptor list>
                                | <SE sender descriptor>

   <WF sender descriptor list> ::= <sender descriptor>

   <FF sender descriptor list> ::=  <sender descriptor>
                   | <FF sender descriptor list> <sender descriptor>

   <SE sender descriptor list> ::= <sender descriptor>
                                   <SE sender list>

   <SE sender list> ::=   <SENDER_TEMPLATE>
                        [ <ADSPEC> ]
                        [ <RECORD_ROUTE> ]

   The definition of <sender descriptor> is found in [RFC3209].

4.2.2 PathErr Message

   The PathErr message is modified as follows.

   <PathErr message> ::=   <Common Header> [ <INTEGRITY> ]
                           <SESSION> <ERROR_SPEC>
                         [ <POLICY_DATA> ...]
                         [ <sender descriptor>
                           | <STYLE> <sender descriptor list>]

   <sender descriptor> and <sender descriptor list> are as previously

5. Backward Compatibility

   This section examines how MP2P support may co-exist with previous
   MPLS-TE function.

Yasukawa                     Expires March 2006                [Page 14]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

5.1 Legacy LSRs

   The presence of the Style object on a Path message will cause a
   legacy LSR to reject the message with a PathErr message containing an
   Error Code that indicates that an unsupported object was found.
   Therefore, in order to support MP2P LSPs it is necessary that all
   LSRs that may lie on the route of an MP2P LSP must be upgraded to
   support the procedures and protocol extensions described in this

   Where this is not practical, it is possible to consider establish FA
   LSPs [RFC4206] to tunnel past the legacy LSPs. This would probably
   require management coordination.

5.2 Support of P2P and P2MP LSPs through an MP2P-enabled network

   It is clearly a requirement that an MPLS-TE network that has been
   enabled for MP2P MUST continue to support P2P and P2MP TE LSPs.
   There is nothing in the procedures and extensions defined in this
   document that prevents that.

6. Path Computation Considerations

   An issue arises for path computation for MP2P LSPs. If this
   computation is performed on ingress LSRs using the Traffic
   Engineering Database (TED) built from information distributed by the
   Interior Gateway Protocols (IGPs) then the computation engine will
   not be aware of bandwidth sharing possibilities and will possibly
   exclude optimal paths assuming that bandwidth is not available. This
   problem only occurs where bandwidth sharing downstream of the merge
   points is desirable.

   In the case of this particular application it may be desirable to
   consider coordinated or centralized path computation such as might be
   performed by stateful PCE [RFC4655].

7. Manageability Considerations

7.1 MIB Modules

   The LSR MIB module [RFC3813] contains full support for many-to-one
   associations through the cross-connect table. No extensions are

   The MPLS TE MIB module [RFC3812] needs an applicability statement to
   show how a Path message that contains multiple senders may be mapped
   to entries in the MIB tables. However, no extensions to those MIB
   tables are required.

Yasukawa                     Expires March 2006                [Page 15]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

7.2 Operations and Management

   Operations and Management (OAM) tools are essential to the successful
   operation of MPLS networks. [RFC4378] provides a framework for OAM in
   MPLS networks, and this is applicable for MP2P MPLS-TE networks.
   [RFC4377] sets out requirements for OAM in MPLS networks, and those
   are applicable to MP2P MPLS-TE.

   It may be observed that the structure of an LSP in LDP is similar to
   that in MP2P MPLS-TE and so many of the same issues and solutions
   will apply.

8. Security Considerations

   MP2P LSPs open up new security concerns not raised in [RFC3209]. In
   particular, the WF style is vulnerable to an ingress being joined to
   an MP2P LSP without the knowledge of the egress LSR and being able to
   send data to the egress. The peer-level (neighbor) authentication
   supported by RSVP [RFC2205] becomes more important in this case.

   Otherwise, these extensions raise no security issues that are not
   covered [RFC3209].

9. IANA Considerations

   IANA is requested to assign a bit number for use by the "MP2P Merge
   Allowed" flag in the Attribute Flags TLV carried in the

   The interpretation of this flag should be tracked by IANA as follows.
   - It has meaning in the Attribute Flags TLV on a Path
   - It does not have meaning in the Attribute Flags TLV on a Resv
   - It does not have meaning in the RRO Attributes Subobject.

   See section 4.1 for a description of the use of this flag.

10. Acknowledgments

   The author thanks Adrian Farrel for useful conversations during the
   production of this document.

11. References

11.1 Normative References

   [RFC2119]    Bradner, S., "Key words for use in RFCs to indicate
                requirements levels", RFC 2119, March 1997.

Yasukawa                     Expires March 2006                [Page 16]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

   [RFC2205]    Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
                Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
                1, Functional Specification", RFC 2205, September 1997.

   [RFC3209]    Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
                and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
                Tunnels", RFC 3209, December 2001.

   [RFC4420]    Farrel, A., Papadimitriou, D., Vasseur, J.P., and
                Ayyangar, A., "Encoding of Attributes for Multiprotocol
                Label Switching (MPLS) Label Switched Path (LSP)
                Establishment Using Resource ReserVation
                Protocol-Traffic Engineering (RSVP-TE)", RFC 4420,
                February 2006.

11.2 Informative References

   [RFC3031]   Rosen, E., Viswanathan, A., and Callon, R.,
               "Multiprotocol Label Switching Architecture", RFC 3031,
               January 2001.

   [RFC3812]   Srinivasan, C., Viswanathan, A., and T. Nadeau,
               "Multiprotocol Label Switching (MPLS) Traffic Engineering
               (TE) Management Information Base (MIB)", RFC 3812, June

   [RFC3813]   Srinivasan, C., Viswanathan, A., and T. Nadeau,
               "Multiprotocol Label Switching (MPLS) Label Switching
               Router (LSR) Management Information Base (MIB)", RFC
               3813, June 2004.

   [RFC4206]   Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
               Hierarchy with Generalized Multi-Protocol Label Switching
               (GMPLS) Traffic Engineering (TE)", RFC 4206, October

   [RFC4377]   Nadeau, T., Morrow, M., Swallow, G., Allan, D., and
               Matsushima, S. "Operations and Management (OAM)
               Requirements for Multi-Protocol Label Switched (MPLS)
               Networks", RFC4377, February 2006.

   [RFC4378]   Allan, D., and Nadeau, T., "A Framework for
               Multi-Protocol Label Switching (MPLS) Operations and
               Management (OAM)", RFC4378, February 2006.

   [RFC4655]   Farrel, A., Vasseur, J.P., and Ash, G., "A Path
               Computation Element (PCE)-Based Architecture",
               RFC 4655, August 2006.

Yasukawa                     Expires March 2006                [Page 17]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

   [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.

12. Author's Address

   Seisho Yasukawa
   3-9-11 Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan

13. Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Yasukawa                     Expires March 2006                [Page 18]

draft-yasukawa-mpls-mp2p-rsvpte-01.txt                    September 2006

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.

Yasukawa                     Expires March 2006                [Page 19]