--- 1/draft-ietf-mpls-rsvp-te-p2mp-01.txt 2006-02-05 00:42:48.000000000 +0100 +++ 2/draft-ietf-mpls-rsvp-te-p2mp-02.txt 2006-02-05 00:42:48.000000000 +0100 @@ -1,314 +1,324 @@ -Network Working Group R. Aggarwal (Juniper) -Internet Draft D. Papadimitriou (Alcatel) -Expiration Date: June 2005 S. Yasukawa (NTT) - Editors +Network Working Group R. Aggarwal (Editor) +Internet Draft Juniper Networks +Expiration Date: January 2006 + D. Papadimitriou (Editor) + Alcatel + + S. Yasukawa (Editor) + NTT + + July 2005 Extensions to RSVP-TE for Point to Multipoint TE LSPs - draft-ietf-mpls-rsvp-te-p2mp-01.txt + draft-ietf-mpls-rsvp-te-p2mp-02.txt Status of this Memo - By submitting this Internet-Draft, we certify that any applicable - patent or IPR claims of which we are aware have been disclosed, and - any of which we become aware will be disclosed, in accordance with - RFC 3668. + 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.'' + 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 + 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 This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the setup 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. -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 [KEYWORDS]. +Table of Contents -Authors' Note + 1 Conventions used in this document ..................... 5 + 2 Terminology ........................................... 5 + 3 Introduction .......................................... 5 + 4 Mechanism ............................................. 5 + 4.1 P2MP Tunnels .......................................... 6 + 4.2 P2MP LSP ............................................. 6 + 4.3 Sub-Groups ............................................ 6 + 4.4 S2L Sub-LSPs .......................................... 7 + 4.4.1 Representation of a S2L Sub-LSP ....................... 7 + 4.4.2 S2L Sub-LSPs and Path Messages ........................ 7 + 4.5 Explicit Routing ...................................... 8 + 5 Path Message .......................................... 10 + 5.1 Path Message Format ................................... 10 + 5.2 Path Message Processing ............................... 11 + 5.2.1 Multiple Path Messages ................................ 12 + 5.2.2 Multiple S2L Sub-LSPs in one Path message ............. 13 + 5.2.3 Transit Fragmentation ................................. 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 Record Routing ........................................ 18 + 6.3.1 RRO Processing ........................................ 18 + 6.4 Reservation Style ..................................... 19 + 7 PathTear Message ...................................... 19 + 7.1 PathTear Message Format ............................... 19 + 7.2 Pruning ............................................... 20 + 7.2.1 Implicit S2L Sub-LSP Teardown ......................... 20 + 7.2.2 Explicit S2L Sub-LSP Teardown ........................ 20 + 8 Notify and ResvConf Messages .......................... 21 + 9 Refresh Reduction ..................................... 21 +10 State Management ...................................... 22 +10.1 Incremental State Update .............................. 22 +10.2 Combining Multiple Path Messages ...................... 23 +11 Error Processing ...................................... 24 +11.1 PathErr Messages ...................................... 24 +11.2 ResvErr Messages ...................................... 24 +11.3 Branch Failure Handling ............................... 25 +12 Admin Status Change ................................... 26 +13 Label Allocation on LANs with Multiple Downstream Nodes ...26 +14 P2MP LSP and Sub-LSP Re-optimization .................. 26 - Some of the text in the document needs further discussion between - authors and feedback from MPLS WG. This has been pointed out when - applicable. A change log and reviewed/updated text will be made - available online. +14.1 Make-before-break ..................................... 27 +14.2 Sub-Group Based Re-optimization ....................... 27 +15 Fast Reroute .......................................... 27 +15.1 Facility Backup ....................................... 28 +15.2 One to One Backup ..................................... 29 +16 Support for LSRs that are not P2MP Capable ............ 29 +17 Reduction in Control Plane Processing with LSP Hierarchy ..31 +18 P2MP LSP Remerging and Cross-Over ..................... 31 +19 New and Updated Message Objects ....................... 34 +19.1 SESSION Object ........................................ 34 +19.1.1 P2MP LSP Tunnel IPv4 SESSION Object ................... 34 +19.1.2 P2MP LSP Tunnel IPv6 SESSION Object ................... 35 +19.2 SENDER_TEMPLATE object ................................ 35 +19.2.1 P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object ........... 35 +19.2.2 P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object ........... 36 +19.3 S2L SUB-LSP Object .................................... 37 +19.3.1 S2L SUB-LSP IPv4 Object ............................... 37 +19.3.2 S2L SUB-LSP IPv6 Object ............................... 38 +19.4 FILTER_SPEC Object .................................... 38 +19.4.1 P2MP LSP_IPv4 FILTER_SPEC Object ...................... 38 +19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object ...................... 38 +19.5 P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) ........... 38 +19.6 P2MP_SECONDARY_RECORD_ROUTE Object (SRRO) ............. 39 +20 IANA Considerations ................................... 39 +20.1 New Class Numbers ..................................... 39 +20.2 New Class Types ....................................... 39 +20.3 New Error Codes ....................................... 40 +20.4 LSP Attributes Flags .................................. 40 +21 Security Considerations ............................... 41 +22 Acknowledgements ...................................... 41 +23 Appendix .............................................. 41 +23.1 Example ............................................... 41 +24 References ............................................ 42 +24.1 Normative References .................................. 42 +24.2 Informative References ................................ 43 +25 Author Information .................................... 44 +25.1 Editor Information .................................... 44 +25.2 Contributor Information ............................... 45 +26 Intellectual Property ................................. 47 +27 Full Copyright Statement .............................. 48 +28 Acknowledgement ....................................... 48 -Table of Contents +1. Conventions used in this document - 1 Terminology............................................. 4 - 2 Introduction.............................................4 - 3 Mechanisms.............................................. 4 - 3.1 P2MP Tunnels............................................ 5 - 3.2 P2MP LSP Tunnels........................................ 5 - 3.3 Sub-Groups.............................................. 5 - 3.4 S2L Sub-LSPs............................................ 6 - 3.4.1 Representation of a S2L sub-LSP......................... 6 - 3.4.2 S2L Sub-LSPs and Path Messages.......................... 6 - 3.5 Explicit Routing........................................ 7 - 4 Path Message............................................ 9 - 4.1 Path Message Format..................................... 9 - 4.2 Path Message Processing................................. 10 - 4.2.1 Multiple Path Messages.................................. 11 - 4.2.2 Multiple S2L Sub-LSPs in One Path Message............... 12 - 4.2.3 Transit Fragmentation................................... 13 - 4.3 Grafting................................................ 14 - 4.3.1 Addition of S2L Sub-LSP................................. 14 - 5 Resv Message............................................ 14 - 5.1 Resv Message Format..................................... 14 - 5.2 Resv Message Processing................................. 15 - 5.2.1 Resv Message Throttling................................. 16 - 5.3 Record Routing.......................................... 17 - 5.3.1 RRO Processing.......................................... 17 - 6 Reservation Style....................................... 17 - 7 Path Tear Message....................................... 17 - 7.1 Path Tear Message Format................................ 17 - 7.2 Pruning................................................. 17 - 7.2.1 Explicit S2L Sub-LSP Teardown........................... 17 - 7.2.2 Implicit S2L Sub-LSP Teardown........................... 18 - 7.2.1 P2MP TE LSP Teardown.................................... 19 - 8 Notify and ResvConf Messages............................ 20 - 9 Error Processing........................................ 20 - 9.1 PathErr Message Format.................................. 20 - 9.2 Handling of Failures at Branch LSRs..................... 21 - 10 Refresh Reduction....................................... 22 - 11 State Management........................................ 22 - 11.1 Incremental State Update................................ 22 - 11.2 Combining Multiple Path Messages........................ 23 - 12 Control of Branch Fate Sharing.......................... 24 - 13 Admin Status Change..................................... 24 - 14 Label Allocation on LANs with Multiple Downstream Nodes. 25 - 15 Make-Before-Break....................................... 25 - 15.1 P2MP Tree re-optimization............................... 25 - 15.2 Re-optimization of a subset of S2L sub-LSPs ............ 25 - 16 Fast Reroute............................................ 26 - 16.1 Facility Backpup........................................ 26 - 16.2 One to One Backup....................................... 26 - 17 Support for LSRs that are not P2MP Capable.............. 27 - 18 Reduction in Control Plane Processing with LSP Hierarchy 29 - 19 P2MP LSP Tunnel Remerging and Cross-Over................ 29 - 20 New and Updated Message Objects......................... 31 - 20.1 P2MP SESSION Object..................................... 31 - 20.2 P2MP LSP Tunnel SENDER_TEMPLATE Object.................. 32 - 20.2.1 P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object............. 33 - 20.2.2 P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object............. 33 - 20.3 S2L SUB-LSP Object...................................... 34 - 20.3.1 S2L IPv4 SUB-LSP Object................................. 34 - 20.3.2 S2L IPv6 SUB-LSP Object................................. 35 - 20.4 FILTER_SPEC Object...................................... 35 - 20.5 SUB EXPLICIT ROUTE Object (SERO)........................ 36 - 20.6 SUB RECORD ROUTE Object (SRRO).......................... 36 - 21 IANA Considerations..................................... 37 - 22 Security Considerations................................. 37 - 23 Acknowledgements........................................ 37 - 24 Example P2MP LSP Establishment ......................... 37 - 25 References.............................................. 39 - 26 Authors................................................. 40 - 27 Intellectual Property................................... 43 - 28 Full Copyright Statement................................ 43 - 29 Acknowledgement......................................... 44 + 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 [KEYWORDS]. -1. Terminology +2. Terminology This document uses terminologies defined in [RFC3031], [RFC2205], - [RFC3209], [RFC3473] and [P2MP-REQ]. In particular, this document - uses the notation defined in [P2MP-REQ] for describing the components - on a P2MP LSP between root, branches and leaves. + [RFC3209], [RFC3473] and [P2MP-REQ]. -2. Introduction +3. Introduction - [RFC3209] defines a mechanism for setting up point-to-point (P2P) - Traffic Engineered (TE) LSPs in MPLS networks. [RFC3473] defines - extensions to [RFC3209] for setting up P2P TE LSPs in GMPLS networks. - However these specifications do not provide a mechanism for building - point-to-multipoint P2MP TE LSPs. + [RFC3209] defines a mechanism for setting up P2P TE LSPs in MPLS net- + works. [RFC3473] defines extensions to [RFC3209] for setting up P2P + TE LSPs in GMPLS networks. However these specifications do not pro- + vide a mechanism for building P2MP TE LSPs. - This document defines extensions to RSVP-TE [RFC3209] and [RFC3473] - protocol to support P2MP TE LSPs satisfying the set of requirements + This document defines extensions to RSVP-TE protocol [RFC3209, + RFC3473] to support P2MP TE LSPs satisfying the set of requirements described in [P2MP-REQ]. This document relies on the semantics of RSVP that RSVP-TE inherits - for building P2MP LSP Tunnels. A P2MP LSP Tunnel is comprised of - multiple 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. Hence the S2L sub- - LSPs belonging to a P2MP LSP Tunnel can be signaled using one Path - message or split across multiple Path messages. + for building P2MP LSPs. A P2MP LSP is comprised of multiple 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. Hence the S2L sub-LSPs belonging to a P2MP + LSP can be signaled using one Path message or split across multiple + Path messages. Path computation and P2MP application specific aspects are outside of the scope of this document. -3. Mechanism +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 a LSR that is capable of replicating the incoming data on two or more outgoing interfaces. The solution uses RSVP-TE in the core of the network for setting up a P2MP TE LSP. The P2MP TE LSP is set up by associating multiple S2L TE 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. + relying on data replication at branch nodes. This is described fur- + ther in the following sub-sections by describing P2MP Tunnels and how + they relate to S2L sub-LSPs. -3.1. P2MP Tunnels +4.1. P2MP Tunnels The specific aspect related to P2MP TE LSP is the action required at - a branch node, where data replication occurs. Incoming labeled data - is appropriately replicated to several outgoing interfaces which may - have different labels. + a branch node, where data replication occurs. For instance, in the + MPLS case, incoming labeled data is appropriately replicated to sev- + eral outgoing interfaces which may have different labels. - A P2MP TE tunnel comprises of one or more P2MP LSPs referred to as - P2MP LSP tunnels. A P2MP TE Tunnel is identified by a P2MP SESSION - object. This object contains an identifier of the P2MP session - defined as a P2MP ID, a tunnel ID and an extended tunnel ID. + A P2MP TE Tunnel comprises of 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 ID, a tunnel + ID and an extended tunnel ID. The fields of a 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 Identifier (P2MP ID) field. + The P2MP ID provides an identifier for the set of destinations of the - P2MP TE Tunnel. The P2MP SESSION object is defined in section 20.1. + P2MP TE Tunnel. -3.2. P2MP LSP Tunnel +4.2. P2MP LSP - A P2MP LSP Tunnel 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 + 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 20.2. -3.3. Sub-Groups +4.3. Sub-Groups - As with all other RSVP controlled LSP Tunnels, P2MP LSP Tunnel state - is managed using RSVP messages. While use of RSVP messages is the - same, P2MP LSP Tunnel state differs from P2P LSP state in a number of - ways. A notable difference is that a P2MP LSP Tunnel is comprised of - multiple S2L Sub-LSPs As a result of this, it may not be possible to - signal a P2MP LSP Tunnel in a single RSVP-TE Path/Resv message. It is - also possible that such a signaling message can not fit into 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 P2MP - LSP Tunnels must also handle the state "remerge" problem [P2MP-REQ]. + As with all other RSVP controlled LSPs, P2MP LSP state is managed + using RSVP messages. While use of RSVP messages is the same, P2MP LSP + state differs from P2P LSP state in a number of ways. The two most + notable differences are that a P2MP LSP comprises multiple S2L Sub- + LSPs and that, as a result of this, it may not be possible to repre- + sent full state in a single IP datagram and even more likely that it + can't fit into a single IP packet. It must also be possible to effi- + ciently add and remove endpoints to and from P2MP TE LSPs. An addi- + tional issue is that P2MP LSP must also handle the state "remerge" + problem, see [P2MP-REQ]. 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 rest of the SENDER_TEMPLATE and - SESSION objects, are used to represent a portion of a P2MP LSP - Tunnel's state. The portion of P2MP LSP Tunnel state identified by - specific subgroup field values is referred to as a signaling sub- - tree. It is important to note that the term "signaling sub-tree" - refers only to signaling state and not data plane replication or - branching. For example, it is possible for a node to "split" - signaling state for a P2MP LSP Tunnel, but to not branch the data - associated with the P2MP LSP Tunnel. Typical applications for - generation and use of multiple subgroups are adding an egress and - semantic fragmentation to ensure that a Path message remains within a - single IP packet. - -3.4. S2L Sub-LSPs + 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 applica- + tions for generation and use of multiple subgroups are adding an + egress and semantic fragmentation to ensure that a Path message + remains within a single IP packet. - A P2MP LSP Tunnel is constituted of one or more S2L sub-LSPs. +4.4. S2L Sub-LSPs -3.4.1. Representation of a S2L Sub-LSP + A P2MP LSP is constituted of one or more S2L sub-LSPs. - A S2L sub-LSP exists within the context of a P2MP LSP Tunnel. 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 20.3. +4.4.1. Representation of a S2L Sub-LSP - Additionally, a sub-LSP ID contained in the S2L_SUB_LSP object may be - used depending on further discussions about the make-before-break - procedures described in section 14. + A 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 20.3. - An EXPLICIT_ROUTE Object (ERO) or SUB_EXPLICIT_ROUTE Object (SERO) is - used to optionally specify the explicit route of a S2L sub-LSP. Each - ERO or a SERO that is signaled corresponds to a particular - S2L_SUB_LSP object. Details of explicit route encoding are specified - in section 3.5. + 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 a 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 [RECOVERY], a new P2MP SECONDARY_EXPLICIT_ROUTE Object C- + type is defined in Section 20.5 and a matching P2MP SEC- + ONDARY_RECORD_ROUTE Object C-type is defined in Section 20.6. -3.4.2. S2L Sub-LSPs and Path Messages +4.4.2. S2L Sub-LSPs and Path Messages - The mechanism in this document allows a P2MP LSP Tunnel 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 fit all - the S2L sub-LSPs; and they also allow separate manipulation of sub- - trees of the P2MP LSP Tunnel. The reason for allowing a single Path - message, to signal multiple S2L sub-LSPs, is to optimize the number - of control messages needed to setup a P2MP LSP Tunnel. + 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 fit 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 + setup a P2MP LSP. -3.5. Explicit Routing +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 may encode 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. 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. + EXPLICIT_ROUTE object encodes the path from the ingress LSR 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 inter- + preted 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. One approach to encode the explicit route - of a subsequent S2L sub-LSP is to include the path from the ingress - to the egress of the S2L sub-LSP. However this implies potential - repetition of hops that could be learned from the ERO or explicit - routes of other S2L sub-LSPs. Explicit route compression using SEROs - attempts to minimize such repetition and is described below. + first S2L sub-LSP, from the ingress LSR 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 corre- + sponding to the S2L_SUB_LSP objects that follow are termed as subse- + quent S2L sub-LSPs. One approach to encode the explicit route of a + subsequent S2L sub-LSP is to include all the hops from the ingress to + the egress of the S2L sub-LSP. However this implies potential repeti- + tion of hops that can be learned from the ERO or explicit routes of + other S2L sub-LSPs. Explicit route compression using SEROs attempts + to minimize such repetition. - The path of each subsequent S2L sub-LSP is encoded in a - SUB_EXPLICIT_ROUTE object (SERO). The format of the SERO is the same - as an ERO (as defined in [RFC3209]). Each subsequent S2L sub-LSP is - represented by tuples of the form [] - . There is a one to one correspondence between a - S2L_SUB_LSP object and a SERO. A SERO for a particular S2L sub-LSP - includes only the path from a certain branch LSR to the egress LSR if - the path to that branch LSR can be derived from the ERO or other - SEROs. The absence of a 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 are described in detail in section 20. + The path of each subsequent S2L sub-LSP is encoded in a P2MP SEC- + ONDARY_EXPLICIT_ROUTE object (SERO). The format of the SERO is the + same as an ERO (as defined in [RFC3209]). Each subsequent S2L sub-LSP + is represented by tuples of the form < [] >. There is a one to one corre- + spondence between a S2L_SUB_LSP object and a SERO. A SERO for a par- + ticular S2L sub-LSP includes only the path from a certain branch LSR + to the egress LSR if the path to that branch LSR can be derived from + the ERO or other SEROs. The absence of a 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 encod- + ing of the SERO and S2L sub-LSP object are described in detail in + section 20. Explicit route compression is illustrated using the following figure. A | | B | | C----D----E @@ -317,26 +327,26 @@ F G H-------I | |\ | | | \ | J K L M | | | | | | | | N O P Q--R Figure 1. Explicit Route Compression - Figure 1. shows a P2MP LSP Tunnel with LSR A as the ingress LSR and - six egress LSRs: (F, N, O, P, Q and R). When all the 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. Following is one way for the ingress LSR A to encode the - S2L sub-LSP explicit routes using 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 the 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. Following 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}, S2L_SUB_LSP Object-F S2L sub-LSP-N: SERO = {D, G, J, N}, S2L_SUB_LSP Object-N S2L sub-LSP-O: SERO = {E, H, K, O}, S2L_SUB_LSP Object-O S2L sub-LSP-P: SERO = {H, L, P}, S2L_SUB_LSP Object-P, S2L sub-LSP-Q: SERO = {H, I, M, Q}, S2L_SUB_LSP Object-Q, S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP 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 @@ -351,282 +361,301 @@ S2L sub-LSP-O: ERO = {H, K, O}, S2L_SUB_LSP Object-O S2L sub-LSP-P: SERO = {H, L, P}, S2L_SUB_LSP Object-P, S2L sub-LSP-Q: SERO = {H, I, M, Q}, S2L_SUB_LSP Object-Q, S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP Object-R, 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}, S2L_SUB_LSP Object-O - - The encoding of the Path message sent by LSR H to LSR L is as - follows: + The encoding of the Path message sent by LSR H to LSR L is as fol- + lows: S2L sub-LSP-P: ERO = {L, P}, S2L_SUB_LSP Object-P, Following 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}, S2L_SUB_LSP Object-Q, S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP Object-R, The explicit route encodings in the Path messages sent by LSRs D and Q are left as an exercise to the reader. This compression mechanism reduces the Path message size. It also - reduces the 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 + 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. A LSR needs - to process a SERO 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 a SERO propagates the corresponding S2L - sub-LSP downstream. + to process a 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 a SERO propagates the + corresponding S2L sub-LSP downstream. -4. Path Message +5. Path Message -4.1. Path Message Format +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. ::= [ ] [ [ | ] ...] [ ] [ ] [ ] [ ... ] [ ] [ ] [ ] [ ... ] - [S2L sub-LSP descriptor list] + [] + 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 SUB-/EXPLICIT_ROUTE object combination. The first S2L_SUB_LSP object's explicit route is specified by the ERO. Explicit routes of subsequent S2L sub-LSPs are specified by the corresponding SERO. A SERO corresponds to the following S2L_SUB_LSP object. The RRO in the sender descriptor contains the hops traversed by the Path message and applies to all the S2L sub-LSPs signaled in the Path message. Path message processing is described in the next section. -4.2. Path Message Processing +5.2. Path Message Processing The ingress-LSR initiates the set up of a S2L sub-LSP to each egress- - LSR that is the destination of the P2MP LSP Tunnel. Each S2L sub-LSP - is associated with the same P2MP LSP Tunnel using common P2MP SESSION - object and fields in the SENDER_TEMPLATE + LSR that is the 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 Tunnel. Another S2L sub-LSP belonging to the same instance - of this S2L sub-LSP (i.e. the same P2MP LSP Tunnel) can share - resources with this 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. + P2MP LSP. Another S2L sub-LSP belonging to the same instance of this + S2L sub-LSP (i.e. the same P2MP LSP) shares resources with this S2L + sub-LSP. The session corresponding to the P2MP TE tunnel is deter- + mined based on the P2MP SESSION object. Each S2L sub-LSP is identi- + fied 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 Tunnel in one or more Path messages. And a given Path - message can contain one or more S2L sub-LSPs. + given P2MP LSP in one or more Path messages. And a given Path message + can contain one or more S2L sub-LSPs. A 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 a LSR MUST be able to receive and process + all objects listed in section 20. -4.2.1. Multiple Path messages +5.2.1. Multiple Path Messages - As described in section 3, {, } or - {, } tuple is used to specify a S2L - sub-LSP. Multiple Path messages can be used to signal a P2MP LSP - Tunnel. Each Path message can signal one or more S2L sub-LSPs. If a + As described in section 3, either the + or the tuple is used to + specify a 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 4.3. + 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 Tunnel. Or it may be while adding - leaves to the P2MP LSP Tunnel the new leaves are signaled in a new - Path message. Or an ingress LSR MAY choose to break the P2MP tree - into separate manageable S2L sub-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 - and multiple S2L sub-trees with a single leaf each. As defined in - [P2MP-REQ], a P2MP LSP Tunnel must have consistent attributes across - all portions of a tree. This implies that each Path message that is - used to signal a P2MP LSP Tunnel is signaled using the same signaling - attributes with the exception of the S2L sub-LSP information. + enough to signal the P2MP LSP. Or it may be while adding leaves to + the P2MP LSP the new leaves are signaled in a new Path message. Or an + ingress LSR MAY choose to break the P2MP tree into separate manage- + able P2MP trees. These trees share the same root and may share the + trunk and certain branches. The scope of this management decomposi- + tion of P2MP trees is bounded by a single tree (the P2MP Tree) and + multiple trees with a single leaf each (S2L sub-LSPs). Per [P2MP- + REQ], 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 with the + exception of the S2L sub-LSP information. - The resulting S2L sub-LSPs from the different Path messages belonging - to the same P2MP LSP Tunnel SHOULD share labels and resources where - they share hops to prevent multiple copies of the data being sent. + 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. There are two cases occurring in such - circumstances, either the message can be decomposed into multiple - Path messages such that each of the message carries a subset of the - incoming S2L sub-LSPs carried by the incoming message, or the message - can not be decomposed such that each of the outgoing Path message - fits its maximum size value. + messages to signal state corresponding to a single received Path mes- + sage. 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 of the messages carry a + subset of the X2L sub-tree carried by the incoming message. Multiple Path messages generated by a LSR that signal state for the same P2MP LSP are signaled with the same SESSION object and have the same in the SENDER_TEMPLATE object. In order to disambiguate these Path messages a tuple is introduced (also referred to as the Sub-Group - field). Multiple Path messages generated by a LSR to signal state - for the same P2MP LSP have the same Sub-Group Originator ID and have - a different sub-Group ID. The Sub-Group Originator ID SHOULD be set - to the TE Router ID of the LSR that originates the Path message. This - is either the ingress LSR or a LSR which re-originates the Path - message with its own Sub-Group Originator ID. Cases when a transit - LSR may change the Sub-Group Originator ID of an incoming Path - message are described below. The tuple is network-wide unique. The sub-Group ID space is specific - to the Sub-Group Originator ID. Therefore the combination is network-wide unique. Also, a router - that changes the Sub-Group Originator ID MUST use the same Sub-Group - Originator ID on all Path messages for the same P2MP LSP Tunnel and - SHOULD not vary the value during the life of the P2MP LSP Tunnel. - - Note: This version of the document assumes that these additional - fields, i.e. , are part of the - SENDER_TEMPLATE object. + field) and encoded in the SENDER_TEMPLATE object. Multiple Path mes- + sages generated by a LSR to signal state for the same P2MP LSP have + the same Sub-Group Originator ID and have a different sub-Group ID. + The Sub-Group Originator ID SHOULD be set to the TE Router ID of the + LSR that originates the Path message. This is either the ingress LSR + or a LSR which re-originates the Path message with its own Sub-Group + Originator ID. Cases when a transit LSR may change the Sub-Group + Originator ID of an incoming Path message are described below. The + tuple is globally unique. The + sub-Group ID space is specific to the Sub-Group Originator ID. There- + fore the combination is net- + work-wide unique. Also, a router that changes the Sub-Group origina- + tor ID of an incoming Path message MUST use the same value of the + Sub-Group Originator ID for all outgoing Path messages, for a partic- + ular P2MP LSP, and SHOULD not vary it during the life of the P2MP + LSP. -4.2.2. Multiple S2L Sub-LSPs in one Path message +5.2.2. Multiple S2L Sub-LSPs in one Path message The S2L sub-LSP descriptor list allows the signaling of one or more S2L sub-LSPs in one Path message. It is possible to signal multiple - S2L sub-LSP objects and ERO/SERO combinations in a single Path - message. Note that these objects are the ones that differentiate a - S2L sub-LSP. Each LSR can use the common objects in the Path message - and the S2L sub-LSP descriptors to process each S2L sub-LSP. + S2L sub-LSP object and ERO/SERO combinations in a single Path mes- + sage. Note that these two objects are the ones that differentiate a + S2L sub-LSP. - All LSRs need to process the ERO corresponding to the first S2L sub- - LSP when the ERO is present. If one or more SEROs are present an ERO - MUST be present. The signaling information for the first S2L sub-LSP - is propagated in a Path message by each LSR along the explicit route - specified by the ERO. A LSR needs to process a 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. If this is not the - case the S2L sub-LSP descriptor is included in the Path message sent - to LSR that is the next hop to reach the first hop in the SERO. This - next hop is determined by using the ERO or other SEROs that encode - the path to the SERO's first hop. If this is the case and the LSR is - also the egress the S2L sub-LSP descriptor is not propagated - downstream. If this is the case and the LSR is not the egress the S2L - sub-LSP descriptor is included in a Path message sent to the next-hop - determined from the SERO. Hence a branch LSR only propagates the - relevant S2L sub-LSP descriptors on each downstream link. A S2L sub- - LSP descriptor that is propagated on a downstream link only contains - those S2L sub-LSPs that are routed using that link. This processing - may result in a subsequent S2L sub-LSP in an incoming Path message to - become the first S2L sub-LSP in an outgoing Path message. + All LSRs MUST process the ERO corresponding to the first S2L sub-LSP + when the ERO is present. If one or more SEROs are present an ERO MUST + be present. The first S2L sub-LSP MUST be propagated in a Path mes- + sage by each LSR along the explicit route specified by the ERO. A LSR + MUST process a 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. If this is not the case the S2L sub-LSP descriptor MUST be + included in the Path message sent to LSR that is the next hop to + reach the first hop in the SERO. This next hop is determined by using + the ERO or other SEROs that encode the path to the SERO's first hop. + If this is the case and the LSR is also the egress, the S2L sub-LSP + descriptor MUST NOT be propagated downstream. If this is the case and + the LSR is not the egress the S2L sub-LSP descriptor MUST be included + in a Path message sent to the next-hop determined from the SERO. + Hence a branch LSR MUST only propagate the relevant S2L sub-LSP + descriptors on each downstream link. A S2L sub-LSP descriptor list + that is propagated on a downstream link MUST only contain those S2L + sub-LSPs that are routed using that link. This processing MAY result + in a subsequent S2L sub-LSP in an incoming Path message to become the + first S2L sub-LSP in an outgoing Path message. - Note that if one or more SEROs contains loose hops, expansion of such - loose hops may result in overflowing the Path message size. Section - 4.2.3 describes how signaling of the set of S2L sub-LSPs can be split + Note that if one or more SEROs contain loose hops, expansion of such + loose hops MAY result in overflowing the Path message size. Section + 5.2.3 describes how signaling of the set of S2L sub-LSPs can be split in more than one Path message. The Record Route Object (RRO) contains the hops traversed by the Path - message and applies to all the S2L sub-LSPs signaled in the Path - message. A transit LSR appends its address in an incoming RRO and - propagates it downstream. A branch LSR forms a new RRO for each of - the outgoing Path messages. Each such updated RRO is formed using the - rules in [RFC3209]. + message and applies to all the S2L sub-LSPs signaled in the path mes- + sage. A transit LSR MUST append its address in an incoming RRO and + propagate it downstream. A branch LSR MUST form a new RRO for each of + the outgoing Path messages. Each such updated RRO MUST be formed + using the rules in [RFC3209]. - If a LSR is unable to support a S2L sub-LSP setup, a PathErr message - MUST be sent for the impacted S2L sub-LSP, and normal processing of - the rest of the P2MP LSP Tunnel SHOULD continue. The default behavior - is that the remainder of the LSP is not impacted (that is, all other - branches are allowed to set up) and the failed branches are reported - in PathErr messages in which the Path_State_Reomved flag MUST NOT be - set. However, the ingress LSR may set a LSP Integrity flag (see - section 21.3) to request that if there is a setup failure on any - branch the entire LSP should fail to set up. + If a LSR is unable to support a S2L sub-LSP in a Path message, a + PathErr message MUST be sent for the impacted S2L sub-LSP, and normal + processing of the rest of the P2MP LSP SHOULD continue. The default + behavior is that the remainder of the LSP is not impacted (that is, + all other branches are allowed to set up) and the failed branches are + reported in PathErr messages in which the Path_State_Removed flag + MUST NOT be set. However, the ingress LSR may set a LSP Integrity + flag to request that if there is a setup failure on any branch the + entire LSP should fail to set up. This is described further in sec- + tion 12. -4.2.3. Transit Fragmentation +5.2.3. Transit Fragmentation 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. It is desirable not to rely on IP - fragmentation in this case. In order to achieve this, the multiple - Path messages generated by the transit LSR, MUST be signaled with the - Sub-Group Originator ID set to the TE Router ID of the transit LSR - and a distinct sub-Group ID. Thus each distinct Path message that is - generated by the transit LSR for the P2MP LSP Tunnel carries a - distinct tuple. + messages to signal state corresponding to a single received Path mes- + sage. For instance ERO expansion may result in an overflow of the + resultant Path message. It is desirable not to rely on IP fragmenta- + tion in this case. In order to achieve this, the multiple Path mes- + sages generated by the transit LSR, are signaled with the Sub-Group + Originator ID set to the TE Router ID of the transit LSR and a dis- + tinct sub-Group ID. Thus each distinct Path message that is generated + by the transit LSR for the P2MP LSP carries a distinct tuple. When multiple Path messages are used by an ingress or transit node, each Path message SHOULD be identical with the exception of the S2L sub-LSP related information (e.g., SERO), message and hop information - (e.g., INTEGRITY, MESSAGE_ID and RSVP_HOP), and the SENDER_TEMPLATE - objects. Except when performing a make-before-break operation, the - tunnel sender address and LSP ID fields MUST be the same in each - message, and for transit nodes, the same as the values in the Path - message. + (e.g., INTEGRITY, MESSAGE_ID and RSVP_HOP), and the sub-group fields + of the SENDER_TEMPLATE objects. Except when performing a make- + before-break operation, the tunnel sender address and LSP ID fields + MUST be the same in each message, and for transit nodes, the same as + the values in the received Path message. As described above one case in which the Sub-Group Originator ID of a received Path message is changed is that of transit fragmentation. The Sub-Group Originator ID of a received Path message may also be - changed in the outgoing Path message and set to that of the LSR - originating the Path message based on a local policy. For instance a - LSR may decide to always change the Sub-Group Originator ID while - performing ERO expansion. The Sub-Group ID MUST not be changed if the + changed in the outgoing Path message and set to that of the LSR orig- + inating the Path message based on a local policy. For instance a LSR + may decide to always change the Sub-Group Originator ID while per- + forming ERO expansion. The Sub-Group ID MUST not be changed if the Sub-Group Originator ID is not being changed. -4.3. Grafting +5.2.4. Control of Branch Fate Sharing - The operation of adding egress LSR(s) to an existing P2MP LSP Tunnel - is termed grafting. This operation allows egress nodes to join a P2MP - LSP Tunnel at different points in time. + An ingress LSR can control the behavior of an LSP if there is a fail- + ure during LSP setup or after an LSP has been established. The + default behavior is that only the branches downstream of the failure + are not established, but the ingress may request 'LSP integrity' such + that any failure anywhere within the LSP tree causes the entire P2MP + LSP to fail. -4.3.1. Addition of S2L Sub-LSPs + The ingress LSP may request 'LSP integrity' by setting bit [TBA] of + the Attributes Flags TLV. The bit is set if LSP integrity is + required. - There are two methods to add S2L sub-LSPs to a P2MP LSP Tunnel. The - first is to add new S2L sub-LSPs to the P2MP LSP Tunnel by adding - them to an existing Path message and refreshing the entire Path - message. Path message processing described in section 4 results in - adding these S2L sub-LSPs to the P2MP LSP Tunnel. Note that as a - result of adding one or more S2L sub-LSPs to a Path message the ERO - compression encoding may have to be recomputed. + It is RECOMMENDED to use the LSP_ATTRIBUTES Object for this flag and + not the LSP_REQUIRED_ATTRIBUTES Object. - The second is to use incremental updates described in section 11.1. - The egress LSRs can be added/removed by signaling only the impacted - S2L sub-LSPs in a new Path message. Hence other S2L sub-LSPs do not - have to be re-signaled. + A branch LSR that supports the Attributes Flags TLV and recognizes + this bit MUST support LSP integrity or reject the LSP setup with a + PathErr carrying the error "Routing Error"/"Unsupported LSP + Integrity" -5. Resv Message +5.3. Grafting -5.1. Resv Message Format + The operation of adding egress LSR(s) to an existing P2MP LSP is + termed as grafting. This operation allows egress nodes to join a P2MP + LSP at different points in time. + + There are two methods to add S2L sub-LSPs to a P2MP LSP. The first + is to add new S2L sub-LSPs to the P2MP LSP by adding them to an + existing Path message and refreshing the entire Path message. Path + message processing described in section 4 results in adding these S2L + sub-LSPs to the P2MP LSP. Note that as a result of adding one or more + S2L sub-LSPs to a Path message the ERO compression encoding may have + to be recomputed. + + The second is to use incremental updates described in section 10.1. + The egress LSRs can be added by signaling only the impacted S2L sub- + LSPs in a new Path message. Hence other S2L sub-LSPs do not have to + be re-signaled. + +6. Resv Message + +6.1. Resv Message Format The Resv message follows the [RFC3209] and [RFC3473] format: ::= [ ] [ [ | ] ... ] [ ] [ ] [ ] [ ] @@ -633,845 +662,846 @@ [ ] [ ... ]