RFC 4875
Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)
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.
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.
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
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.
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.
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.
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].
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].
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.
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-Type20.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
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.
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.421. 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.
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.
[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.
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>.
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
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
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.comEditors' 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
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.