Network Working Group Seisho Yasukawa Internet Draft NTT Category: Standards Track Expires: August 2006 February 2006 Supporting Multipoint-to-Point Label Switched Paths in Multiprotocol Label Switching Traffic Engineering draft-yasukawa-mpls-mp2p-rsvpte-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Traffic engineered Multiprotocol Label Switching (MPLS-TE) uses Resource Reservation Protocol traffic engineering extensions (RSVP-TE) as the signaling protocol to establish Label Switched Paths (LSPs). Although the Resource Reservation Protocol (RSVP) on which RSVP-TE is built supports the convergence of traffic flows toward a common destination, this concept has not been exploited in MPLS-TE which has been limited to point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. This document proposes extensions to RSVP-TE procedures and protocol elements to support multipoint-to-point (MP2P) LSPs. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Yasukawa Expires August 2006 [Page 1] draft-yasukawa-mpls-mp2p-rsvpte-00.txt February 2006 Contents 1. Introduction ................................................... 3 2. Description of MP2P MPLS-TE LSPs ............................... 3 2.1 Basic Requirements ............................................ 4 2.1.1 Non-Requirements ............................................ 6 2.2 Requirement for new Procedures and Extensions ................. 6 3. Procedures for Signaling MP2P MPLS-TE LSPs ..................... 7 3.1 Initial P2P LSP Establishment ................................. 7 3.2 Subsequent LSPs ............................................... 7 3.3 Processing at Merge Points .................................... 8 3.3.1 Determining that Merging is Allowed ......................... 8 3.3.2 Wildcard Filter Style ....................................... 8 3.3.3 Fixed Filter Style .......................................... 9 3.3.4 Shared Explicit Style ...................................... 10 3.3.5 Record Route Processing on Merged Path Messages ............ 11 3.4 Processing Downstream of a Merge Point ....................... 11 3.5 Processing at Egress LSRs .................................... 12 3.6 Resv Processing at Merge Points .............................. 12 3.7 LSP Teardown ................................................. 12 3.8 Make-Before-Break Support .................................... 12 4. Protocol Extensions ........................................... 13 4.1 Allowing MP2P LSP Merging .................................... 13 4.2 Message Formats .............................................. 13 4.2.1 Path Message ............................................... 13 4.2.2 PathErr Message ............................................ 14 5. Backward Compatibility ........................................ 14 5.1 Legacy LSRs .................................................. 15 5.2 Support of P2P and P2MP LSPs through an MP2P-enabled network . 15 6. Path Computation Considerations ............................... 15 7. Manageability Considerations .................................. 15 7.1 MIB Modules .................................................. 15 7.2 Operations and Management .................................... 16 8. Security Considerations ....................................... 16 9. IANA Considerations ........................................... 16 10. Acknowledgments .............................................. 16 11. References ................................................... 16 11.1 Normative References ........................................ 16 11.2 Informative References ...................................... 17 12. Author's Address ............................................. 18 13. Intellectual Property Statement .............................. 18 Yasukawa Expires August 2006 [Page 2] draft-yasukawa-mpls-mp2p-rsvpte-00.txt February 2006 1. Introduction The architecture for Multiprotocol Label Switching (MPLS) is described in [RFC3031]. The signaling for Label Switched Paths (LSPs) in MPLS traffic engineering (MPLS-TE) networks is achieved through specific extensions to the Resource Reservation Protocol (RSVP) defined in [RFC3209]. Although RSVP includes support for the convergence of traffic flows toward a common destination, the traffic engineering (TE) extensions to RSVP (RSVP-TE) do not leverage this fact, and [RFC3209] only includes support for point-to-point (P2P) LSPs. Additional extensions to RSVP-TE have been defined to support point-to-multipoint (P2MP) LSPs in [P2MP-RSVP]. Multipoint-to-point (MP2P) LSP tunnels offer certain benefits in a core MPLS network. For example, they reduce the amount of LSP state that protocol implementations must maintain within the network, and they may simplify the accounting and prioritization of traffic within individual routers. This document investigates how MP2P LSPs might be established using the protocol elements and procedures inherent in RSVP and RSVP-TE, and proposes new procedures and protocol elements where necessary. 2. Description of MP2P MPLS-TE LSPs MP2P MPLS-TE LSPs are transport tunnels within a core MPLS-TE network. An MP2P MPLS-TE LSP delivers traffic from multiple ingress Label Switching Routers (LSRs) to a single common egress LSR. Identification of the traffic carried by the tunnel with its originating ingress LSR is not within the scope of the MP2P LSP. Thus the MP2P LSP must be treated as an edge-to-edge tunnel much in the manner of hierarchical P2P LSPs described in [RFC4206]. For example, directed signaling can be used to exchange labels between egress and ingresses so that traffic from each ingress will use a different label on the label stack beneath the label used for the MP2P tunnel. LSP merging within the network can be carried out in an ad hoc way on any LSPs that are allowed to be merged. The judgment on whether two LSPs can be merged is dependent on: - are the LSPs to the same destination - do the ingresses allow these LSPs to be merged - are the explicit routes downstream of the merge point consistent with merging - is the merge point capable of performing merging - are the bandwidth implications of merging supported by the downstream network. Yasukawa Expires August 2006 [Page 3] draft-yasukawa-mpls-mp2p-rsvpte-00.txt February 2006 The ad hoc way of MP2P LSP establishment means that upstream segments of the MP2P tree are added as new ingress to egress LSPs are signaled and coincide with (discover) other existing LSPs to the same egress that can be merged according to the above criterions. Two models to manage the bandwidth of merged LSPs may be considered. - The new upstream segment may be spliced into the MP2P LSP and the additional bandwidth required for the traffic from the new ingress is added to the bandwidth request for the downstream segment. This is most appropriate for MP2P tunnels carrying unassociated traffic from the ingress LSRs. - The new upstream segment may be spliced into the MP2P LSP and use (share) the existing bandwidth on the downstream segment. This may be appropriate for certain specific applications where individual ingresses send data one at a time (for example, voice conferencing). Additionally, two models of notification to the egress of merging may be considered. - When a new upstream segment is spliced into an MP2P LSP the new ingress LSR is reported to the egress so that it knows all of the ingress LSRs on the MP2P tree. This is suitable to some uses of the MP2P LSP as a tunnel where forwarding adjacencies (FAs, see [RFC4206]) are managed between the end points. - When a new upstream segment is spliced into an MP2P LSP no further downstream signaling is required and the ingress is told that it is connected to the egress. This may be particularly suited to bandwidth sharing applications. The combination of these two sets of models gives four options for signaling MP2P LSPs downstream of a merge point. 2.1 Basic Requirements This section lists the basic functional requirements that the signaling must support. a. Control of merging function The ingress LSR MUST be able to specify through signaling whether a LSP may be merged into an MP2P LSP or not. This can currently be achieved using the Session object defined in [RFC3209]. b. Identification of LSPs that can be merged. Transit LSRs that are capable of merging LSPs into the MP2P tree MUST be able to distinguish which LSPs can be merged and which are to remain distinct. The merging rules of [RFC2205] allow merging Yasukawa Expires August 2006 [Page 4] draft-yasukawa-mpls-mp2p-rsvpte-00.txt February 2006 based on an identical Session object, and this rule can be applied with the Session object as modified by [RFC3209]. c. Resource sharing downstream of merge points It is a requirement that the single LSP segment downstream of a merge point MUST have sufficient bandwidth allocated to support all traffic from the LSP segments upstream of the merge point, and that that traffic MUST be able to share the bandwidth on the downstream segment. This requirement can be met using the features of RSVP [RFC2205] where TSpecs for different sender are forwarded to the egress in separate Path messages and combined into a single Flowspec that is returned on a Resv message. d. Explicit route control It is a requirement that the ingress LSR MUST be able to control the route of the LSP from source to destination. This feature is provided by the Explicit Route object of [RFC3209] in conjunction with merging rules described in this document. e. Label allocation Label allocation MUST be supported with a single label on a merged downstream segment and individual labels on upstream segments. No changes to [RFC3209] are required for this function except to clarify how labels are carried on Resv messages where multiple FilterSpecs are used, and to clarify how Label Forwarding Information Bases (LFIBs) are programmed at merge points. f. LSP identification Each LSP MUST be uniquely identifiable within the network. Further, in order to support diagnostics and OAM, a single identifier MUST be used on the LSP for the whole of its path between any ingress and the egress. Additionally, a single identifier SHOULD be used for the MP2P across the whole of the LSP tree. g. Coordination between ingress LSRs MP2P operation MUST be possible with minimal or zero coordination between ingress LSRs. It is not acceptable to require configuration at each ingress LSR in order to specify which other ingress LSRs may join the same MP2P LSP (for example, through identifying a group). It is acceptable to require: - Specific configuration for an individual LSP that it will support MP2P merging (see requirement a.) - Network-wide configuration of identifiers of "classes" of LSP that may be merged. Yasukawa Expires August 2006 [Page 5] draft-yasukawa-mpls-mp2p-rsvpte-00.txt February 2006 This requirement is hard to reconcile with previous requirements and the assumed use of [RFC2205] and [RFC3209] procedures. In order to control merging, the Session object of all upstream segments are required to be the same [RFC2205], but this means that the Tunnel ID and Extended Tunnel ID must be coordinated. It might be possible to reserve certain Tunnel ID and Extended Tunnel ID values to indicate MP2P merging, but this seems impractical and unscalable. The alternative (adopted in this document) is to define different rules for when LSP merging is allowed. h. Identification of senders at egress. It MUST be possible for the egress LSR to determine all of the ingress LSRs attached to the MP2P LSP. This requires that signaling information from each ingress is passed to the egress either in its own Path message or through some form of merging of signaling information into a single message. i. Route recording It MUST be possible to record the path followed by the MP2P LSP and pass this information to the end points. The ingress only requires to know the path from the ingress to the egress. The egress requires to know the path from each ingress to the egress. The route reported to the ingress SHOULD indicate which LSRs on the route are currently acting as MP2P merge points. Some form of information aggregation technique SHOULD be used in reporting the recorded route to the egress so that hops that are common in the tree form multiple ingress LSRs (that is, hops downstream of the merge point) SHOULD NOT be repeated in the information present in the signaling message (Path message). 2.1.1 Non-Requirements No ingress is required to know of the existence of other ingresses in the MP2P LSP. 2.2 Requirement for new Procedures and Extensions Section 2.1 summarizes the signaling requirements and shows how many of the requirements can be met using the merging techniques of [RFC2205] and the LSP identification techniques of [RFC3209]. But the last requirements (g, h and i) cannot be met using these techniques. Thus new procedures and extensions are needed. The remainder of this document introduces new procedures and extensions to support signaling MP2P LSPs. Yasukawa Expires August 2006 [Page 6] draft-yasukawa-mpls-mp2p-rsvpte-00.txt February 2006 3. Procedures for Signaling MP2P MPLS-TE LSPs The procedures described here are modeled on the reservation styles described in [RFC2205]. Further, many ideas are taken from the way that FlowSpecs and FilterSpecs may be combined on Resv messages in [RFC2205] in recognition that the Resv message in [RFC2205] is creating an MP2P flow tree. Additions are made to allow control of this MP2P behavior on the Path message. The advantage of this over the [RFC2205] techniques is that merging is explicitly announced and is the responsibility of the merge point not of the egress. 3.1 Initial P2P LSP Establishment The initial LSP is signaled as a normal point-to-point LSP would be. The ingress LSP cannot know whether future upstream segments will be merged into this LSP or not. However, the LSP is flagged by the ingress to say whether MP2P merging is allowed using a new flag in the LSP_ATTRIBUTES object in the Path message. If this flag is not set or is absent, the LSP is treated as a normal P2P LSP. If MP2P merging is allowed by the ingress, the Path message MUST also include the Style object. The Style object was previously only allowed on a Resv message, [RFC2205]. The Style object directs the merging procedure that is performed at any merge point as described in section 3.3. When the ingress LSR allows MP2P merging it SHOULD set the Extended Tunnel ID in the Session object to a well-known value. The value of zero SHOULD be used to allow general merging with other LSPs. Other non-zero values MAY be defined according to administrative policy for the network to restrict the LSPs that may be merged, perhaps according to service or application classification. It is RECOMMENDED that only values that do not match valid IP addresses are used for this function since [RFC3209] suggests the use of the sender's IP address in this field for P2P LSPs. Other procedures and encodings are unchanged from [RFC3209]. 3.2 Subsequent LSPs Subsequent LSPs are actually identical to initial LSPs described in the previous section. The ingress LSR is not aware whether other LSPs already exist and MP2P merging will happen. Therefore the ingress LSR builds its Path message as already described. Yasukawa Expires August 2006 [Page 7] draft-yasukawa-mpls-mp2p-rsvpte-00.txt February 2006 3.3 Processing at Merge Points The main difference for MP2P LSP support takes place at the merge points. Much of the processing depends on the setting of the Style object carried in the received Path messages. 3.3.1 Determining that Merging is Allowed When an LSR receives a Path message with the MP2P flag set indicating that MP2P merging is allowed for the LSP, and if the LSR is capable of supporting MP2P merging it performs the following checks to determine an existing LSP with which to merge. - Search all LSP state for LSPs that are allowed to be merged (that is, that were signaled with the MP2P flag set). - Find any LSPs that have a common destination set in the Session object and that have the same Extended Tunnel ID in the Session object. Note that the Tunnel ID, Sender and LSP ID do not form part of this check. - Select those LSPs that have compatible downstream explicit routes. In this context, an explicit route is compatible if the path of the existing LSP satisfies the Explicit Route object (ERO) carried in the new Path message. - Select those LSPs that were signaled with the same value of the Style object. - Select those LSPs for which MP2P merging is allowed according to local policy (possibly using the contents of the Policy object signaled in the received Path messages). This choice MAY include consideration of the hardware capabilities of the merging LSR. - If more than one LSP is still a candidate for merging select the best LSP to merge according to local policy. If no merge candidate is found the LSR processes the Path message as normal according to [RFC3209]. If an LSP is found merging proceeds according to the reservation style carried in the Style object. 3.3.2 Wildcard Filter Style In [RFC2205] the Wildcard Filter (WF) reservation style allows sharing between all traffic in the same session, that is, to the same destination. Just as in [RFC2205], the WF M2MP LSP may be thought of as a shared Yasukawa Expires August 2006 [Page 8] draft-yasukawa-mpls-mp2p-rsvpte-00.txt February 2006 "pipe", whose "size" is the largest of the resource requests, independent of the number of senders using it. In other words, a WF style indicates that resource sharing occurs downstream of the merge point and this style is applicable to resource sharing applications such as voice-conferencing. A merge LSR that receives a Path message for a second LSP carries out the following processing. - If the new LSP requests bandwidth less than or equal to the bandwidth already allocated downstream for the existing LSP, the merge point immediately generates a Resv for the new LSP, allocates a label on the new upstream segment, and sends the Resv upstream following normal rules from [RFC3209]. The merge LSR installs an entry in the LFIB mapping the new label on the new upstream interface, to the existing label on the downstream interface for the MP2P LSP so that the new LSP is spliced into the MP2P LSP. - If the new LSP requests bandwidth greater than the bandwidth already allocated downstream for the existing LSP, the merge LSR sends a trigger Path message downstream with a TSpec that requests increased bandwidth. If a Resv message is later received indicating that the required bandwidth has been allocated, the merge LSR builds and sends a Resv upstream for the new LSP segment only (no new Resv is sent upstream for the previously existing LSP segments). If the requested bandwidth is not made available, the merge LSR sends a PathErr message upstream on the new LSP segment just as it would if normal LSP setup had failed owing to lack of resources [RFC3209]. In this mode of operation, the egress does not become aware when new ingress LSRs are spliced into the MP2P tree. 3.3.3 Fixed Filter Style In [RFC2205] the Fixed Filter (FF) style implies distinct reservations for each flow in the session. For MP2P LSPs this means that common labels are used on the shared downstream segments, but a separate pool of resource is allocated for each ingress LSR (sender) that shares the MP2P tree. The consequence is that each LSP (that is, each LSP from each ingress) must be signaled all the way to the egress carrying a distinct LSP identifier and TSpec. Although a possible approach is to send a separate Path message for each such LSP (which would be the technique used in [RFC2205]) this cannot be done because it would leave the choice of MP2P merging to the egress LSR. This situation is Yasukawa Expires August 2006 [Page 9] draft-yasukawa-mpls-mp2p-rsvpte-00.txt February 2006 OK in [RFC2205] where all routers are capable of merging flows, but is not suitable in MP2P MPLS-TE because the merge node needs control of whether merging is performed. Therefore, the solution is to merge the Path messages. The Path message for the first LSP is processed as normal (see section 3.1), but once merging has been chosen, the incoming Path message for the second LSP is merged, and the trigger Path message sent downstream contains information about both senders. The mechanism used to achieve this mirrors the information that will be carried on the Resv. An is used to provide a list of Sender Template objects each of which is accompanied by a TSpec. AdSpec and Record Route objects may also be present. The MUST NOT be present unless the Style object is present and contains the FF setting. However, the observant reader will note that an with only one element is identical to the defined in [RFC3209] and used for P2P signaling. Each in the is copied from the on a received Path message. Thus all information from received Path messages is conveyed to the egress LSR. 3.3.4 Shared Explicit Style [RFC2205] describes the Shared Explicit (SE) style as creating a single reservation that is shared by selected upstream senders. Unlike the WF style, the SE style requires that the senders that share the style are explicitly identified, and so each LSP that is joined to the MP2P LSP needs to be signaled to the egress. The solution is also modeled on the SE signaling used in the Resv message in [RFC2205]. An is used to provide a list of Sender Template objects that are associated with a single TSpec. AdSpec and Record Route objects may also be present. The MUST NOT be present unless the Style object is present and contains the SE setting. However, the observant reader will note that an with only one element is identical to the defined in [RFC3209] and used for P2P signaling. Each Sender Template and any Record Route or AdSpec object in the is copied from the a received Path message. Thus all information from received Path messages is conveyed to the egress LSR. But the traffic parameters in the Sender TSpec object are summed to ensure that sufficient bandwidth is allocated on the downstream leg. Yasukawa Expires August 2006 [Page 10] draft-yasukawa-mpls-mp2p-rsvpte-00.txt February 2006 3.3.5 Record Route Processing on Merged Path Messages The route of an LSP can be recorded in a Record Route object (RRO) included in a Path message [RFC3209]. There is no change to this procedure up to the merge point for two LSPs. Downstream of the merge point, the Path message can include multiple RROs: one for each Sender Template object. The presence rules for these RROs is that they exist in the for a merged LSP in a Path message downstream of the merge point if and only if the RRO existed in the Path message for the LSP upstream of the merge point. Note that continuing to record the route of an LSP in all RROs in a Path message would result in duplicate information that might make the Path message too large for convenient processing. In order to avoid such duplicate information the following three rules MUST be applied: - When creating a for transmission in a Path message to a downstream LSR the merge LSR MUST include an RRO in a if there is one in the corresponding in the Path message received from upstream. - When creating a for transmission in a Path message to a downstream LSR, if any includes an RRO the merge LSR MUST ensure that the first contains an RRO. This MUST be achieved by appropriate ordering of items and MUST NOT be achieved by inserting an RRO into a that would not otherwise include an RRO. - When adding route record information to a Path message, an LSR MUST add the information only to the first RRO in the Path message. Thus RROs in Path messages start at ingress LSRs and end at merge LSRs, except for the first RRO in the Path message that ends at the egress LSR. 3.4 Processing Downstream of a Merge Point No special processing for Path messages is necessary at an LSR downstream of a merge LSR except for the following points. - RROs MUST be handled as described in the previous section. - Resources should be checked based on the contents of the Style object. Yasukawa Expires August 2006 [Page 11] draft-yasukawa-mpls-mp2p-rsvpte-00.txt February 2006 3.5 Processing at Egress LSRs Egress LSRs are responsible for converting TSpec objects on Path messages into FlowSpec objects on Resv messages. The rules for doing this are inherited from [RFC2205] and [RFC3209] applying the information received in Path the messages including the value set in the Style object. 3.6 Resv Processing at Merge Points Resv messages need careful handling at merge points. The contents of the Resv needs to be split and sent upstream in separate Resv messages according to the Path messages that were received. The on the Resv is simply split according to the received on the Path messages. Where bandwidth is shared on downstream links, the merge LSR makes appropriate decisions for how much bandwidth to allocate on the upstream links according to the TSpecs received in the Path messages. Where bandwidth is allocated per sender, this is simply copied from the received Resv to the outgoing Resvs. Note that a RRO MUST NOT be included in a Resv sent upstream from a merge LSR unless an RRO was received in the corresponding Path message. 3.7 LSP Teardown When an ingress LSR decides to tear an LSP down it sends a PathTear message. This message is propagated as per [RFC3209] until it reaches a merge LSR. - If the PathTear is removing the last upstream segment then this is not really a merge LSR, and the PathTear MUST be forwarded towards the egress as normal. - If the LSP uses the WF style, the PathTear MUST be terminated at the merge LSR. If the result of removing the associated sender is a reduction in the amount of required resource on the downstream LSP, the merge LSR MAY send a trigger Path message with a new TSpec. - If the LSP uses the FF or SE style, the PathTear MUST be terminated at the merge LSR and a trigger Path message MUST be sent downstream with the associated removed. 3.8 Make-Before-Break Support Make-before-break is an important aspect of MPLS-TE that allows LSPs to be re-routed in a "hitless" way. Yasukawa Expires August 2006 [Page 12] draft-yasukawa-mpls-mp2p-rsvpte-00.txt February 2006 The integration of make-before-break with MP2P LSPs is for future study. 4. Protocol Extensions This section describes the protocol extensions and changes to message encodings required to support the function described in section 3. 4.1 Allowing MP2P LSP Merging An ingress LSR may allow M2MP LSP merging by setting the "MP2P Merge Allowed" flag at bit number xx (TBD by IANA) in the LSP Attributes TLV carried in the LSP_ATTRIBUTES object [LSP-ATTRIB] in the Path message that it sends for this LSP. The LSP_ATTRIBUTES object is used rather than the LSP_REQUIRED_ATTRIBUTES object because transit LSRs that do not support MP2P LSP merging are not required to take any action. An LSR that recognizes the LSP_ATTRIBUTES object, but does not recognize the MP2P Merge Allowed flag will ignore the flag according to the processing rules in [LSP-ATTRIB], and MUST forward the flag unmodified in any Path message that it sends for this LSP. An LSR that recognizes the LSP_ATTRIBUTES object and the MP2P Merge Allowed flag, but which does not support MP2P LSP merging or does not wish to support MP2P merging for the signaled LSP MUST forward the flag unmodified in any Path message that it sends for this LSP. 4.2 Message Formats As described in section 3, some changes are required to the existing RSVP-TE message formats. These are shown in the sections that follow. The following messages are not changed by this document. - PathTear - Resv - ResvTear - ResvErr - ResvConf 4.2.1 Path Message The Path message is extended by the optional inclusion of the Style object. If this object is present the is replaced by a . Yasukawa Expires August 2006 [Page 13] draft-yasukawa-mpls-mp2p-rsvpte-00.txt February 2006 ::= [ ] [ ] [ ] [ ] [ ... ] |