Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4875

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

Pages: 53
Proposed Standard
Errata
Updated by:  6510
Part 3 of 3 – Pages 35 to 53
First   Prev   None

Top   ToC   RFC4875 - Page 35   prevText

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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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   ToC   RFC4875 - 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.