RFC4875 Extensions to Resource Reservation Protocol - Traffic Engineering(RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)
4875 Extensions to Resource Reservation Protocol - Traffic Engineering(RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs). R.Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.. May 2007. (Format: TXT=125394 bytes) (Status: PROPOSED STANDARD)
日本語訳
RFC一覧
参照
Network Working Group R. Aggarwal, Ed. Request for Comments: 4875 Juniper Networks Category: Standards Track D. Papadimitriou, Ed. Alcatel S. Yasukawa, Ed. NTT May 2007 Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. Aggarwal, et al. Standards Track [Page 1] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007 Table of Contents 1. Introduction ....................................................4 2. Conventions Used in This Document ...............................4 3. Terminology .....................................................4 4. Mechanism .......................................................5 4.1. P2MP Tunnels ...............................................5 4.2. P2MP LSP ...................................................5 4.3. Sub-Groups .................................................5 4.4. S2L Sub-LSPs ...............................................6 4.4.1. Representation of an S2L Sub-LSP ....................6 4.4.2. S2L Sub-LSPs and Path Messages ......................7 4.5. Explicit Routing ...........................................7 5. Path Message ....................................................9 5.1. Path Message Format ........................................9 5.2. Path Message Processing ...................................11 5.2.1. Multiple Path Messages .............................11 5.2.2. Multiple S2L Sub-LSPs in One Path Message ..........12 5.2.3. Transit Fragmentation of Path State Information ....14 5.2.4. Control of Branch Fate Sharing .....................15 5.3. Grafting ..................................................15 6. Resv Message ...................................................16 6.1. Resv Message Format .......................................16 6.2. Resv Message Processing ...................................17 6.2.1. Resv Message Throttling ............................18 6.3. Route Recording ...........................................19 6.3.1. RRO Processing .....................................19 6.4. Reservation Style .........................................19 7. PathTear Message ...............................................20 7.1. PathTear Message Format ...................................20 7.2. Pruning ...................................................20 7.2.1. Implicit S2L Sub-LSP Teardown ......................20 7.2.2. Explicit S2L Sub-LSP Teardown ......................21 8. Notify and ResvConf Messages ...................................21 8.1. Notify Messages ...........................................21 8.2. ResvConf Messages .........................................23 9. Refresh Reduction ..............................................24 10. State Management ..............................................24 10.1. Incremental State Update .................................25 10.2. Combining Multiple Path Messages .........................25 11. Error Processing ..............................................26 11.1. PathErr Messages .........................................27 11.2. ResvErr Messages .........................................27 11.3. Branch Failure Handling ..................................28 12. Admin Status Change ...........................................29 13. Label Allocation on LANs with Multiple Downstream Nodes .......29 Aggarwal, et al. Standards Track [Page 2] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007 14. P2MP LSP and Sub-LSP Re-Optimization ..........................29 14.1. Make-before-Break ........................................29 14.2. Sub-Group-Based Re-Optimization ..........................29 15. Fast Reroute ..................................................30 15.1. Facility Backup ..........................................31 15.1.1. Link Protection ...................................31 15.1.2. Node Protection ...................................31 15.2. One-to-One Backup ........................................32 16. Support for LSRs That Are Not P2MP Capable ....................33 17. Reduction in Control Plane Processing with LSP Hierarchy ......34 18. P2MP LSP Re-Merging and Cross-Over ............................35 18.1. Procedures ...............................................36 18.1.1. Re-Merge Procedures ...............................36 19. New and Updated Message Objects ...............................39 19.1. SESSION Object ...........................................39 19.1.1. P2MP LSP Tunnel IPv4 SESSION Object ...............39 19.1.2. P2MP LSP Tunnel IPv6 SESSION Object ...............40 19.2. SENDER_TEMPLATE Object ...................................40 19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object .......41 19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object .......42 19.3. S2L_SUB_LSP Object .......................................43 19.3.1. S2L_SUB_LSP IPv4 Object ...........................43 19.3.2. S2L_SUB_LSP IPv6 Object ...........................43 19.4. FILTER_SPEC Object .......................................43 19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object ..................43 19.4.2. P2MP LSP_IPv6 FILTER_SPEC Object ..................44 19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) ..............44 19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO) ................44 20. IANA Considerations ...........................................44 20.1. New Class Numbers ........................................44 20.2. New Class Types ..........................................44 20.3. New Error Values .........................................45 20.4. LSP Attributes Flags .....................................46 21. Security Considerations .......................................46 22. Acknowledgements ..............................................47 23. References ....................................................47 23.1. Normative References .....................................47 23.2. Informative References ...................................48 Appendix A. Example of P2MP LSP Setup .............................49 Appendix B. Contributors ..........................................50 Aggarwal, et al. Standards Track [Page 3] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007 1. Introduction [RFC3209] defines a mechanism for setting up point-to-point (P2P) Traffic Engineered (TE) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. [RFC3473] defines extensions to [RFC3209] for setting up P2P TE LSPs in Generalized MPLS (GMPLS) networks. However these specifications do not provide a mechanism for building point-to-multipoint (P2MP) TE LSPs. This document defines extensions to the RSVP-TE protocol ([RFC3209] and [RFC3473]) to support P2MP TE LSPs satisfying the set of requirements described in [RFC4461]. This document relies on the semantics of the Resource Reservation Protocol (RSVP) that RSVP-TE inherits for building P2MP LSPs. A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between the ingress and egress LSRs and are appropriately combined by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. One Path message may signal one or multiple S2L sub-LSPs for a single P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP LSP can be signaled using one Path message or split across multiple Path messages. There are various applications for P2MP TE LSPs and the signaling techniques described in this document can be used, sometimes in combination with other techniques, to support different applications. Specification of how applications will use P2MP TE LSPs and how the paths of P2MP TE LSPs are computed is outside the scope of this document. 2. 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]. 3. Terminology This document uses terminologies defined in [RFC2205], [RFC3031], [RFC3209], [RFC3473], [RFC4090], and [RFC4461]. Aggarwal, et al. Standards Track [Page 4] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007 4. Mechanism This document describes a solution that optimizes data replication by allowing non-ingress nodes in the network to be replication/branch nodes. A branch node is an LSR that replicates the incoming data on to one or more outgoing interfaces. The solution relies on RSVP-TE in the network for setting up a P2MP TE LSP. The P2MP TE LSP is set up by associating multiple S2L sub-LSPs and relying on data replication at branch nodes. This is described further in the following sub-sections by describing P2MP tunnels and how they relate to S2L sub-LSPs. 4.1. P2MP Tunnels The defining feature of a P2MP TE LSP is the action required at branch nodes where data replication occurs. Incoming MPLS labeled data is replicated to outgoing interfaces which may use different labels for the data. A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is identified by a P2MP SESSION object. This object contains the identifier of the P2MP Session, which includes the P2MP Identifier (P2MP ID), a tunnel Identifier (Tunnel ID), and an extended tunnel identifier (Extended Tunnel ID). The P2MP ID is a four-octet number and is unique within the scope of the ingress LSR. Thetuple provides an identifier for the set of destinations of the P2MP TE Tunnel. The fields of the P2MP SESSION object are identical to those of the SESSION object defined in [RFC3209] except that the Tunnel Endpoint Address field is replaced by the P2MP ID field. The P2MP SESSION object is defined in section 19.1 4.2. P2MP LSP A P2MP LSP is identified by the combination of the P2MP ID, Tunnel ID, and Extended Tunnel ID that are part of the P2MP SESSION object, and the tunnel sender address and LSP ID fields of the P2MP SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is defined in section 19.2. 4.3. Sub-Groups As with all other RSVP controlled LSPs, P2MP LSP state is managed using RSVP messages. While the use of RSVP messages is the same, P2MP LSP state differs from P2P LSP state in a number of ways. A Aggarwal, et al. Standards Track [Page 5] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007 P2MP LSP comprises multiple S2L Sub-LSPs, and as a result of this, it may not be possible to represent full state in a single IP packet. It must also be possible to efficiently add and remove endpoints to and from P2MP TE LSPs. An additional issue is that the P2MP LSP must also handle the state "re-merge" problem, see [RFC4461] and section 18. These differences in P2MP state are addressed through the addition of a sub-group identifier (Sub-Group ID) and sub-group originator (Sub- Group Originator ID) to the SENDER_TEMPLATE and FILTER_SPEC objects. Taken together, the Sub-Group ID and Sub-Group Originator ID are referred to as the Sub-Group fields. The Sub-Group fields, together with the rest of the SENDER_TEMPLATE and SESSION objects, are used to represent a portion of a P2MP LSP's state. This portion of a P2MP LSP's state refers only to signaling state and not data plane replication or branching. For example, it is possible for a node to "branch" signaling state for a P2MP LSP, but to not branch the data associated with the P2MP LSP. Typical applications for generation and use of multiple sub-groups are (1) addition of an egress and (2) semantic fragmentation to ensure that a Path message remains within a single IP packet. 4.4. S2L Sub-LSPs A P2MP LSP is constituted of one or more S2L sub-LSPs. 4.4.1. Representation of an S2L Sub-LSP An S2L sub-LSP exists within the context of a P2MP LSP. Thus, it is identified by the P2MP ID, Tunnel ID, and Extended Tunnel ID that are part of the P2MP SESSION, the tunnel sender address and LSP ID fields of the P2MP SENDER_TEMPLATE object, and the S2L sub-LSP destination address that is part of the S2L_SUB_LSP object. The S2L_SUB_LSP object is defined in section 19.3. An EXPLICIT_ROUTE Object (ERO) or P2MP_SECONDARY_EXPLICIT_ROUTE Object (SERO) is used to optionally specify the explicit route of a S2L sub-LSP. Each ERO or SERO that is signaled corresponds to a particular S2L_SUB_LSP object. Details of explicit route encoding are specified in section 4.5. The SECONDARY_EXPLICIT_ROUTE Object is defined in [RFC4873], a new P2MP SECONDARY_EXPLICIT_ROUTE Object C-type is defined in section 19.5, and a matching P2MP_SECONDARY_RECORD_ROUTE Object C-type is defined in section 19.6. Aggarwal, et al. Standards Track [Page 6] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007 4.4.2. S2L Sub-LSPs and Path Messages The mechanism in this document allows a P2MP LSP to be signaled using one or more Path messages. Each Path message may signal one or more S2L sub-LSPs. Support for multiple Path messages is desirable as one Path message may not be large enough to contain all the S2L sub-LSPs; and they also allow separate manipulation of sub-trees of the P2MP LSP. The reason for allowing a single Path message to signal multiple S2L sub-LSPs is to optimize the number of control messages needed to set up a P2MP LSP. 4.5. Explicit Routing When a Path message signals a single S2L sub-LSP (that is, the Path message is only targeting a single leaf in the P2MP tree), the EXPLICIT_ROUTE object encodes the path to the egress LSR. The Path message also includes the S2L_SUB_LSP object for the S2L sub-LSP being signaled. The < [ ], > tuple represents the S2L sub-LSP and is referred to as the sub-LSP descriptor. The absence of the ERO should be interpreted as requiring hop-by-hop routing for the sub-LSP based on the S2L sub-LSP destination address field of the S2L_SUB_LSP object. When a Path message signals multiple S2L sub-LSPs, the path of the first S2L sub-LSP to the egress LSR is encoded in the ERO. The first S2L sub-LSP is the one that corresponds to the first S2L_SUB_LSP object in the Path message. The S2L sub-LSPs corresponding to the S2L_SUB_LSP objects that follow are termed as subsequent S2L sub- LSPs. The path of each subsequent S2L sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object (SERO). The format of the SERO is the same as an ERO (as defined in [RFC3209] and [RFC3473]). Each subsequent S2L sub-LSP is represented by tuples of the form < [ ], >. An SERO for a particular S2L sub-LSP includes only the path from a branch LSR to the egress LSR of that S2L sub-LSP. The branch MUST appear as an explicit hop in the ERO or some other SERO. The absence of an SERO should be interpreted as requiring hop-by-hop routing for that S2L sub-LSP. Note that the destination address is carried in the S2L sub-LSP object. The encoding of the SERO and S2L_SUB_LSP object is described in detail in section 19. In order to avoid the potential repetition of path information for the parts of S2L sub-LSPs that share hops, this information is deduced from the explicit routes of other S2L sub-LSPs using explicit route compression in SEROs. Aggarwal, et al. Standards Track [Page 7] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007 A | | B | | C----D----E | | | | | | F G H-------I | |\ | | | \ | J K L M | | | | | | | | N O P Q--R Figure 1. Explicit Route Compression Figure 1 shows a P2MP LSP with LSR A as the ingress LSR and six egress LSRs: (F, N, O, P, Q and R). When all six S2L sub-LSPs are signaled in one Path message, let us assume that the S2L sub-LSP to LSR F is the first S2L sub-LSP, and the rest are subsequent S2L sub- LSPs. The following encoding is one way for the ingress LSR A to encode the S2L sub-LSP explicit routes using compression: S2L sub-LSP-F: ERO = {B, E, D, C, F}, object-F S2L sub-LSP-N: SERO = {D, G, J, N}, object-N S2L sub-LSP-O: SERO = {E, H, K, O}, object-O S2L sub-LSP-P: SERO = {H, L, P}, object-P S2L sub-LSP-Q: SERO = {H, I, M, Q}, object-Q S2L sub-LSP-R: SERO = {Q, R}, object-R After LSR E processes the incoming Path message from LSR B it sends a Path message to LSR D with the S2L sub-LSP explicit routes encoded as follows: S2L sub-LSP-F: ERO = {D, C, F}, object-F S2L sub-LSP-N: SERO = {D, G, J, N}, object-N LSR E also sends a Path message to LSR H, and the following is one way to encode the S2L sub-LSP explicit routes using compression: S2L sub-LSP-O: ERO = {H, K, O}, object-O S2L sub-LSP-P: SERO = {H, L, P}, S2L_SUB_LSP object-P S2L sub-LSP-Q: SERO = {H, I, M, Q}, object-Q S2L sub-LSP-R: SERO = {Q, R}, object-R Aggarwal, et al. Standards Track [Page 8] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007 After LSR H processes the incoming Path message from E, it sends a Path message to LSR K, LSR L, and LSR I. The encoding for the Path message to LSR K is as follows: S2L sub-LSP-O: ERO = {K, O}, object-O The encoding of the Path message sent by LSR H to LSR L is as follows: S2L sub-LSP-P: ERO = {L, P}, object-P The following encoding is one way for LSR H to encode the S2L sub-LSP explicit routes in the Path message sent to LSR I: S2L sub-LSP-Q: ERO = {I, M, Q}, object-Q S2L sub-LSP-R: SERO = {Q, R}, object-R The explicit route encodings in the Path messages sent by LSRs D and Q are left as an exercise for the reader. This compression mechanism reduces the Path message size. It also reduces extra processing that can result if explicit routes are encoded from ingress to egress for each S2L sub-LSP. No assumptions are placed on the ordering of the subsequent S2L sub-LSPs and hence on the ordering of the SEROs in the Path message. All LSRs need to process the ERO corresponding to the first S2L sub-LSP. An LSR needs to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP only if the first hop in the corresponding SERO is a local address of that LSR. The branch LSR that is the first hop of an SERO propagates the corresponding S2L sub-LSP downstream. 5. Path Message 5.1. Path Message Format This section describes modifications made to the Path message format as specified in [RFC3209] and [RFC3473]. The Path message is enhanced to signal one or more S2L sub-LSPs. This is done by including the S2L sub-LSP descriptor list in the Path message as shown below. Aggarwal, et al. Standards Track [Page 9] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007 ::= [ ] [ [ | ] ...] [ ] [ ] [ ] [ ... ] [ ] [ ] [ ] [ ... ] [ ] The following is the format of the S2L sub-LSP descriptor list. ::= [ ] ::= [ ] Each LSR MUST use the common objects in the Path message and the S2L sub-LSP descriptors to process each S2L sub-LSP represented by the S2L_SUB_LSP object and the SECONDARY-/EXPLICIT_ROUTE object combination. Per the definition of , each S2L_SUB_LSP object MAY be followed by a corresponding SERO. The first S2L_SUB_LSP object is a special case, and its explicit route is specified by the ERO. Therefore, the first S2L_SUB_LSP object SHOULD NOT be followed by an SERO, and if one is present, it MUST be ignored. The RRO in the sender descriptor contains the upstream hops traversed by the Path message and applies to all the S2L sub-LSPs signaled in the Path message. An IF_ID RSVP_HOP object MUST be used on links where there is not a one-to-one association of a control channel to a data channel [RFC3471]. An RSVP_HOP object defined in [RFC2205] SHOULD be used otherwise. Path message processing is described in the next section. Aggarwal, et al. Standards Track [Page 10] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007 5.2. Path Message Processing The ingress LSR initiates the setup of an S2L sub-LSP to each egress LSR that is a destination of the P2MP LSP. Each S2L sub-LSP is associated with the same P2MP LSP using common P2MP SESSION object and fields in the P2MP SENDER_TEMPLATE object. Hence, it can be combined with other S2L sub-LSPs to form a P2MP LSP. Another S2L sub-LSP belonging to the same instance of this S2L sub-LSP (i.e., the same P2MP LSP) SHOULD share resources with this S2L sub-LSP. The session corresponding to the P2MP TE tunnel is determined based on the P2MP SESSION object. Each S2L sub-LSP is identified using the S2L_SUB_LSP object. Explicit routing for the S2L sub-LSPs is achieved using the ERO and SEROs. As mentioned earlier, it is possible to signal S2L sub-LSPs for a given P2MP LSP in one or more Path messages, and a given Path message can contain one or more S2L sub-LSPs. An LSR that supports RSVP-TE signaled P2MP LSPs MUST be able to receive and process multiple Path messages for the same P2MP LSP and multiple S2L sub-LSPs in one Path message. This implies that such an LSR MUST be able to receive and process all objects listed in section 19. 5.2.1. Multiple Path Messages As described in section 4, either the < [ ] > or the < [ ] > tuple is used to specify an S2L sub-LSP. Multiple Path messages can be used to signal a P2MP LSP. Each Path message can signal one or more S2L sub-LSPs. If a Path message contains only one S2L sub-LSP, each LSR along the S2L sub-LSP follows [RFC3209] procedures for processing the Path message besides the S2L_SUB_LSP object processing described in this document. Processing of Path messages containing more than one S2L sub-LSP is described in section 5.2.2. An ingress LSR MAY use multiple Path messages for signaling a P2MP LSP. This may be because a single Path message may not be large enough to signal the P2MP LSP. Or it may be that when new leaves are added to the P2MP LSP, they are signaled in a new Path message. Or an ingress LSR MAY choose to break the P2MP tree into separate manageable P2MP trees. These trees share the same root and may share the trunk and certain branches. The scope of this management decomposition of P2MP trees is bounded by a single tree (the P2MP Tree) and multiple trees with a single leaf each (S2L sub-LSPs). Per [RFC4461], a P2MP LSP MUST have consistent attributes across all portions of a tree. This implies that each Path message that is used to signal a P2MP LSP is signaled using the same signaling attributes Aggarwal, et al. Standards Track [Page 11] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007 with the exception of the S2L sub-LSP descriptors and Sub-Group identifier. The resulting sub-LSPs from the different Path messages belonging to the same P2MP LSP SHOULD share labels and resources where they share hops to prevent multiple copies of the data being sent. In certain cases, a transit LSR may need to generate multiple Path messages to signal state corresponding to a single received Path message. For instance ERO expansion may result in an overflow of the resultant Path message. In this case, the message can be decomposed into multiple Path messages such that each message carries a subset of the X2L sub-tree carried by the incoming message. Multiple Path messages generated by an LSR that signal state for the same P2MP LSP are signaled with the same SESSION object and have the same