tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4875

 
 
 

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

Part 3 of 3, p. 35 to 53
Prev RFC Part

 


prevText      Top      Up      ToC       Page 35 
18.  P2MP LSP Re-Merging and Cross-Over

   This section details the procedures for detecting and dealing with
   re-merge and cross-over.  The term "re-merge" refers to the case of
   an ingress or transit node that creates a branch of a P2MP LSP, a re-
   merge branch, that intersects the P2MP LSP at another node farther
   down the tree.  This may occur due to such events as an error in path
   calculation, an error in manual configuration, or network topology
   changes during the establishment of the P2MP LSP.  If the procedures
   detailed in this section are not followed, data duplication will
   result.

   The term "cross-over" refers to the case of an ingress or transit
   node that creates a branch of a P2MP LSP, a cross-over branch, that
   intersects the P2MP LSP at another node farther down the tree.  It is
   unlike re-merge in that, at the intersecting node, the cross-over
   branch has a different outgoing interface as well as a different
   incoming interface.  This may be necessary in certain combinations of
   topology and technology; e.g., in a transparent optical network in
   which different wavelengths are required to reach different leaf
   nodes.

   Normally, a P2MP LSP has a single incoming interface on which all of
   the data for the P2MP LSP is received.  The incoming interface is
   identified by the IF_ID RSVP_HOP object, if present, and by the
   interface over which the Path message was received if the IF_ID
   RSVP_HOP object is not present.  However, in the case of dynamic LSP
   re-routing, the incoming interface may change.

   Similarly, in both the re-merge and cross-over cases, a node will
   receive a Path message for a given P2MP LSP identifying a different
   incoming interface for the data, and the node needs to be able to
   distinguish between dynamic LSP re-routing and the re- merge/cross-
   over cases.

Top      Up      ToC       Page 36 
   Make-before-break represents yet another similar but different case,
   in that the incoming interface associated with the make-before-break
   P2MP LSP may be different than that associated with the original P2MP
   LSP.  However, the two P2MP LSPs will be treated as distinct (but
   related) LSPs because they will have different LSP ID field values in
   their SENDER_TEMPLATE objects.

18.1.  Procedures

   When a node receives a Path message, it MUST check whether it has
   matching state for the P2MP LSP.  Matching state is identified by
   comparing the SESSION and SENDER_TEMPLATE objects in the received
   Path message with the SESSION and SENDER_TEMPLATE objects of each
   locally maintained P2MP LSP Path state.  The P2MP ID, Tunnel ID, and
   Extended Tunnel ID in the SESSION object and the sender address and
   LSP ID in the SENDER_TEMPLATE object are used for the comparison.  If
   the node has matching state, and the incoming interface for the
   received Path message is different than the incoming interface of the
   matching P2MP LSP Path state, then the node MUST determine whether it
   is dealing with dynamic LSP rerouting or re-merge/cross-over.

   Dynamic LSP rerouting is identified by checking whether there is any
   intersection between the set of S2L_SUB_LSP objects associated with
   the matching P2MP LSP Path state and the set of S2L_SUB_LSP objects
   in the received Path message.  If there is any intersection, then
   dynamic re-routing has occurred.  If there is no intersection between
   the two sets of S2L_SUB_LSP objects, then either re-merge or cross-
   over has occurred.  (Note that in the case of dynamic LSP rerouting,
   Path messages for the non-intersecting members of set of S2L_SUB_LSPs
   associated with the matching P2MP LSP Path state will be received
   subsequently on the new incoming interface.)

   In order to identify the re-merge case, the node processing the
   received Path message MUST identify the outgoing interfaces
   associated with the matching P2MP Path state.  Re-merge has occurred
   if there is any intersection between the set of outgoing interfaces
   associated with the matching P2MP LSP Path state and the set of
   outgoing interfaces in the received Path message.

18.1.1.  Re-Merge Procedures

   There are two approaches to dealing with the re-merge case.  In the
   first, the node detecting the re-merge case, i.e., the re-merge node,
   allows the re-merge case to persist, but data from all but one
   incoming interface is dropped at the re-merge node.  In the second,
   the re-merge node initiates the removal of the re-merge branch(es)
   via signaling.  Which approach is used is a matter of local policy.

Top      Up      ToC       Page 37 
   A node MUST support both approaches and MUST allow user configuration
   of which approach is to be used.

   When configured to allow a re-merge case to persist, the re-merge
   node MUST validate consistency between the objects included in the
   received Path message and the matching P2MP LSP Path state.  Any
   inconsistencies MUST result in a PathErr message sent to the previous
   hop of the received Path message.  The Error Code is set to "Routing
   Problem", and the Error Value is set to "P2MP Re-Merge Parameter
   Mismatch".

   If there are no inconsistencies, the node logically merges, from the
   downstream perspective, the control state of incoming Path message
   with the matching P2MP LSP Path state.  Specifically, procedures
   related to processing of messages received from upstream MUST NOT be
   modified from the upstream perspective; this includes processing
   related to refresh and state timeout.  In addition to the standard
   upstream related procedures, the node MUST ensure that each object
   received from upstream is appropriately represented within the set of
   Path messages sent downstream.  For example, the received <S2L sub-
   LSP descriptor list> MUST be included in the set of outgoing Path
   messages.  If there are any NOTIFY_REQUEST objects present, then the
   procedures defined in section 8 MUST be followed for all Path and
   Resv messages.  Special processing is also required for Resv
   processing.  Specifically, any Resv message received from downstream
   MUST be mapped into an outgoing Resv message that is sent to the
   previous hop of the received Path message.  In practice, this
   translates to decomposing the complete <S2L sub-LSP descriptor list>
   into subsets that match the incoming Path messages, and then
   constructing an outgoing Resv message for each incoming Path message.

   When configured to allow a re-merge case to persist, the re-merge
   node receives data associated with the P2MP LSP on multiple incoming
   interfaces, but it MUST only send the data from one of these
   interfaces to its outgoing interfaces.  That is, the node MUST drop
   data from all but one incoming interface.  This ensures that
   duplicate data is not sent on any outgoing interface.  The mechanism
   used to select the incoming interface is implementation specific and
   is outside the scope of this document.

   When configured to correct the re-merge branch via signaling, the re-
   merge node MUST send a PathErr message corresponding to the received
   Path message.  The PathErr message MUST include all of the objects
   normally included in a PathErr message, as well as one or more
   S2L_SUB_LSP objects from the set of sub-LSPs associated with the
   matching P2MP LSP Path state.  A minimum of three S2L_SUB_LSP objects
   is RECOMMENDED.  This will allow the node that caused the re-merge to
   identify the outgoing Path state associated with the valid portion of

Top      Up      ToC       Page 38 
   the P2MP LSP.  The set of S2L_SUB_LSP objects in the received Path
   message MUST also be included.  The PathErr message MUST include the
   Error Code "Routing Problem" and Error Value of "P2MP Re-Merge
   Detected".  The node MAY set the Path_State_Removed flag [RFC3473].
   As is always the case, the PathErr message is sent to the previous
   hop of the received Path message.

   A node that receives a PathErr message that contains the Error Value
   "Routing Problem/P2MP Re-Merge Detected" MUST determine if it is the
   node that created the re-merge case.  This is done by checking
   whether there is any intersection between the set of S2L_SUB_LSP
   objects associated with the matching P2MP LSP Path state and the set
   of other-branch S2L_SUB_LSP objects in the received PathErr message.
   If there is, then the node created the re-merge case.  Other-branch
   S2L_SUB_LSP objects are those S2L_SUB_LSP objects included, by the
   node detecting the re-merge case, in the PathErr message that were
   taken from the matching P2MP LSP Path state.  Such S2L_SUB_LSP
   objects are identifiable as they will not be included in the Path
   message associated with the received PathErr message.  See section
   11.1 for more details on how such an association is identified.

   The node SHOULD remove the re-merge case by moving the S2L_SUB_LSP
   objects included in the Path message associated with the received
   PathErr message to the outgoing interface associated with the
   matching P2MP LSP Path state.  A trigger Path message for the moved
   S2L_SUB_LSP objects is then sent via that outgoing interface.  If the
   received PathErr message did not have the Path_State_Removed flag
   set, the node SHOULD send a PathTear via the outgoing interface
   associated with the re-merge branch.

   If use of a new outgoing interface violates one or more SERO
   constraints, then a PathErr message containing the associated
   egresses and any identified S2L_SUB_LSP objects SHOULD be generated
   with the Error Code "Routing Problem" and Error Value of "ERO
   Resulted in Re-Merge".

   The only case where this process will fail is when all the listed
   S2L_SUB_LSP objects are deleted prior to the PathErr message
   propagating to the ingress.  In this case, the whole process will be
   corrected on the next (refresh or trigger) transmission of the
   offending Path message.

Top      Up      ToC       Page 39 
19.  New and Updated Message Objects

   This section presents the RSVP object formats as modified by this
   document.

19.1.  SESSION Object

   A P2MP LSP SESSION object is used.  This object uses the existing
   SESSION C-Num.  New C-Types are defined to accommodate a logical P2MP
   destination identifier of the P2MP tunnel.  This SESSION object has a
   similar structure as the existing point-to-point RSVP-TE SESSION
   object.  However the destination address is set to the P2MP ID
   instead of the unicast Tunnel Endpoint address.  All S2L sub-LSPs
   that are part of the same P2MP LSP share the same SESSION object.
   This SESSION object identifies the P2MP tunnel.

   The combination of the SESSION object, the SENDER_TEMPLATE object and
   the S2L_SUB_LSP object identifies each S2L sub-LSP.  This follows the
   existing P2P RSVP-TE notion of using the SESSION object for
   identifying a P2P Tunnel, which in turn can contain multiple LSPs,
   each distinguished by a unique SENDER_TEMPLATE object.

19.1.1.  P2MP LSP Tunnel IPv4 SESSION Object

   Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       P2MP ID                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MUST be zero                 |      Tunnel ID                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Extended Tunnel ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   P2MP ID
      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel.  It encodes the P2MP
      Identifier that is unique within the scope of the ingress LSR.

   Tunnel ID
      A 16-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel.

Top      Up      ToC       Page 40 
   Extended Tunnel ID
      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel.  Ingress LSRs that wish
      to have a globally unique identifier for the P2MP tunnel SHOULD
      place their tunnel sender address here.  A combination of this
      address, P2MP ID, and Tunnel ID provides a globally unique
      identifier for the P2MP tunnel.

19.1.2.  P2MP LSP Tunnel IPv6 SESSION Object

   This is the same as the P2MP IPv4 LSP SESSION object with the
   difference that the extended tunnel ID may be set to a 16-byte
   identifier [RFC3209].

   Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       P2MP ID                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MUST be zero                 |      Tunnel ID                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Extended Tunnel ID (16 bytes)            |
      |                                                               |
      |                             .......                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

19.2.  SENDER_TEMPLATE Object

   The SENDER_TEMPLATE object contains the ingress LSR source address.
   The LSP ID can be changed to allow a sender to share resources with
   itself.  Thus, multiple instances of the P2MP tunnel can be created,
   each with a different LSP ID.  The instances can share resources with
   each other.  The S2L sub-LSPs corresponding to a particular instance
   use the same LSP ID.

   As described in section 4.2, it is necessary to distinguish different
   Path messages that are used to signal state for the same P2MP LSP by
   using a <Sub-Group ID Originator ID, Sub-Group ID> tuple.  The
   SENDER_TEMPLATE object is modified to carry this information as shown
   below.

Top      Up      ToC       Page 41 
19.2.1.  P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Reserved                |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Sub-Group Originator ID                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Reserved                |            Sub-Group ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 tunnel sender address
      See [RFC3209].

   Sub-Group Originator ID
      The Sub-Group Originator ID is set to the TE Router ID of the LSR
      that originates the Path message.  This is either the ingress LSR
      or an LSR which re-originates the Path message with its own Sub-
      Group Originator ID.

   Sub-Group ID
      An identifier of a Path message used to differentiate multiple
      Path messages that signal state for the same P2MP LSP.  This may
      be seen as identifying a group of one or more egress nodes
      targeted by this Path message.

   LSP ID
      See [RFC3209].

Top      Up      ToC       Page 42 
19.2.2.  P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                   IPv6 tunnel sender address                  |
      +                                                               +
      |                            (16 bytes)                         |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Reserved                |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                   Sub-Group Originator ID                     |
      +                                                               +
      |                            (16 bytes)                         |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Reserved                |            Sub-Group ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 tunnel sender address
      See [RFC3209].

   Sub-Group Originator ID
      The Sub-Group Originator ID is set to the IPv6 TE Router ID of the
      LSR that originates the Path message.  This is either the ingress
      LSR or an LSR which re-originates the Path message with its own
      Sub-Group Originator ID.

   Sub-Group ID
      As above in section 19.2.1.

   LSP ID
      See [RFC3209].

Top      Up      ToC       Page 43 
19.3.  S2L_SUB_LSP Object

   An S2L_SUB_LSP object identifies a particular S2L sub-LSP belonging
   to the P2MP LSP.

19.3.1.  S2L_SUB_LSP IPv4 Object

   S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv4 C-Type = 1

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 S2L Sub-LSP destination address        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Sub-LSP destination address
      IPv4 address of the S2L sub-LSP destination.

19.3.2.  S2L_SUB_LSP IPv6 Object

   S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv6 C-Type = 2

   This is the same as the S2L IPv4 Sub-LSP object, with the difference
   that the destination address is a 16-byte IPv6 address.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        IPv6 S2L Sub-LSP destination address (16 bytes)        |
      |                        ....                                   |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

19.4.  FILTER_SPEC Object

   The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
   object.

19.4.1.  P2MP LSP_IPv4 FILTER_SPEC Object

   Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = 12

   The format of the P2MP LSP_IPv4 FILTER_SPEC object is identical to
   the P2MP LSP_IPv4 SENDER_TEMPLATE object.

Top      Up      ToC       Page 44 
19.4.2.  P2MP LSP_IPv6 FILTER_SPEC Object

   Class = FILTER_SPEC, P2MP LSP_IPv6 C-Type = 13

   The format of the P2MP LSP_IPv6 FILTER_SPEC object is identical to
   the P2MP LSP_IPv6 SENDER_TEMPLATE object.

19.5.  P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO)

   The P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) is defined as
   identical to the ERO.  The class of the P2MP SERO is the same as the
   SERO defined in [RFC4873].  The P2MP SERO uses a new C-Type = 2.  The
   sub-objects are identical to those defined for the ERO.

19.6.  P2MP SECONDARY_RECORD_ROUTE Object (SRRO)

   The P2MP SECONDARY_RECORD_ROUTE Object (SRRO) is defined as identical
   to the ERO.  The class of the P2MP SRRO is the same as the SRRO
   defined in [RFC4873].  The P2MP SRRO uses a new C-Type = 2.  The
   sub-objects are identical to those defined for the RRO.

20.  IANA Considerations

20.1.  New Class Numbers

   IANA has assigned the following Class Numbers for the new object
   classes introduced.  The Class Types for each of them are to be
   assigned via standards action.  The sub-object types for the P2MP
   SECONDARY_EXPLICIT_ROUTE and P2MP_SECONDARY_RECORD_ROUTE follow the
   same IANA considerations as those of the ERO and RRO [RFC3209].

   50  Class Name = S2L_SUB_LSP

   C-Type
      1   S2L_SUB_LSP_IPv4 C-Type
      2   S2L_SUB_LSP_IPv6 C-Type

20.2.  New Class Types

   IANA has assigned the following C-Type values:

   Class Name = SESSION

   C-Type
     13    P2MP_LSP_TUNNEL_IPv4 C-Type
     14    P2MP_LSP_TUNNEL_IPv6 C-Type

Top      Up      ToC       Page 45 
   Class Name = SENDER_TEMPLATE

   C-Type
     12    P2MP_LSP_TUNNEL_IPv4 C-Type
     13    P2MP_LSP_TUNNEL_IPv6 C-Type

   Class Name = FILTER_SPEC

   C-Type
     12    P2MP LSP_IPv4 C-Type
     13    P2MP LSP_IPv6 C-Type

   Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])

   C-Type
      2  P2MP SECONDARY_EXPLICIT_ROUTE C-Type

   Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])

   C-Type
      2  P2MP_SECONDARY_RECORD_ROUTE C-Type

20.3.  New Error Values

   Five new Error Values are defined for use with the Error Code
   "Routing Problem".  IANA has assigned values for them as follows.

   The Error Value "Unable to Branch" indicates that a P2MP branch
   cannot be formed by the reporting LSR.  IANA has assigned value 23 to
   this Error Value.

   The Error Value "Unsupported LSP Integrity" indicates that a P2MP
   branch does not support the requested LSP integrity function.  IANA
   has assigned value 24 to this Error Value.

   The Error Value "P2MP Re-Merge Detected" indicates that a node has
   detected re-merge.  IANA has assigned value 25 to this Error Value.

   The Error Value "P2MP Re-Merge Parameter Mismatch" is described in
   section 18.  IANA has assigned value 26 to this Error Value.

   The Error Value "ERO Resulted in Re-Merge" is described in section
   18.  IANA has assigned value 27 to this Error Value.

Top      Up      ToC       Page 46 
20.4.  LSP Attributes Flags

   IANA has been asked to manage the space of flags in the Attributes
   Flags TLV carried in the LSP_REQUIRED_ATTRIBUTES object [RFC4420].
   This document defines a new flag as follows:

   Bit Number:                       3
   Meaning:                          LSP Integrity Required
   Used in Attributes Flags on Path: Yes
   Used in Attributes Flags on Resv: No
   Used in Attributes Flags on RRO:  No
   Referenced Section of this Doc:   5.2.4

21.  Security Considerations

   In principle this document does not introduce any new security issues
   above those identified in [RFC3209], [RFC3473], and [RFC4206].
   [RFC2205] specifies the message integrity mechanisms for hop-by-hop
   RSVP signaling.  These mechanisms apply to the hop-by-hop P2MP RSVP-
   TE signaling in this document.  Further, [RFC3473] and [RFC4206]
   specify the security mechanisms for non hop-by-hop RSVP-TE signaling.
   These mechanisms apply to the non hop-by-hop P2MP RSVP-TE signaling
   specified in this document, particularly in sections 16 and 17.

   An administration may wish to limit the domain over which P2MP TE
   tunnels can be established.  This can be accomplished by setting
   filters on various ports to deny action on a RSVP path message with a
   SESSION object of type P2MP_LSP_IPv4 or P2MP_LSP_IPv6.

   The ingress LSR of a P2MP TE LSP determines the leaves of the P2MP TE
   LSP based on the application of the P2MP TE LSP.  The specification
   of how such applications will use a P2MP TE LSP is outside the scope
   of this document.  Applications MUST provide a mechanism to notify
   the ingress LSR of the appropriate leaves for the P2MP LSP.
   Specifications of applications within the IETF MUST specify this
   mechanism in sufficient detail that an ingress LSR from one vendor
   can be used with an application implementation provided by another
   vendor.  Manual configuration of security parameters when other
   parameters are auto-discovered is generally not sufficient to meet
   security and interoperability requirements of IETF specifications.

Top      Up      ToC       Page 47 
22.  Acknowledgements

   This document is the product of many people.  The contributors are
   listed in Appendix B.

   Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger, and Nischal
   Sheth for their suggestions and comments.  Thanks also to Dino
   Farninacci and Benjamin Niven for their comments.

23.  References

23.1.  Normative References

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

   [RFC4420]     Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and
                 A. Ayyangar, "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.

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

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC3471]     Berger, L., Ed., "Generalized Multi-Protocol Label
                 Switching (GMPLS) Signaling Functional Description",
                 RFC 3471, January 2003.

   [RFC3473]     Berger, L., Ed., "Generalized Multi-Protocol Label
                 Switching (GMPLS) Signaling Resource ReserVation
                 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
                 3473, January 2003.

Top      Up      ToC       Page 48 
   [RFC2961]     Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
                 and S. Molendini, "RSVP Refresh Overhead Reduction
                 Extensions", RFC 2961, April 2001.

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

   [RFC4090]     Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed.,
                 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels",
                 RFC 4090, May 2005.

   [RFC3477]     Kompella, K. and Y. Rekhter, "Signalling Unnumbered
                 Links in Resource ReSerVation Protocol - Traffic
                 Engineering (RSVP-TE)", RFC 3477, January 2003.

   [RFC4873]     Berger, L., Bryskin, I., Papadimitriou, D., and A.
                 Farrel, "GMPLS Segment Recovery", RFC 4873, April 2007.

23.2. Informative References

   [RFC4461]     Yasukawa, S., Ed., "Signaling Requirements for Point-
                 to-Multipoint Traffic-Engineered MPLS Label Switched
                 Paths (LSPs)", RFC 4461, April 2006.

   [BFD]         Katz, D. and D. Ward, "Bidirectional Forwarding
                 Detection", Work in Progress, March 2007.

   [BFD-MPLS]    Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
                 "BFD for MPLS LSPs", Work in Progress, March 2007.

   [LSP-STITCH]  Ayyanger, A., Kompella, K., Vasseur, JP., and A.
                 Farrel, "Label Switched Path Stitching with Generalized
                 Multiprotocol Label Switching Traffic Engineering
                 (GMPLS TE)", Work in Progress, March 2007.

   [TE-NODE-CAP] Vasseur, JP., Ed., Le Roux, JL., Ed., "IGP Routing
                 Protocol Extensions for Discovery of Traffic
                 Engineering Node Capabilities", Work in Progress, April
                 2007.

   [RFC4003]     Berger, L., "GMPLS Signaling Procedure for Egress
                 Control", RFC 4003, February 2005.

Top      Up      ToC       Page 49 
Appendix A.  Example of P2MP LSP Setup

   The Following is one example of setting up a P2MP LSP using the
   procedures described in this document.

                   Source 1 (S1)
                     |
                    PE1
                   |   |
                   |L5 |
                   P3  |
                   |   |
                L3 |L1 |L2
       R2----PE3--P1   P2---PE2--Receiver 1 (R1)
                  | L4
          PE5----PE4----R3
                  |
                  |
                 R4

                Figure 2.

   The mechanism is explained using Figure 2.  PE1 is the ingress LSR.
   PE2, PE3, and PE4 are egress LSRs.

   a) PE1 learns that PE2, PE3, and PE4 are interested in joining a P2MP
      tree with a P2MP ID of P2MP ID1.  We assume that PE1 learns of the
      egress LSRs at different points in time.

   b) PE1 computes the P2P path to reach PE2.

   c) PE1 establishes the S2L sub-LSP to PE2 along <PE1, P2, PE2>.

   d) PE1 computes the P2P path to reach PE3 when it discovers PE3.
      This path is computed to share the same links where possible with
      the sub-LSP to PE2 as they belong to the same P2MP session.

   e) PE1 establishes the S2L sub-LSP to PE3 along <PE1, P3, P1, PE3>.

   f) PE1 computes the P2P path to reach PE4 when it discovers PE4.
      This path is computed to share the same links where possible with
      the sub-LSPs to PE2 and PE3 as they belong to the same P2MP
      session.

   g) PE1 signals the Path message for PE4 sub-LSP along <PE1, P3, P1,
      PE4>.

Top      Up      ToC       Page 50 
   h) P1 receives a Resv message from PE4 with label L4.  It had
      previously received a Resv message from PE3 with label L3.  It had
      allocated a label L1 for the sub-LSP to PE3.  It uses the same
      label and sends the Resv messages to P3.  Note that it may send
      only one Resv message with multiple flow descriptors in the flow
      descriptor list.  If this is the case, and FF style is used, the
      FF flow descriptor will contain the S2L sub-LSP descriptor list
      with two entries: one for PE4 and the other for PE3.  For SE
      style, the SE filter spec will contain this S2L sub-LSP descriptor
      list.  P1 also creates a label mapping of (L1 -> {L3, L4}).  P3
      uses the existing label L5 and sends the Resv message to PE1, with
      label L5.  It reuses the label mapping of {L5 -> L1}.

Appendix B.  Contributors

   John Drake
   Boeing
   EMail: john.E.Drake2@boeing.com

   Alan Kullberg
   Motorola Computer Group
   120 Turnpike Road 1st Floor
   Southborough, MA  01772
   EMail: alan.kullberg@motorola.com

   Lou Berger
   LabN Consulting, L.L.C.
   EMail: lberger@labn.net

   Liming Wei
   Redback Networks
   350 Holger Way
   San Jose, CA 95134
   EMail: lwei@redback.com

   George Apostolopoulos
   Redback Networks
   350 Holger Way
   San Jose, CA 95134
   EMail: georgeap@redback.com

   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089
   EMail: kireeti@juniper.net

Top      Up      ToC       Page 51 
   George Swallow
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough , MA - 01719
   USA
   EMail: swallow@cisco.com

   JP Vasseur
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough , MA - 01719
   USA
   EMail: jpv@cisco.com
   Dean Cheng
   Cisco Systems Inc.
   170 W Tasman Dr.
   San Jose, CA 95134
   Phone 408 527 0677
   EMail:  dcheng@cisco.com

   Markus Jork
   Avici Systems
   101 Billerica Avenue
   N. Billerica, MA 01862
   Phone: +1 978 964 2142
   EMail: mjork@avici.com

   Hisashi Kojima
   NTT Corporation
   9-11, Midori-Cho 3-Chome
   Musashino-Shi, Tokyo 180-8585 Japan
   Phone: +81 422 59 6070
   EMail: kojima.hisashi@lab.ntt.co.jp

   Andrew G. Malis
   Tellabs
   2730 Orchard Parkway
   San Jose, CA 95134
   Phone: +1 408 383 7223
   EMail: Andy.Malis@tellabs.com

   Koji Sugisono
   NTT Corporation
   9-11, Midori-Cho 3-Chome
   Musashino-Shi, Tokyo 180-8585 Japan
   Phone: +81 422 59 2605
   EMail: sugisono.koji@lab.ntt.co.jp

Top      Up      ToC       Page 52 
   Masanori Uga
   NTT Corporation
   9-11, Midori-Cho 3-Chome
   Musashino-Shi, Tokyo 180-8585 Japan
   Phone: +81 422 59 4804
   EMail: uga.masanori@lab.ntt.co.jp

   Igor Bryskin
   Movaz Networks, Inc.
   7926 Jones Branch Drive
   Suite 615
   McLean VA, 22102
   ibryskin@movaz.com
   Adrian Farrel
   Old Dog Consulting
   Phone: +44 0 1978 860944
   EMail: adrian@olddog.co.uk

   Jean-Louis Le Roux
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   EMail: jeanlouis.leroux@francetelecom.com

Editors' Addresses

   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   EMail: rahul@juniper.net

   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

   Dimitri Papadimitriou
   Alcatel
   Francis Wellesplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 240-8491
   EMail: Dimitri.Papadimitriou@alcatel-lucent.be

Top      Up      ToC       Page 53 
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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.

Intellectual Property

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.