tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4875

 
 
 

Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)

Part 2 of 3, p. 16 to 35
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 16 
6.  Resv Message

6.1.  Resv Message Format

   The Resv message follows the [RFC3209] and [RFC3473] format:

   <Resv Message> ::=    <Common Header> [ <INTEGRITY> ]
                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
                         [ <MESSAGE_ID> ]
                         <SESSION> <RSVP_HOP>
                         <TIME_VALUES>
                         [ <RESV_CONFIRM> ]  [ <SCOPE> ]
                         [ <NOTIFY_REQUEST> ]
                         [ <ADMIN_STATUS> ]
                         [ <POLICY_DATA> ... ]
                         <STYLE> <flow descriptor list>

   <flow descriptor list> ::= <FF flow descriptor list>
                              | <SE flow descriptor>

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

   <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>

   <SE filter spec list> ::= <SE filter spec>
                            | <SE filter spec list> <SE filter spec>

   The FF flow descriptor and SE filter spec are modified as follows to
   identify the S2L sub-LSPs that they correspond to:

   <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
                            [ <RECORD_ROUTE> ]
                            [ <S2L sub-LSP flow descriptor list> ]

   <SE filter spec> ::=     <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
                            [ <S2L sub-LSP flow descriptor list> ]

   <S2L sub-LSP flow descriptor list> ::=
                               <S2L sub-LSP flow descriptor>
                               [ <S2L sub-LSP flow descriptor list> ]

   <S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
                                     [ <P2MP_SECONDARY_RECORD_ROUTE> ]

   FILTER_SPEC is defined in section 19.4.

Top      Up      ToC       Page 17 
   The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP
   descriptor in section 4.1 with the difference that a
   P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
   SECONDARY_EXPLICIT_ROUTE object.  The P2MP_SECONDARY_RECORD_ROUTE
   objects follow the same compression mechanism as the P2MP
   SECONDARY_EXPLICIT_ROUTE objects.  Note that a Resv message can
   signal multiple S2L sub-LSPs that may belong to the same FILTER_SPEC
   object or different FILTER_SPEC objects.  The same label SHOULD be
   allocated if the <Sender Address, LSP-ID> fields of the FILTER_SPEC
   object are the same.

   However different labels MUST be allocated if the <Sender Address,
   LSP-ID> of the FILTER_SPEC object is different, as that implies that
   the FILTER_SPEC refers to a different P2MP LSP.

6.2.  Resv Message Processing

   The egress LSR MUST follow normal RSVP procedures while originating a
   Resv message.  The format of Resv messages is as defined in section
   6.1.  As usual, the Resv message carries the label allocated by the
   egress LSR.

   A node upstream of the egress node MUST allocate its own label and
   pass it upstream in the Resv message.  The node MAY combine multiple
   flow descriptors, from different Resv messages received from
   downstream, in one Resv message sent upstream.  A Resv message MUST
   NOT be sent upstream until at least one Resv message has been
   received from a downstream neighbor.  When the integrity bit is set
   in the LSP_REQUIRED_ATTRIBUTE object, Resv message MUST NOT be sent
   upstream until all Resv messages have been received from the
   downstream neighbors.

   Each Fixed-Filter (FF) flow descriptor or Shared-Explicit (SE) filter
   spec sent upstream in a Resv message includes an S2L sub-LSP
   descriptor list.  Each such FF flow descriptor or SE filter spec for
   the same P2MP LSP (whether on one or multiple Resv messages) on the
   same Resv MUST be allocated the same label, and FF flow descriptors
   or SE filter specs SHOULD use the same label across multiple Resv
   messages.

   The node that sends the Resv message, for a P2MP LSP, upstream MUST
   associate the label assigned by this node with all the labels
   received from downstream Resv messages, for that P2MP LSP.  Note that
   a transit node may become a replication point in the future when a
   branch is attached to it.  Hence, this results in the setup of a P2MP
   LSP from the ingress LSR to the egress LSRs.

Top      Up      ToC       Page 18 
   The ingress LSR may need to understand when all desired egresses have
   been reached.  This is achieved using S2L_SUB_LSP objects.

   Each branch node MAY forward a single Resv message upstream for each
   received Resv message from a downstream receiver.  Note that there
   may be a large number of Resv messages at and close to the ingress
   LSR for an LSP with many receivers.  A branch LSR SHOULD combine Resv
   state from multiple receivers into a single Resv message to be sent
   upstream (see section 6.2.1).  However, note that this may result in
   overflowing the Resv message, particularly as the number of receivers
   downstream of any branch LSR increases as the LSR is closer to the
   ingress LSR.  Thus, a branch LSR MAY choose to send more than one
   Resv message upstream and partition the Resv state between the
   messages.

   When a transit node sets the Sub-Group Originator field in a Path
   message, it MUST replace the Sub-Group fields received in the
   FILTER_SPEC objects of any associated Resv messages with the value
   that it originally received in the Sub-Group fields of the Path
   message from the upstream neighbor.

   ResvErr message generation is unmodified.  Nodes propagating a
   received ResvErr message MUST use the Sub-Group field values carried
   in the corresponding Resv message.

6.2.1.  Resv Message Throttling

   A branch node may have to send a revised Resv message upstream
   whenever there is a change in a Resv message for an S2L sub-LSP
   received from one of the downstream neighbors.  This can result in
   excessive Resv messages sent upstream, particularly when the S2L sub-
   LSPs are first established.  In order to mitigate this situation,
   branch nodes can limit their transmission of Resv messages.
   Specifically, in the case where the only change being sent in a Resv
   message is in one or more P2MP_SECONDARY_RECORD_ROUTE objects
   (SRROs), the branch node SHOULD transmit the Resv message only after
   a delay time has passed since the transmission of the previous Resv
   message for the same session.  This delayed Resv message SHOULD
   include SRROs for all branches.  A suggested value for the delay time
   is thirty seconds, and delay times SHOULD generally be longer than 1
   second.  Specific mechanisms for Resv message throttling and delay
   timer settings are implementation dependent and are outside the scope
   of this document.

Top      Up      ToC       Page 19 
6.3.  Route Recording

6.3.1.  RRO Processing

   A Resv message for a P2P LSP contains a recorded route if the ingress
   LSR requested route recording by including an RRO in the original
   Path message.  The same rule is used during signaling of P2MP LSPs.
   That is, inclusion of an RRO in the Path message used to signal one
   or more S2L sub-LSPs triggers the inclusion of a recorded route for
   each sub-LSP in the Resv message.

   The recorded route of the first S2L sub-LSP is encoded in the RRO.
   Additional recorded routes for the subsequent S2L sub-LSPs are
   encoded in P2MP_SECONDARY_RECORD_ROUTE objects (SRROs).  Their format
   is specified in section 19.5.  Each S2L_SUB_LSP object in a Resv is
   associated with an RRO or SRRO.  The first S2L_SUB_LSP object (for
   the first S2L sub-LSP) is associated with the RRO.  Subsequent
   S2L_SUB_LSP objects (for subsequent S2L sub-LSPs) are each followed
   by an SRRO that contains the recorded route for that S2L sub-LSP from
   the leaf to a branch.  The ingress node can then use the RRO and
   SRROs to determine the end-to-end path for each S2L sub-LSP.

6.4.  Reservation Style

   Considerations about the reservation style in a Resv message apply as
   described in [RFC3209].  The reservation style in the Resv messages
   can be either FF or SE.  All P2MP LSPs that belong to the same P2MP
   Tunnel MUST be signaled with the same reservation style.
   Irrespective of whether the reservation style is FF or SE, the S2L
   sub-LSPs that belong to the same P2MP LSP SHOULD share labels where
   they share hops.  If the S2L sub-LSPs that belong to the same P2MP
   LSP share labels then they MUST share resources.  If the reservation
   style is FF, then S2L sub-LSPs that belong to different P2MP LSPs
   MUST NOT share resources or labels.  If the reservation style is SE,
   then S2L sub-LSPs that belong to different P2MP LSPs and the same
   P2MP tunnel SHOULD share resources where they share hops, but they
   MUST not share labels in packet environments.

Top      Up      ToC       Page 20 
7.  PathTear Message

7.1.  PathTear Message Format

   The format of the PathTear message is as follows:

   <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
                           [ [ <MESSAGE_ID_ACK> |
                               <MESSAGE_ID_NACK> ... ]
                           [ <MESSAGE_ID> ]
                           <SESSION> <RSVP_HOP>
                           [ <sender descriptor> ]
                           [ <S2L sub-LSP descriptor list> ]

   <S2L sub-LSP descriptor list> ::= <S2L_SUB_LSP>
                                     [ <S2L sub-LSP descriptor list> ]

   The definition of <sender descriptor> is not changed by this
   document.

7.2.  Pruning

   The operation of removing egress LSR(s) from an existing P2MP LSP is
   termed as pruning.  This operation allows egress nodes to be removed
   from a P2MP LSP at different points in time.  This section describes
   the mechanisms to perform pruning.

7.2.1.  Implicit S2L Sub-LSP Teardown

   Implicit teardown uses standard RSVP message processing.  Per
   standard RSVP processing, an S2L sub-LSP may be removed from a P2MP
   TE LSP by sending a modified message for the Path or Resv message
   that previously advertised the S2L sub-LSP.  This message MUST list
   all S2L sub-LSPs that are not being removed.  When using this
   approach, a node processing a message that removes an S2L sub-LSP
   from a P2MP TE LSP MUST ensure that the S2L sub-LSP is not included
   in any other Path state associated with session before interrupting
   the data path to that egress.  All other message processing remains
   unchanged.

   When implicit teardown is used to delete one or more S2L sub-LSPs, by
   modifying a Path message, a transit LSR may have to generate a
   PathTear message downstream to delete one or more of these S2L sub-
   LSPs.  This can happen if as a result of the implicit deletion of S2L
   sub-LSP(s) there are no remaining S2L sub-LSPs to send in the
   corresponding Path message downstream.

Top      Up      ToC       Page 21 
7.2.2.  Explicit S2L Sub-LSP Teardown

   Explicit S2L Sub-LSP teardown relies on generating a PathTear message
   for the corresponding Path message.  The PathTear message is signaled
   with the SESSION and SENDER_TEMPLATE objects corresponding to the
   P2MP LSP and the <Sub-Group Originator ID, Sub-Group ID> tuple
   corresponding to the Path message.  This approach SHOULD be used when
   all the egresses signaled by a Path message need to be removed from
   the P2MP LSP.  Other S2L sub-LSPs, from other sub-groups signaled
   using other Path messages, are not affected by the PathTear.

   A transit LSR that propagates the PathTear message downstream MUST
   ensure that it sets the <Sub-Group Originator ID, Sub-Group ID> tuple
   in the PathTear message to the values used in the Path message that
   was used to set up the S2L sub-LSPs being torn down.  The transit LSR
   may need to generate multiple PathTear messages for an incoming
   PathTear message if it had performed transit fragmentation for the
   corresponding incoming Path message.

   When a P2MP LSP is removed by the ingress, a PathTear message MUST be
   generated for each Path message used to signal the P2MP LSP.

8.  Notify and ResvConf Messages

8.1.  Notify Messages

   The Notify Request object and Notify message are described in
   [RFC3473].  Both object and message SHALL be supported for delivery
   of upstream and downstream notification.  Processing not detailed in
   this section MUST comply to [RFC3473].

   1.  Upstream Notification

   If a transit LSR sets the Sub-Group Originator ID in the
   SENDER_TEMPLATE object of a Path message to its own address, and the
   incoming Path message carries a Notify Request object, then this LSR
   MUST change the Notify node address in the Notify Request object to
   its own address in the Path message that it sends.

   If this LSR subsequently receives a corresponding Notify message from
   a downstream LSR, then it MUST:

      - send a Notify message upstream toward the Notify node address
        that the LSR received in the Path message.

Top      Up      ToC       Page 22 
      - process the Sub-Group fields of the SENDER_TEMPLATE object on
        the received Notify message, and modify their values, in the
        Notify message that is forwarded, to match the Sub-Group field
        values in the original Path message received from upstream.

   The receiver of an (upstream) Notify message MUST identify the state
   referenced in this message based on the SESSION and SENDER_TEMPLATE.

   2.  Downstream Notification

   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
   object(s) of a Resv message to the value that was received in the
   corresponding Path message.  If the incoming Resv message carries a
   Notify Request object, then:

      - If there is at least another incoming Resv message that carries
        a Notify Request object, and the LSR merges these Resv messages
        into a single Resv message that is sent upstream, the LSR MUST
        set the Notify node address in the Notify Request object to its
        Router ID.

      - Else if the LSR sets the Sub-Group Originator ID (in the
        outgoing Path message that corresponds to the received Resv
        message) to its own address, the LSR MUST set the Notify node
        address in the Notify Request object to its Router ID.

      - Else the LSR MUST propagate the Notify Request object unchanged,
        in the Resv message that it sends upstream.

   If this LSR subsequently receives a corresponding Notify message from
   an upstream LSR, then it MUST:

      - process the Sub-Group fields of the FILTER_SPEC object in the
        received Notify message, and modify their values, in the Notify
        message that is forwarded, to match the Sub-Group field values
        in the original Path message sent downstream by this LSR.

      - send a Notify message downstream toward the Notify node address
        that the LSR received in the Resv message.

   The receiver of a (downstream) Notify message MUST identify the state
   referenced in the message based on the SESSION and FILTER_SPEC
   objects.

   The consequence of these rules for a P2MP LSP is that an upstream
   Notify message generated on a branch will result in a Notify being
   delivered to the upstream Notify node address.  The receiver of the
   Notify message MUST NOT assume that the Notify message applies to all

Top      Up      ToC       Page 23 
   downstream egresses, but MUST examine the information in the message
   to determine to which egresses the message applies.

   Downstream Notify messages MUST be replicated at branch LSRs
   according to the Notify Request objects received on Resv messages.
   Some downstream branches might not request Notify messages, but all
   that have requested Notify messages MUST receive them.

8.2.  ResvConf Messages

   ResvConf messages are described in [RFC2205].  ResvConf processing in
   [RFC3473] and [RFC3209] is taken directly from [RFC2205].  An egress
   LSR MAY include a RESV_CONFIRM object that contains the egress LSR's
   address.  The object and message SHALL be supported for the
   confirmation of receipt of the Resv message in P2MP TE LSPs.
   Processing not detailed in this section MUST comply to [RFC2205].

   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
   object(s) of a Resv message to the value that was received in the
   corresponding Path message.  If any of the incoming Resv messages
   corresponding to a single Path message carry a RESV_CONFIRM object,
   then the LSR MUST include a RESV_CONFIRM object in the corresponding
   Resv message that it sends upstream.  If the Sub-Group Originator ID
   is its own address, then it MUST set the receiver address in the
   RESV_CONFIRM object to this address, else it MUST propagate the
   object unchanged.

   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
   object(s) of a Resv message to the value that was received in the
   corresponding Path message.  If an incoming Resv message
   corresponding to a single Path message carries a RESV_CONFIRM object,
   then the LSR MUST include a RESV_CONFIRM object in the corresponding
   Resv message that it sends upstream and:

      - If there is at least another incoming Resv message that carries
        a RESV_CONFIRM object, and the LSR merges these Resv messages
        into a single Resv message that is sent upstream, the LSR MUST
        set the receiver address in the RESV_CONFIRM object to its
        Router ID.

      - If the LSR sets the Sub-Group Originator ID (in the outgoing
        Path message that corresponds to the received Resv message) to
        its own address, the LSR MUST set the receiver address in the
        RESV_CONFIRM object to its Router ID.

      - Else the LSR MUST propagate the RESV_CONFIRM object unchanged,
        in the Resv message that it sends upstream.

Top      Up      ToC       Page 24 
   If this LSR subsequently receives a corresponding ResvConf message
   from an upstream LSR, then it MUST:

      - process the Sub-Group fields of the FILTER_SPEC object in the
        received ResvConf message, and modify their values, in the
        ResvConf message that is forwarded, to match the Sub-Group field
        values in the original Path message sent downstream by this LSR.

      - send a ResvConf message downstream toward the receiver address
        that the LSR received in the RESV_CONFIRM object in the Resv
        message.

   The receiver of a ResvConf message MUST identify the state referenced
   in this message based on the SESSION and FILTER_SPEC objects.

   The consequence of these rules for a P2MP LSP is that a ResvConf
   message generated at the ingress will result in a ResvConf message
   being delivered to the branch and then to the receiver address in the
   original RESV_CONFIRM object.  The receiver of a ResvConf message
   MUST NOT assume that the ResvConf message should be sent to all
   downstream egresses, but it MUST replicate the message according to
   the RESV_CONFIRM objects received in Resv messages.  Some downstream
   branches might not request ResvConf messages, and ResvConf messages
   SHOULD NOT be sent on these branches.  All downstream branches that
   requested ResvConf messages MUST be sent such a message.

9.  Refresh Reduction

   The refresh reduction procedures described in [RFC2961] are equally
   applicable to P2MP LSPs described in this document.  Refresh
   reduction applies to individual messages and the state they
   install/maintain, and that continues to be the case for P2MP LSPs.

10.  State Management

   State signaled by a P2MP Path message is identified by a local
   implementation using the <P2MP ID, Tunnel ID, Extended Tunnel ID>
   tuple as part of the SESSION object and the <Tunnel Sender Address,
   LSP ID, Sub-Group Originator ID, Sub-Group ID> tuple as part of the
   SENDER_TEMPLATE object.

   Additional information signaled in the Path/Resv message is part of
   the state created by a local implementation.  This includes PHOP/NHOP
   and SENDER_TSPEC/FILTER_SPEC objects.

Top      Up      ToC       Page 25 
10.1.  Incremental State Update

   RSVP (as defined in [RFC2205] and as extended by RSVP-TE [RFC3209]
   and GMPLS [RFC3473]) uses the same basic approach to state
   communication and synchronization -- namely, full state is sent in
   each state advertisement message.  Per [RFC2205], Path and Resv
   messages are idempotent.  Also, [RFC2961] categorizes RSVP messages
   into two types (trigger and refresh messages) and improves RSVP
   message handling and scaling of state refreshes, but does not modify
   the full state advertisement nature of Path and Resv messages.  The
   full state advertisement nature of Path and Resv messages has many
   benefits, but also has some drawbacks.  One notable drawback is when
   an incremental modification is being made to a previously advertised
   state.  In this case, there is the message overhead of sending the
   full state and the cost of processing it.  It is desirable to
   overcome this drawback and add/delete S2L sub-LSPs to/from a P2MP LSP
   by incrementally updating the existing state.

   It is possible to use the procedures described in this document to
   allow S2L sub-LSPs to be incrementally added to or deleted from the
   P2MP LSP by allowing a Path or a PathTear message to incrementally
   change the existing P2MP LSP Path state.

   As described in section 5.2, multiple Path messages can be used to
   signal a P2MP LSP.  The Path messages are distinguished by different
   <Sub-Group Originator ID, Sub-Group ID> tuples in the SENDER_TEMPLATE
   object.  In order to perform incremental S2L sub-LSP state addition,
   a separate Path message with a new Sub-Group ID is used to add the
   new S2L sub-LSPs, by the ingress LSR.  The Sub-Group Originator ID
   MUST be set to the TE Router ID [RFC3477] of the node that sets the
   Sub-Group ID.

   This maintains the idempotent nature of RSVP Path messages, avoids
   keeping track of individual S2L sub-LSP state expiration, and
   provides the ability to perform incremental P2MP LSP state updates.

10.2.  Combining Multiple Path Messages

   There is a tradeoff between the number of Path messages used by the
   ingress to maintain the P2MP LSP and the processing imposed by full
   state messages when adding S2L sub-LSPs to an existing Path message.
   It is possible to combine S2L sub-LSPs previously advertised in
   different Path messages in a single Path message in order to reduce
   the number of Path messages needed to maintain the P2MP LSP.  This
   can also be done by a transit node that performed fragmentation and
   that at a later point is able to combine multiple Path messages that
   it generated into a single Path message.  This may happen when one or
   more S2L sub-LSPs are pruned from the existing Path states.

Top      Up      ToC       Page 26 
   The new Path message is signaled by the node that is combining
   multiple Path messages with all the S2L sub-LSPs that are being
   combined in a single Path message.  This Path message MAY contain new
   Sub-Group ID field values.  When a new Path and Resv message that is
   signaled for an existing S2L sub-LSP is received by a transit LSR,
   state including the new instance of the S2L sub-LSP is created.

   The S2L sub-LSP SHOULD continue to be advertised in both the old and
   new Path messages until a Resv message listing the S2L sub-LSP and
   corresponding to the new Path message is received by the combining
   node.  Hence, until this point, state for the S2L sub-LSP SHOULD be
   maintained as part of the Path state for both the old and the new
   Path message (see section 3.1.3 of [RFC2205]).  At that point the S2L
   sub-LSP SHOULD be deleted from the old Path state using the
   procedures of section 7.

   A Path message with a Sub-Group_ID(n) may signal a set of S2L sub-
   LSPs that belong partially or entirely to an already existing Sub-
   Group_ID(i), or a strictly non-overlapping new set of S2L sub-LSPs.
   A newly received Path message that matches SESSION object and Sender
   Tunnel Address, LSP ID, Sub-Group Originator ID> with existing Path
   state carrying the same or different Sub-Group_ID, referred to Sub-
   Group_ID(n) is processed as follows:

   1) If Sub-Group_ID(i) = Sub-Group_ID(n), then S2L Sub-LSPs that are
      in both Sub-Group_ID(i) and Sub-Group_ID(n) are refreshed.  New
      S2L Sub-LSPs are added to Sub-Group_ID(i) Path state and S2L Sub-
      LSPs that are in Sub-Group_ID(i) but not in Sub-Group_ID(n) are
      deleted from the Sub-Group_ID(i) Path state.

   2) If Sub-Group_ID(i) != Sub-Group_ID(n), then a new Sub-Group_ID(n)
      Path state is created for S2L Sub-LSPs signaled by Sub-
      Group_ID(n).  S2L Sub-LSPs in existing Sub-Group_IDs(i) Path state
      (that are or are not in the newly received Path message Sub-
      Group_ID(n)) are left unmodified (see above).

11.  Error Processing

   PathErr and ResvErr messages are processed as per RSVP-TE procedures.
   Note that an LSR, on receiving a PathErr/ResvErr message for a
   particular S2L sub-LSP, changes the state only for that S2L sub-LSP.
   Hence other S2L sub-LSPs are not impacted.  If the ingress node
   requests 'LSP integrity', an error reported on a branch of a P2MP TE
   LSP for a particular S2L sub-LSP may change the state of any other
   S2L sub-LSP of the same P2MP TE LSP.  This is explained further in
   section 11.3.

Top      Up      ToC       Page 27 
11.1.  PathErr Messages

   The PathErr message will include one or more S2L_SUB_LSP objects.
   The resulting modified format for a PathErr message is:

   <PathErr Message> ::=    <Common Header> [ <INTEGRITY> ]
                             [ [<MESSAGE_ID_ACK> |
                                <MESSAGE_ID_NACK>] ... ]
                             [ <MESSAGE_ID> ]
                             <SESSION> <ERROR_SPEC>
                             [ <ACCEPTABLE_LABEL_SET> ... ]
                             [ <POLICY_DATA> ... ]
                             <sender descriptor>
                             [ <S2L sub-LSP descriptor list> ]

   PathErr message generation is unmodified, but nodes that set the
   Sub-Group Originator field and propagate a received PathErr message
   upstream MUST replace the Sub-Group fields received in the PathErr
   message with the value that was received in the Sub-Group fields of
   the Path message from the upstream neighbor.  Note the receiver of a
   PathErr message is able to identify the errored outgoing Path
   message, and outgoing interface, based on the Sub-Group fields
   received in the PathErr message.  The S2L sub-LSP descriptor list is
   defined in section 5.1.

11.2.  ResvErr Messages

   The ResvErr message will include one or more S2L_SUB_LSP objects.
   The resulting modified format for a ResvErr Message is:

   <ResvErr Message> ::=    <Common Header> [ <INTEGRITY> ]
                             [ [<MESSAGE_ID_ACK> |
                                <MESSAGE_ID_NACK>] ... ]
                             [ <MESSAGE_ID> ]
                             <SESSION> <RSVP_HOP>
                             <ERROR_SPEC> [ <SCOPE> ]
                             [ <ACCEPTABLE_LABEL_SET> ... ]
                             [ <POLICY_DATA> ... ]
                             <STYLE> <flow descriptor list>

   ResvErr message generation is unmodified, but nodes that set the
   Sub-Group Originator field and propagate a received ResvErr message
   downstream MUST replace the Sub-Group fields received in the ResvErr
   message with the value that was set in the Sub-Group fields of the
   Path message sent to the downstream neighbor.  Note the receiver of a
   ResvErr message is able to identify the errored outgoing Resv

Top      Up      ToC       Page 28 
   message, and outgoing interface, based on the Sub-Group fields
   received in the ResvErr message.  The flow descriptor list is defined
   in section 6.1.

11.3.  Branch Failure Handling

   During setup and during normal operation, PathErr messages may be
   received at a branch node.  In all cases, a received PathErr message
   is first processed per standard processing rules.  That is, the
   PathErr message is sent hop-by-hop to the ingress/branch LSR for that
   Path message.  Intermediate nodes until this ingress/branch LSR MAY
   inspect this message but take no action upon it.  The behavior of a
   branch LSR that generates a PathErr message is under the control of
   the ingress LSR.

   The default behavior is that the PathErr message does not have the
   Path_State_Removed flag set.  However, if the ingress LSR has set the
   LSP integrity flag on the Path message (see LSP_REQUIRED_ATTRIBUTEs
   object in section 5.2.4), and if the Path_State_Removed flag is
   supported, the LSR generating a PathErr to report the failure of a
   branch of the P2MP LSP SHOULD set the Path_State_Removed flag.

   A branch LSR that receives a PathErr message during LSP setup with
   the Path_State_Removed flag set MUST act according to the wishes of
   the ingress LSR.  The default behavior is that the branch LSR clears
   the Path_State_Removed flag on the PathErr and sends it further
   upstream.  It does not tear any other branches of the LSP.  However,
   if the LSP integrity flag is set on the Path message, the branch LSR
   MUST send PathTear on all other downstream branches and send the
   PathErr message upstream with the Path_State_Removed flag set.

   A branch LSR that receives a PathErr message with the
   Path_State_Removed flag clear MUST act according to the wishes of the
   ingress LSR.  The default behavior is that the branch LSR forwards
   the PathErr upstream and takes no further action.  However, if the
   LSP integrity flag is set on the Path message, the branch LSR MUST
   send PathTear on all downstream branches and send the PathErr
   upstream with the Path_State_Removed flag set (per [RFC3473]).

   In all cases, the PathErr message forwarded by a branch LSR MUST
   contain the S2L sub-LSP identification and explicit routes of all
   branches that are reported by received PathErr messages and all
   branches that are explicitly torn by the branch LSR.

Top      Up      ToC       Page 29 
12.  Admin Status Change

   A branch node that receives an ADMIN_STATUS object processes it
   normally and also relays the ADMIN_STATUS object in a Path on every
   branch.  All Path messages may be concurrently sent to the downstream
   neighbors.

   Downstream nodes process the change in the ADMIN_STATUS object per
   [RFC3473], including generation of Resv messages.  When the last
   received upstream ADMIN_STATUS object had the R bit set, branch nodes
   wait for a Resv message with a matching ADMIN_STATUS object to be
   received (or a corresponding PathErr or ResvTear message) on all
   branches before relaying a corresponding Resv message upstream.

13.  Label Allocation on LANs with Multiple Downstream Nodes

   A branch LSR of a P2MP LSP on an Ethernet LAN segment SHOULD send one
   copy of the data traffic per downstream LSR connected on that LAN for
   that P2MP LSP.  Procedures for preventing MPLS labeled traffic
   replication in such a case is beyond the scope of this document.

14.  P2MP LSP and Sub-LSP Re-Optimization

   It is possible to change the path used by P2MP LSPs to reach the
   destinations of the P2MP tunnel.  There are two methods that can be
   used to accomplish this.  The first is make-before-break, defined in
   [RFC3209], and the second uses the sub-groups defined above.

14.1.  Make-before-Break

   In this case, all the S2L sub-LSPs are signaled with a different LSP
   ID by the ingress LSR and follow the make-before-break procedure
   defined in [RFC3209].  Thus, a new P2MP LSP is established.  Each S2L
   sub-LSP is signaled with a different LSP ID, corresponding to the new
   P2MP LSP.  After moving traffic to the new P2MP LSP, the ingress can
   tear down the old P2MP LSP.  This procedure can be used to re-
   optimize the path of the entire P2MP LSP or the paths to a subset of
   the destinations of the P2MP LSP.  When modifying just a portion of
   the P2MP LSP, this approach requires the entire P2MP LSP to be re-
   signaled.

14.2.  Sub-Group-Based Re-Optimization

   Any node may initiate re-optimization of a set of S2L sub-LSPs by
   using incremental state update and then, optionally, combining
   multiple path messages.

Top      Up      ToC       Page 30 
   To alter the path taken by a particular set of S2L sub-LSPs, the node
   initiating the path change initiates one or more separate Path
   messages for the same P2MP LSP, each with a new sub-Group ID.  The
   generation of these Path messages, each with one or more S2L sub-
   LSPs, follows procedures in section 5.2.  As is the case in section
   10.2, a particular egress continues to be advertised in both the old
   and new Path messages until a Resv message listing the egress and
   corresponding to the new Path message is received by the re-
   optimizing node.  At that point, the egress SHOULD be deleted from
   the old Path state using the procedures of section 7.  Sub-tree re-
   optimization is then completed.

   Sub-Group-based re-optimization may result in transient data
   duplication as the new Path messages for a set of S2L sub-LSPs may
   transit one or more nodes with the old Path state for the same set of
   S2L sub-LSPs.

   As is always the case, a node may choose to combine multiple path
   messages as described in section 10.2.

15.  Fast Reroute

   [RFC4090] extensions can be used to perform fast reroute for the
   mechanism described in this document when applied within packet
   networks.  GMPLS introduces other protection techniques that can be
   applied to packet and non-packet environments [RFC4873], but which
   are not discussed further in this document.  This section only
   applies to LSRs that support [RFC4090].

   This section uses terminology defined in [RFC4090], and fast reroute
   procedures defined in [RFC4090] MUST be followed unless specified
   below.  The head-end and transit LSRs MUST follow the
   SESSION_ATTRIBUTE and FAST_REROUTE object processing as specified in
   [RFC4090] for each Path message and S2L sub-LSP of a P2MP LSP.  Each
   S2L sub-LSP of a P2MP LSP MUST have the same protection
   characteristics.  The RRO processing MUST apply to SRRO as well
   unless modified below.

   The sections that follow describe how fast reroute may be applied to
   P2MP MPLS TE LSPs in all of the principal operational scenarios.
   This document does not describe the detailed processing steps for
   every imaginable usage case, and they may be described in future
   documents, as needed.

Top      Up      ToC       Page 31 
15.1.  Facility Backup

   Facility backup can be used for link or node protection of LSRs on
   the path of a P2MP LSP.  The downstream labels MUST be learned by the
   Point of Local Repair (PLR), as specified in [RFC4090], from the
   label corresponding to the S2L sub-LSP in the RESV message.
   Processing of SEROs signaled in a backup tunnel MUST follow backup
   tunnel ERO processing described in [RFC4090].

15.1.1.  Link Protection

   If link protection is desired, a bypass tunnel MUST be used to
   protect the link between the PLR and next-hop.  Thus all S2L sub-LSPs
   that use the link SHOULD be protected in the event of link failure.
   Note that all such S2L sub-LSPs belonging to a particular instance of
   a P2MP tunnel SHOULD share the same outgoing label on the link
   between the PLR and the next-hop as per section 5.2.1.  This is the
   P2MP LSP label on the link.  Label stacking is used to send data for
   each P2MP LSP into the bypass tunnel.  The inner label is the P2MP
   LSP label allocated by the next-hop.

   During failure, Path messages for each S2L sub-LSP that is affected,
   MUST be sent to the Merge Point (MP) by the PLR.  It is RECOMMENDED
   that the PLR uses the sender template-specific method to identify
   these Path messages.  Hence, the PLR will set the source address in
   the sender template to a local PLR address.

   The MP MUST use the LSP-ID to identify the corresponding S2L sub-
   LSPs.  The MP MUST NOT use the <Sub-Group Originator ID, Sub-Group
   ID> tuple while identifying the corresponding S2L sub-LSPs.  In order
   to further process an S2L sub-LSP the MP MUST determine the protected
   S2L sub-LSP using the LSP-ID and the S2L_SUB_LSP object.

15.1.2.  Node Protection

   If node protection is desired the PLR SHOULD use one or more P2P
   bypass tunnels to protect the set of S2L sub-LSPs that transit the
   protected node.  Each of these P2P bypass tunnels MUST intersect the
   path of the S2L sub-LSPs that they protect on an LSR that is
   downstream from the protected node.  This constrains the set of S2L
   sub-LSPs being backed- up via that bypass tunnel to those S2L sub-
   LSPs that pass through a common downstream MP.  This MP is the
   destination of the bypass tunnel.  When the PLR forwards incoming
   data for a P2MP LSP into the bypass tunnel, the outer label is the
   bypass tunnel label and the inner label is the label allocated by the
   MP to the set of S2L sub-LSPs belonging to that P2MP LSP.

Top      Up      ToC       Page 32 
   After detecting failure of the protected node the PLR MUST send one
   or more Path messages for all protected S2L sub-LSPs to the MP of the
   protected S2L sub-LSP.  It is RECOMMENDED that the PLR use the sender
   template specific method to identify these Path messages.  Hence the
   PLR will set the source address in the sender template to a local PLR
   address.  The MP MUST use the LSP-ID to identify the corresponding
   S2L sub-LSPs.  The MP MUST NOT use the <Sub-Group Originator ID,
   Sub-Group ID> tuple while identifying the corresponding S2L sub-LSPs
   because the Sub-Group Originator ID might be changed by some LSR that
   is bypassed by the bypass tunnel.  In order to further process an S2L
   sub-LSP the MP MUST determine the protected S2L sub-LSP using the
   LSP-ID and the S2L_SUB_LSP object.

   Note that node protection MAY require the PLR to be branch capable in
   the data plane, as multiple bypass tunnels may be required to back up
   the set of S2L sub-LSPs passing through the protected node.  If the
   PLR is not branch capable, the node protection mechanism described
   here is applicable to only those cases where all the S2L sub-LSPs
   passing through the protected node also pass through a single MP that
   is downstream from the protected node.  A PLR MUST set the Node
   protection flag in the RRO/SRRO as specified in [RFC4090].  If a PLR
   is not branch capable, and one or more S2L sub-LSPs are added to a
   P2MP tree, and these S2L sub-LSPs do not transit the existing MP
   downstream of the protected node, then the PLR MUST reset this flag.

   It is to be noted that procedures in this section require P2P bypass
   tunnels.  Procedures for using P2MP bypass tunnels are for further
   study.

15.2.  One-to-One Backup

   One-to-one backup, as described in [RFC4090], can be used to protect
   a particular S2L sub-LSP against link and next-hop failure.
   Protection may be used for one or more S2L sub-LSPs between the PLR
   and the next-hop.  All the S2L sub-LSPs corresponding to the same
   instance of the P2MP tunnel between the PLR and the next-hop SHOULD
   share the same P2MP LSP label, as per section 5.2.1.  All such S2L
   sub-LSPs belonging to a P2MP LSP MUST be protected.

   The backup S2L sub-LSPs may traverse different next-hops at the PLR.
   Thus, the set of outgoing labels and next-hops for a P2MP LSP, at the
   PLR, may change once protection is triggered.  Consider a P2MP LSP
   that is using a single next-hop and label between the PLR and the
   next-hop of the PLR.  This may no longer be the case once protection
   is triggered.  This MAY require a PLR to be branch capable in the
   data plane.  If the PLR is not branch capable, the one-to-one backup
   mechanisms described here are only applicable to those cases where
   all the backup S2L sub-LSPs pass through the same next-hop downstream

Top      Up      ToC       Page 33 
   of the PLR.  Procedures for one-to-one backup when a PLR is not
   branch capable and when all the backup S2L sub-LSPs do not pass
   through the same downstream next-hop are for further study.

   It is recommended that the path-specific method be used to identify a
   backup S2L sub-LSP.  Hence, the DETOUR object SHOULD be inserted in
   the backup Path message.  A backup S2L sub-LSP MUST be treated as
   belonging to a different P2MP tunnel instance than the one specified
   by the LSP-ID.  Furthermore multiple backup S2L sub-LSPs MUST be
   treated as part of the same P2MP tunnel instance if they have the
   same LSP-ID and the same DETOUR objects.  Note that, as specified in
   section 4, S2L sub-LSPs between different P2MP tunnel instances use
   different labels.

   If there is only one S2L sub-LSP in the Path message, the DETOUR
   object applies to that sub-LSP.  If there are multiple S2L sub-LSPs
   in the Path message, the DETOUR object applies to all the S2L sub-
   LSPs.

16.  Support for LSRs That Are Not P2MP Capable

   It may be that some LSRs in a network are capable of processing the
   P2MP extensions described in this document, but do not support P2MP
   branching in the data plane.  If such an LSR is requested to become a
   branch LSR by a received Path message, it MUST respond with a PathErr
   message carrying the Error Code "Routing Error" and Error Value
   "Unable to Branch".

   It is also conceivable that some LSRs, in a network deploying P2MP
   capability, may not support the extensions described in this
   document.  If a Path message for the establishment of a P2MP LSP
   reaches such an LSR, it will reject it with a PathErr because it will
   not recognize the C-Type of the P2MP SESSION object.

   LSRs that do not support the P2MP extensions in this document may be
   included as transit LSRs by the use of LSP stitching [LSP-STITCH] and
   LSP hierarchy [RFC4206].  Note that LSRs that are required to play
   any other role in the network (ingress, branch or egress) MUST
   support the extensions defined in this document.

   The use of LSP stitching and LSP hierarchy [RFC4206] allows P2MP LSPs
   to be built in such an environment.  A P2P LSP segment is signaled
   from the last P2MP-capable hop that is upstream of a legacy LSR to
   the first P2MP-capable hop that is downstream of it.  This assumes
   that intermediate legacy LSRs are transit LSRs: they cannot act as
   P2MP branch points.  Transit LSRs along this LSP segment do not
   process control plane messages associated with the P2MP LSP.
   Furthermore, these transit LSRs also do not need to have P2MP data

Top      Up      ToC       Page 34 
   plane capabilities as they only need to process data belonging to the
   P2P LSP segment.  Hence, these transit LSRs do not need to support
   P2MP MPLS.  This P2P LSP segment is stitched to the incoming P2MP
   LSP.  After the P2P LSP segment is established, the P2MP Path message
   is sent to the next P2MP-capable LSR as a directed Path message.  The
   next P2MP-capable LSR stitches the P2P LSP segment to the outgoing
   P2MP LSP.

   In packet networks, the S2L sub-LSPs may be nested inside the outer
   P2P LSP.  Hence, label stacking can be used to enable use of the same
   LSP segment for multiple P2MP LSPs.  Stitching and nesting
   considerations and procedures are described further in [LSP-STITCH]
   and [RFC4206].

   There maybe overhead for an operator to configure the P2P LSP
   segments in advance, when it is desired to support legacy LSRs.  It
   may be desirable to do this dynamically.  The ingress can use IGP
   extensions to determine P2MP-capable LSRs [TE-NODE-CAP].  It can use
   this information to compute S2L sub-LSP paths such that they avoid
   legacy non-P2MP-capable LSRs.  The explicit route object of an S2L
   sub-LSP path may contain loose hops if there are legacy LSRs along
   the path.  The corresponding explicit route contains a list of
   objects up to the P2MP-capable LSR that is adjacent to a legacy LSR
   followed by a loose object with the address of the next P2MP-capable
   LSR.  The P2MP-capable LSR expands the loose hop using its Traffic
   Engineering Database (TED).  When doing this it determines that the
   loose hop expansion requires a P2P LSP to tunnel through the legacy
   LSR.  If such a P2P LSP exists, it uses that P2P LSP.  Else it
   establishes the P2P LSP.  The P2MP Path message is sent to the next
   P2MP-capable LSR using non-adjacent signaling.

   The P2MP-capable LSR that initiates the non-adjacent signaling
   message to the next P2MP-capable LSR may have to employ a fast
   detection mechanism (such as [BFD] or [BFD-MPLS]) to the next P2MP-
   capable LSR.  This may be needed for the directed Path message head-
   end to use node protection fast reroute when the protected node is
   the directed Path message tail.

   Note that legacy LSRs along a P2P LSP segment cannot perform node
   protection of the tail of the P2P LSP segment.

17.  Reduction in Control Plane Processing with LSP Hierarchy

   It is possible to take advantage of LSP hierarchy [RFC4206] while
   setting up P2MP LSP, as described in the previous section, to reduce
   control plane processing along transit LSRs that are P2MP capable.
   This is applicable only in environments where LSP hierarchy can be
   used.  Transit LSRs along a P2P LSP segment, being used by a P2MP

Top      Up      ToC       Page 35 
   LSP, do not process control plane messages associated with the P2MP
   LSP.  In fact, they are not aware of these messages as they are
   tunneled over the P2P LSP segment.  This reduces the amount of
   control plane processing required on these transit LSRs.

   Note that the P2P LSPs can be set up dynamically as described in the
   previous section or preconfigured.  For example, in Figure 2 in
   section 24, PE1 can set up a P2P LSP to P1 and use that as a LSP
   segment.  The Path messages for PE3 and PE4 can now be tunneled over
   the LSP segment.  Thus, P3 is not aware of the P2MP LSP and does not
   process the P2MP control messages.



(page 35 continued on part 3)

Next RFC Part