RFC 4875
Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)
RFC 4875 🦋 Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)
Okay bestie, the paperwork first 📋 It's from the Network Working Group, written by R. Aggarwal (Ed.) of Juniper Networks, D. Papadimitriou (Ed.) of Alcatel, and S. Yasukawa (Ed.) of NTT. It's on the Standards Track and dates from May 2007 🌸 The title block doesn't list anything it obsoletes or updates, so it's not replacing or patching any other RFC.
Status of This Memo 📜
This one is an Internet standards track protocol for the Internet community, and the authors are inviting discussion and suggestions for improvements 💖 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🫶
Copyright Notice ©️
Copyright (C) The IETF Trust (2007). 💜
Abstract 🎀
Okay so this doc extends RSVP-TE so you can set up Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks 🔥 The big win is that it works using RSVP-TE alone, with no multicast routing protocol needed in the Service Provider core. Obsessed 😭 The protocol elements and procedures for all of this are described inside.
There can be all kinds of applications for P2MP TE LSPs, like IP multicast ✨ But how those apps use a P2MP TE LSP is outside the scope of this doc 🙈
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
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 ..........................................501. Introduction ✨
Quick backstory 🧚 [RFC3209] defines how to set up point-to-point (P2P) Traffic Engineered (TE) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. [RFC3473] extends [RFC3209] so P2P TE LSPs work in Generalized MPLS (GMPLS) networks. But neither of these gives you a way to build point-to-multipoint (P2MP) TE LSPs, which is the gap this doc fills 🌈
So this doc extends the RSVP-TE protocol ([RFC3209] and [RFC3473]) to support P2MP TE LSPs that meet the requirements in [RFC4461] 💅
The trick is that it leans on RSVP semantics that RSVP-TE already inherits to build P2MP LSPs. A P2MP LSP is made of multiple source-to-leaf (S2L) sub-LSPs. Those get set up between the ingress and egress LSRs, then the branch LSRs stitch them together using RSVP semantics to make one P2MP TE LSP 🦋 One Path message can signal one or several S2L sub-LSPs for a single P2MP LSP. So the S2L sub-LSPs of a P2MP LSP can ride in on one Path message, or get split across several 🎀
There are lots of applications for P2MP TE LSPs, and the signaling techniques here can be used on their own or mixed with other techniques to support different ones 💖
How applications use P2MP TE LSPs, and how their paths get computed, is outside the scope of this document 🙈
2. Conventions Used in This Document 📏
Okay, the capital words are the important ones. "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" all carry the meanings given in RFC 2119 [RFC2119] everywhere in this document 🫶
3. Terminology 🗂️
This doc uses terms defined in [RFC2205], [RFC3031], [RFC3209], [RFC3473], [RFC4090], and [RFC4461] 🌸
4. Mechanism 🔥
This one's the big idea 😭 It optimizes data replication by letting non-ingress nodes in the network act as replication/branch nodes. A branch node is an LSR that copies the incoming data onto one or more outgoing interfaces ✨ The whole thing relies on RSVP-TE in the network to set up a P2MP TE LSP.
The P2MP TE LSP gets set up by associating multiple S2L sub-LSPs and relying on data replication at the branch nodes. The next sub-sections explain P2MP tunnels and how they connect to S2L sub-LSPs 💜
4.1. P2MP Tunnels 🎀
Here's what makes a P2MP TE LSP special: it's the action that happens at branch nodes where data gets replicated. Incoming MPLS labeled data is copied out to outgoing interfaces, and those interfaces can use different labels for the same data 🦋
A P2MP TE Tunnel is made of one or more P2MP LSPs. You identify a P2MP TE Tunnel with a P2MP SESSION object 🧁 That object holds the P2MP Session identifier, 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, unique within the scope of the ingress LSR 🌈
The <P2MP ID, Tunnel ID, Extended Tunnel ID> tuple gives you one identifier for the whole set of destinations of the P2MP TE Tunnel 💖
The P2MP SESSION object has the same fields as the SESSION object from [RFC3209], with one twist: the Tunnel Endpoint Address field gets swapped out for the P2MP ID field. The P2MP SESSION object is defined in section 19.1 🫶
4.2. P2MP LSP 🦋
A P2MP LSP is identified by a combo of stuff: the P2MP ID, Tunnel ID, and Extended Tunnel ID from the P2MP SESSION object, plus the tunnel sender address and LSP ID fields from the P2MP SENDER_TEMPLATE object 💅 That new P2MP SENDER_TEMPLATE object is defined in section 19.2 ✨
4.3. Sub-Groups ✨
Okay so, just like every other RSVP-controlled LSP, P2MP LSP state is managed with RSVP messages 💌. The messages themselves are the same, but P2MP state is different from P2P state in a bunch of ways 🦋. A P2MP LSP is made of multiple S2L Sub-LSPs, so the full state might literally not fit in one IP packet 😭. You also need to be able to add and remove endpoints efficiently, and the P2MP LSP has to handle the state "re-merge" problem too, see [RFC4461] and section 18 🌀.
These P2MP differences get handled by adding a sub-group identifier (Sub-Group ID) and a sub-group originator (Sub-Group Originator ID) to the SENDER_TEMPLATE and FILTER_SPEC objects 🎀. Together, the Sub-Group ID and Sub-Group Originator ID are called the Sub-Group fields.
The Sub-Group fields, along with the rest of the SENDER_TEMPLATE and SESSION objects, represent a chunk of a P2MP LSP's state 💅. This chunk only covers signaling state, not data plane replication or branching. So a node can "branch" signaling state for a P2MP LSP without branching the data for it, which is a very valid move 👑. Typical reasons to make multiple sub-groups are (1) adding an egress and (2) semantic fragmentation, so that a Path message stays inside a single IP packet 📦.
4.4. S2L Sub-LSPs 🦋
A P2MP LSP is made up of one or more S2L sub-LSPs. Main character energy, honestly 👑.
4.4.1. Representation of an S2L Sub-LSP
An S2L sub-LSP only exists inside the context of a P2MP LSP 🧚. So it gets identified by the P2MP ID, Tunnel ID, and Extended Tunnel ID from the P2MP SESSION, the tunnel sender address and LSP ID fields from the P2MP SENDER_TEMPLATE object, and the S2L sub-LSP destination address from 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) can optionally specify the explicit route of an S2L sub-LSP 🗺️. Each ERO or SERO that gets signaled matches up with one particular S2L_SUB_LSP object. The details of explicit route encoding are 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 🌸.
4.4.2. S2L Sub-LSPs and Path Messages
A P2MP LSP can be signaled using one or more Path messages 💜. Each Path message can signal one or more S2L sub-LSPs. Supporting multiple Path messages is desirable, because one Path message might not be big enough to hold all the S2L sub-LSPs, and it also lets you manipulate sub-trees of the P2MP LSP separately 🙈. A single Path message is allowed to signal multiple S2L sub-LSPs so you can cut down 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 (so the Path message only targets one 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 that S2L sub-LSP. The < [<EXPLICIT_ROUTE>], <S2L_SUB_LSP> > tuple is the S2L sub-LSP, and it's called the sub-LSP descriptor 🧩. If the ERO is absent, it 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" one is whichever one matches the first S2L_SUB_LSP object in the Path message. Every S2L sub-LSP that matches one of the S2L_SUB_LSP objects after that is called a subsequent S2L sub-LSP 🫶.
The path of each subsequent S2L sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object (SERO) 🧁. The SERO has the same format as an ERO, as defined in [RFC3209] and [RFC3473]. Each subsequent S2L sub-LSP is represented by tuples of the form < [<P2MP SECONDARY_EXPLICIT_ROUTE>], <S2L_SUB_LSP> >. A SERO for a given S2L sub-LSP only includes the path from a branch LSR to that S2L sub-LSP's egress LSR 🌈. The branch MUST appear as an explicit hop in the ERO or some other SERO 🚨. If there's no SERO, it 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 SERO and S2L_SUB_LSP object encoding is described in detail in section 19.
To avoid repeating path information for the parts of S2L sub-LSPs that share hops, that info gets deduced from the explicit routes of other S2L sub-LSPs using explicit route compression in SEROs 🧠.
A
|
|
B
|
|
C----D----E
| | |
| | |
F G H-------I
| |\ |
| | \ |
J K L M
| | | |
| | | |
N O P Q--RFigure 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) 🌟. Say all six S2L sub-LSPs are signaled in one Path message, and the S2L sub-LSP to LSR F is the first one, with the rest as subsequent S2L sub-LSPs. Here's one way ingress LSR A could 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-RAfter 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 like this 📨:
S2L sub-LSP-F: ERO = {D, C, F}, <S2L_SUB_LSP> object-F
S2L sub-LSP-N: SERO = {D, G, J, N}, <S2L_SUB_LSP> object-NLSR E also sends a Path message to LSR H, and here's one way to encode the S2L sub-LSP explicit routes with compression 💫:
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-RAfter LSR H processes the incoming Path message from E, it sends Path messages to LSR K, LSR L, and LSR I 🔀. The encoding for the Path message to LSR K looks like this:
S2L sub-LSP-O: ERO = {K, O}, <S2L_SUB_LSP> object-OThe Path message LSR H sends to LSR L is encoded like this:
S2L sub-LSP-P: ERO = {L, P}, <S2L_SUB_LSP> object-PHere's one way LSR H can encode the S2L sub-LSP explicit routes in the Path message it sends 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-RThe explicit route encodings in the Path messages sent by LSRs D and Q are left as an exercise for the reader 😉.
This compression trick makes Path messages smaller ✂️. It also cuts down on the extra processing you'd get if every S2L sub-LSP had its explicit route encoded from ingress to egress. No assumptions are made about the ordering of the subsequent S2L sub-LSPs, so there's no assumed ordering of the SEROs in the Path message either 🤷♀️. Every LSR needs to process the ERO for the first S2L sub-LSP. An LSR only needs to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP if the first hop in the matching SERO is one of its own local addresses 📍. The branch LSR that is the first hop of a SERO passes the matching S2L sub-LSP downstream 🚀.
5. Path Message 💌
5.1. Path Message Format
This section covers the changes made to the Path message format from [RFC3209] and [RFC3473] 🛠️. The Path message now signals one or more S2L sub-LSPs. It does this by putting the S2L sub-LSP descriptor list into the Path message, like below 👇.
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[<S2L sub-LSP descriptor list>]Here's the format of the S2L sub-LSP descriptor list 📋:
<S2L sub-LSP descriptor list> ::= <S2L sub-LSP descriptor>
[ <S2L sub-LSP descriptor list> ]
<S2L sub-LSP descriptor> ::= <S2L_SUB_LSP>
[ <P2MP SECONDARY_EXPLICIT_ROUTE> ]Each LSR MUST use the common objects in the Path message, along with 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 🔍.
Going by the definition of <S2L sub-LSP descriptor>, each S2L_SUB_LSP object MAY be followed by a matching SERO 🙌. The first S2L_SUB_LSP object is the special one, since its explicit route is specified by the ERO. So the first S2L_SUB_LSP object SHOULD NOT be followed by an SERO, and if one does show up, it MUST be ignored 🙅♀️.
The RRO in the sender descriptor holds the upstream hops the Path message went through, and it applies to every S2L sub-LSP signaled in the Path message 🔁.
An IF_ID RSVP_HOP object MUST be used on links where there isn't a one-to-one association between a control channel and a data channel [RFC3471]. Otherwise, an RSVP_HOP object defined in [RFC2205] SHOULD be used 🎀.
Path message processing is covered in the next section 💖.
5.2. Path Message Processing ✨
Okay so the ingress LSR is the one who kicks things off 💅 It starts the setup of an S2L sub-LSP to every egress LSR that's a destination of the P2MP LSP 🦋. Each S2L sub-LSP gets tied to the same P2MP LSP through the same P2MP SESSION object and the same <Sender Address, LSP-ID> fields in the P2MP SENDER_TEMPLATE object, so they can all be combined into one P2MP LSP. It's giving teamwork 🫶. Another S2L sub-LSP from that same instance (aka the same P2MP LSP) SHOULD share resources with this one. The session for the P2MP TE tunnel comes from the P2MP SESSION object, each S2L sub-LSP is identified by the S2L_SUB_LSP object, and explicit routing for them is handled with the ERO and SEROs 🧚.
As mentioned earlier, you can signal S2L sub-LSPs for a given P2MP LSP in one or more Path messages, and one Path message can carry 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. That means such an LSR MUST be able to receive and process all objects listed in section 19 🔥. Iconic behavior.
5.2.1. Multiple Path Messages
Remember section 4? Either this tuple:
< [<EXPLICIT_ROUTE>]
<S2L_SUB_LSP> >or this one:
< [<P2MP SECONDARY_EXPLICIT_ROUTE>]
<S2L_SUB_LSP> >is used to specify an S2L sub-LSP 🌸. Multiple Path messages can be used to signal a P2MP LSP, and each Path message can signal one or more S2L sub-LSPs. If a Path message only has one S2L sub-LSP, each LSR along that S2L sub-LSP follows [RFC3209] procedures for processing the Path message, plus the S2L_SUB_LSP object processing described in this document.
Processing of Path messages with more than one S2L sub-LSP is covered in section 5.2.2 📖.
An ingress LSR MAY use multiple Path messages for signaling a P2MP LSP. This might be because one Path message may not be large enough to signal the whole P2MP LSP 😭. Or when new leaves get added to the P2MP LSP, they can be 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 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. So each Path message used to signal a P2MP LSP uses the same signaling attributes, 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 wherever they share hops, so you don't end up with multiple copies of the data being sent 🍓.
In certain cases, a transit LSR may need to generate multiple Path messages to signal state for a single received Path message. For instance, ERO expansion may overflow the resultant Path message 🙈. In that case, the message can be split into multiple Path messages so that each one 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 all carry the same SESSION object and the same <Source address, LSP-ID> in the SENDER_TEMPLATE object. To tell these Path messages apart, a <Sub-Group Originator ID, Sub-Group ID> tuple is introduced (also called the Sub-Group fields) and encoded in the SENDER_TEMPLATE object ✨. Multiple Path messages generated by an LSR to signal state for the same P2MP LSP have the same Sub-Group Originator ID and a different Sub-Group ID. The Sub-Group Originator ID MUST be set to the TE Router ID of the LSR that originates the Path message. Cases where a transit LSR may change the Sub-Group Originator ID of an incoming Path message are described below 👀. The Sub-Group Originator ID is globally unique, and the Sub-Group ID space is specific to the Sub-Group Originator ID.
5.2.2. Multiple S2L Sub-LSPs in One Path Message
The S2L sub-LSP descriptor list lets you signal one or more S2L sub-LSPs in one Path message 🧁. Each S2L sub-LSP descriptor describes a single S2L sub-LSP.
All LSRs MUST process the ERO corresponding to the first S2L sub-LSP if 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 message by each LSR along the explicit route specified by the ERO, if the ERO is present. Otherwise, it MUST be propagated using hop-by-hop routing towards the destination identified by the S2L_SUB_LSP object 🛣️.
An LSR MUST process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP as follows:
If the S2L_SUB_LSP object is followed by an SERO, the LSR MUST check the first hop in the SERO:
- If the first hop of the SERO identifies a local address of the LSR, and the LSR is also the egress identified by the S2L_SUB_LSP object, the descriptor MUST NOT be propagated downstream. The SERO may still be used for egress control per [RFC4003] 🎯.
- If the first hop of the SERO identifies a local address of the LSR, and the LSR is not the egress identified by the S2L_SUB_LSP object, the S2L sub-LSP descriptor MUST be included in a Path message sent to the next-hop determined from the SERO.
- If the first hop of the SERO is not a local address of the LSR, the S2L sub-LSP descriptor MUST be included in the Path message sent to the 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 the S2L_SUB_LSP object is not followed by an SERO, the LSR MUST examine the S2L_SUB_LSP object:
- If this LSR is the egress identified by the S2L_SUB_LSP object, the S2L sub-LSP descriptor MUST NOT be propagated downstream.
- If this LSR is not the egress identified by the S2L_SUB_LSP object, the LSR MUST make a routing decision to determine the next hop towards the egress, and MUST include the S2L sub-LSP descriptor in a Path message sent to that next hop. In this case, the LSR MAY insert an SERO into the S2L sub-LSP descriptor.
So a branch LSR MUST only propagate the relevant S2L sub-LSP descriptors to each downstream hop 🌿. An S2L sub-LSP descriptor list propagated on a downstream link MUST only contain the S2L sub-LSPs that are routed using that hop. This processing MAY result in a subsequent S2L sub-LSP in an incoming Path message becoming the first S2L sub-LSP in an outgoing Path message.
Heads up: if one or more SEROs contain loose hops, expanding those loose hops MAY overflow the Path message size 🚨. Section 5.2.3 describes how signaling for the set of S2L sub-LSPs can be split across 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 that Path message. 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 outgoing Path message by copying the RRO from the incoming Path message and appending its address. Each updated RRO MUST be formed using the rules in [RFC3209] (and updated by [RFC3473]), as appropriate 📝.
If an LSR is unable to support an S2L sub-LSP in a Path message (for example, it can't route towards the destination using the SERO), a PathErr message MUST be sent for the impacted S2L sub-LSP. Normal processing of the rest of the P2MP LSP SHOULD continue. The default behavior is that the remainder of the LSP is not impacted (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 an 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 sections 5.2.4 and 11 🚫.
5.2.3. Transit Fragmentation of Path State Information
Again, a transit LSR may need to generate multiple Path messages to signal state for a single received Path message 🧩. For instance, ERO expansion may overflow the resultant Path message. RSVP [RFC2205] disallows the use of IP fragmentation, so IP fragmentation MUST be avoided in this case. To achieve that, the multiple Path messages generated by the transit LSR are signaled with the Sub-Group Originator ID set to the TE Router ID of the transit LSR, and with a distinct Sub-Group ID for each Path message. So each distinct Path message generated by the transit LSR for the P2MP LSP carries a distinct <Sub-Group Originator ID, Sub-Group ID> tuple 💖.
When multiple Path messages are used by an ingress or transit node, each Path message SHOULD be identical except for the S2L sub-LSP related descriptor (e.g., SERO), message and hop information (e.g., INTEGRITY, MESSAGE_ID, and RSVP_HOP), and the Sub-Group fields of the SENDER_TEMPLATE objects. Except when a make-before-break operation is being performed (as specified in section 14.1), the tunnel sender address and LSP ID fields MUST be the same in each message. For transit nodes, they MUST be the same as the values in the received Path message 🔁.
As described above, one case where the Sub-Group Originator ID of a received Path message gets changed is fragmentation of a Path message at a transit node. Another case is when the Sub-Group Originator ID of a received Path message may be changed in the outgoing Path message and set to that of the LSR originating the Path message, based on local policy. For instance, an 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 Sub-Group Originator ID is not changed 🌈.
5.2.4. Control of Branch Fate Sharing
An ingress LSR can control what happens to an LSP if there's a failure 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', so that any failure anywhere within the LSP tree causes the entire P2MP LSP to fail 🫣.
The ingress LSP may request 'LSP integrity' by setting bit 3 of the Attributes Flags TLV. The bit is set if LSP integrity is required ✅.
It is RECOMMENDED to use the LSP_REQUIRED_ATTRIBUTES object [RFC4420] 👑.
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 message carrying the error "Routing Error"/"Unsupported LSP Integrity" 💀.
5.3. Grafting ✨
okay bestie, so grafting is just the fancy word for adding egress LSR(s) to a P2MP LSP that already exists 🌸 It's so iconic because egress nodes can join at totally different times 💅
There are two ways to add S2L sub-LSPs to a P2MP LSP 🦋 The first is to toss new S2L sub-LSPs into an existing Path message and then refresh the whole entire Path message 🫶 Path message processing from section 4 is what actually adds those S2L sub-LSPs to the P2MP LSP ✨ Heads up, though: once you add one or more S2L sub-LSPs to a Path message, the ERO compression encoding might have to be recomputed 💀
The second way is to use the incremental updates from section 10.1 🎀 The egress LSRs can get added by signaling only the S2L sub-LSPs that are impacted, all in a brand new Path message. That means the other S2L sub-LSPs don't have to be re-signaled. Lowkey the main character move 👑
6. Resv Message ✨
6.1. Resv Message Format
okay so the Resv message follows the [RFC3209] and [RFC3473] format 🧚 Here's the grammar, bestie:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FF flow descriptor>
| <FF flow descriptor list>
<FF flow descriptor>
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>The FF flow descriptor and SE filter spec get a little makeover so they can identify the S2L sub-LSPs they belong to 🌈
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<S2L sub-LSP flow descriptor list> ::=
<S2L sub-LSP flow descriptor>
[ <S2L sub-LSP flow descriptor list> ]
<S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
[ <P2MP_SECONDARY_RECORD_ROUTE> ]FILTER_SPEC is defined in section 19.4 🍓
The S2L sub-LSP flow descriptor has the same format as the S2L sub-LSP descriptor in section 4.1, with one plot twist: a P2MP_SECONDARY_RECORD_ROUTE object shows up in place of a P2MP SECONDARY_EXPLICIT_ROUTE object 🦋 The P2MP_SECONDARY_RECORD_ROUTE objects follow the same compression mechanism as the P2MP SECONDARY_EXPLICIT_ROUTE objects 💜 Also, a Resv message can signal multiple S2L sub-LSPs, and they might belong to the same FILTER_SPEC object or to different ones 👀 The same label SHOULD be allocated if the <Sender Address, LSP-ID> fields of the FILTER_SPEC object are the same 🎀
But different labels MUST be allocated if the <Sender Address, LSP-ID> of the FILTER_SPEC object is different 🚫 That's because it means the FILTER_SPEC is talking about a different P2MP LSP, bestie 😭
6.2. Resv Message Processing
The egress LSR MUST follow normal RSVP procedures when it's originating a Resv message 🫶 The format is the one from section 6.1, and as usual, the Resv message carries the label that the egress LSR allocated ✨
A node upstream of the egress node MUST allocate its own label and pass it upstream in the Resv message 🌸 The node MAY combine multiple flow descriptors, from different Resv messages received from downstream, into one Resv message sent upstream 🧚 A Resv message MUST NOT be sent upstream until at least one Resv message has been received from a downstream neighbor 🙈 And when the integrity bit is set in the LSP_REQUIRED_ATTRIBUTE object, the Resv message MUST NOT be sent upstream until all Resv messages have been received from the downstream neighbors 🔥
Each Fixed-Filter (FF) flow descriptor or Shared-Explicit (SE) filter spec sent upstream in a Resv message includes an S2L sub-LSP descriptor list 💖 Every such FF flow descriptor or SE filter spec for the same P2MP LSP, whether it's on one Resv message or on several, and on the same Resv, MUST be allocated the same label 🌈 FF flow descriptors or SE filter specs SHOULD use the same label across multiple Resv messages too ✨
The node that sends the Resv message upstream for a P2MP LSP MUST associate the label it assigned with all the labels it received from downstream Resv messages for that P2MP LSP 🦋 Also, a transit node may become a replication point later on, when a branch gets attached to it 🌿 So this sets up a P2MP LSP from the ingress LSR all the way to the egress LSRs, bestie 💅
The ingress LSR may need to know when all the desired egresses have been reached 👀 It figures that out using S2L_SUB_LSP objects 🎀
Each branch node MAY forward a single Resv message upstream for each Resv message it gets from a downstream receiver 🧚 Heads up, there could be a LOT of Resv messages at and near the ingress LSR for an LSP with many receivers 😭 A branch LSR SHOULD combine Resv state from multiple receivers into a single Resv message to send upstream (see section 6.2.1) 💜 But this might overflow the Resv message, especially since the number of receivers downstream of a branch LSR grows the closer that LSR gets to the ingress LSR 💀 So a branch LSR MAY choose to send more than one Resv message upstream and split the Resv state between them 🫶
When a transit node sets the Sub-Group Originator field in a Path message, it MUST replace the Sub-Group fields received in the FILTER_SPEC objects of any associated Resv messages with the value it originally received in the Sub-Group fields of the Path message from the upstream neighbor ✨
ResvErr message generation is unchanged 🌸 Nodes that propagate a received ResvErr message MUST use the Sub-Group field values carried in the corresponding Resv message 💅
6.2.1. Resv Message Throttling
A branch node may have to send a revised Resv message upstream whenever a Resv message for an S2L sub-LSP changes after it's received from one of the downstream neighbors 🙈 This can result in a flood of Resv messages going upstream, especially when the S2L sub-LSPs are first being established 😵 To calm things down, branch nodes can limit how often they send Resv messages 🌈 Specifically, when the only change in a Resv message is in one or more P2MP_SECONDARY_RECORD_ROUTE objects (SRROs), the branch node SHOULD transmit the Resv message only after a delay time has passed since the previous Resv message for the same session was sent 🫶 That delayed Resv message SHOULD include SRROs for all branches 🦋 A suggested value for the delay time is thirty seconds, and delay times SHOULD generally be longer than 1 second ⏳ How the throttling works and what the delay timer is set to are implementation dependent and out of scope for this document 💜
6.3. Route Recording
6.3.1. RRO Processing
A Resv message for a P2P LSP contains a recorded route if the ingress LSR asked for route recording by including an RRO in the original Path message 🧚 The same rule applies when signaling P2MP LSPs ✨ So including an RRO in the Path message used to signal one or more S2L sub-LSPs triggers a recorded route for each sub-LSP in the Resv message 🌸
The recorded route of the first S2L sub-LSP is encoded in the RRO 🎀 Recorded routes for the later S2L sub-LSPs are encoded in P2MP_SECONDARY_RECORD_ROUTE objects (SRROs), whose format is specified in section 19.5 💖 Each S2L_SUB_LSP object in a Resv is associated with an RRO or an SRRO 🦋 The first S2L_SUB_LSP object (for the first S2L sub-LSP) is associated with the RRO 🫶 Each subsequent S2L_SUB_LSP object (for the subsequent S2L sub-LSPs) is followed by an SRRO holding the recorded route for that S2L sub-LSP, from the leaf to a branch 🌿 With the RRO and SRROs together, the ingress node can figure out the end-to-end path for each S2L sub-LSP 👑
6.4. Reservation Style
The reservation style considerations in a Resv message apply as described in [RFC3209] 💅 The reservation style in Resv messages can be either FF or SE 🌈 All P2MP LSPs that belong to the same P2MP Tunnel MUST be signaled with the same reservation style 🙈 Whether the style is FF or SE, the S2L sub-LSPs that belong to the same P2MP LSP SHOULD share labels where they share hops 🫶 If the S2L sub-LSPs that belong to the same P2MP LSP share labels, then they MUST share resources ✨ If the reservation style is FF, then S2L sub-LSPs that belong to different P2MP LSPs MUST NOT share resources or labels 🚫 If the reservation style is SE, then S2L sub-LSPs that belong to different P2MP LSPs and the same P2MP tunnel SHOULD share resources where they share hops, but they MUST not share labels in packet environments 💀
7. PathTear Message ✨
7.1. PathTear Message Format
The PathTear message is formatted like this, bestie 🧚
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
[ [ <MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK> ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
[ <sender descriptor> ]
[ <S2L sub-LSP descriptor list> ]
<S2L sub-LSP descriptor list> ::= <S2L_SUB_LSP>
[ <S2L sub-LSP descriptor list> ]The definition of <sender descriptor> is not changed by this document 🎀
7.2. Pruning
Pruning is the operation of removing egress LSR(s) from an existing P2MP LSP 🦋 It's basically grafting's opposite, and it lets egress nodes leave a P2MP LSP at different points in time 💅 This section explains the mechanisms for doing it 🌸
7.2.1. Implicit S2L Sub-LSP Teardown
Implicit teardown uses standard RSVP message processing 🧚 Per standard RSVP processing, an S2L sub-LSP can be removed from a P2MP TE LSP by sending a modified message for the Path or Resv message that previously advertised that S2L sub-LSP ✨ This modified message MUST list all S2L sub-LSPs that are not being removed 🫶 When using this approach, a node processing a message that removes an S2L sub-LSP from a P2MP TE LSP MUST ensure that the S2L sub-LSP is not included in any other Path state associated with the session before it interrupts the data path to that egress 🙈 All other message processing stays the same 💖
When implicit teardown is used to delete one or more S2L sub-LSPs by modifying a Path message, a transit LSR may have to generate a PathTear message downstream to delete one or more of those S2L sub-LSPs 😭 This can happen if, after the implicit deletion, there are no remaining S2L sub-LSPs to send in the corresponding Path message downstream 💀
7.2.2. Explicit S2L Sub-LSP Teardown ✨
okay bestie, explicit S2L sub-LSP teardown works by generating a PathTear message for the matching Path message 🦋 The PathTear gets sent with the SESSION and SENDER_TEMPLATE objects for the P2MP LSP, plus the <Sub-Group Originator ID, Sub-Group ID> tuple from that Path message. This approach SHOULD be used when all the egresses signaled by a Path message need to be removed from the P2MP LSP. Other S2L sub-LSPs from other sub-groups, signaled using other Path messages, are not affected by the PathTear 💅
A transit LSR that passes the PathTear downstream MUST make sure it sets the <Sub-Group Originator ID, Sub-Group ID> tuple in the PathTear to the values used in the Path message that set up the S2L sub-LSPs being torn down 🫶 The transit LSR may need to generate multiple PathTear messages for one incoming PathTear, if it did transit fragmentation for the matching incoming Path message. Lowkey a lot, but it's giving organized 🧚
When the ingress removes a P2MP LSP, a PathTear message MUST be generated for each Path message that was used to signal the P2MP LSP 🌸
8. Notify and ResvConf Messages ✨
8.1. Notify Messages
okay so the Notify Request object and Notify message are explained in [RFC3473] 💜 Both the object and the message SHALL be supported for delivering upstream and downstream notifications. Anything not covered in this section MUST comply to [RFC3473], no cap 🎀
1. Upstream Notification 🦋
If a transit LSR sets the Sub-Group Originator ID in the SENDER_TEMPLATE object of a Path message to its own address, and the incoming Path message carries a Notify Request object, then this LSR MUST change the Notify node address in the Notify Request object to its own address in the Path message it sends. Main character energy 👑
If this LSR later gets a matching Notify message from a downstream LSR, then it MUST:
- send a Notify message upstream toward the Notify node address that the LSR got in the Path message.
- process the Sub-Group fields of the
SENDER_TEMPLATEobject on the received Notify message, and change their values in the forwarded Notify message so they match the Sub-Group field values in the original Path message received from upstream. 🔥
The receiver of an (upstream) Notify message MUST identify the state referenced in this message based on the SESSION and SENDER_TEMPLATE 💅
2. Downstream Notification 🌈
A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value it got in the matching Path message. If the incoming Resv message carries a Notify Request object, then:
- If there is at least one other incoming Resv message that carries a Notify Request object, and the LSR merges these Resv messages into one Resv message that gets sent upstream, the LSR MUST set the Notify node address in the Notify Request object to its Router ID. ✨
- Else if the LSR sets the Sub-Group Originator ID (in the outgoing Path message that matches the received Resv message) to its own address, the LSR MUST set the Notify node address in the Notify Request object to its Router ID.
- Else the LSR MUST pass the Notify Request object along unchanged, in the Resv message it sends upstream.
If this LSR later gets a matching Notify message from an upstream LSR, then it MUST:
- process the Sub-Group fields of the
FILTER_SPECobject in the received Notify message, and change their values in the forwarded Notify message so they match the Sub-Group field values in the original Path message this LSR sent downstream. 🫶 - send a Notify message downstream toward the Notify node address that the LSR got in the Resv message.
The receiver of a (downstream) Notify message MUST identify the state referenced in the message based on the SESSION and FILTER_SPEC objects 🧚
Here's the tea for a P2MP LSP: an upstream Notify message generated on one branch results in a Notify being delivered to the upstream Notify node address. The receiver of the Notify message MUST NOT assume the Notify message applies to all downstream egresses, but MUST look at the information in the message to figure out which egresses it applies to. Not every egress is involved, bestie 🙈
Downstream Notify messages MUST be replicated at branch LSRs according to the Notify Request objects received on Resv messages. Some downstream branches might not ask for Notify messages, but every branch that did ask MUST receive them 🦋
8.2. ResvConf Messages
ResvConf messages are explained in [RFC2205] 💖 ResvConf processing in [RFC3473] and [RFC3209] is taken straight from [RFC2205]. An egress LSR MAY include a RESV_CONFIRM object that holds the egress LSR's address. The object and message SHALL be supported for confirming receipt of the Resv message in P2MP TE LSPs. Anything not covered in this section MUST comply to [RFC2205] ✨
A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value it got in the matching Path message. If any of the incoming Resv messages for a single Path message carry a RESV_CONFIRM object, then the LSR MUST include a RESV_CONFIRM object in the matching Resv message it sends upstream. If the Sub-Group Originator ID is its own address, then it MUST set the receiver address in the RESV_CONFIRM object to this address. Otherwise it MUST pass the object along unchanged 🌸
A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value it got in the matching Path message. If an incoming Resv message for a single Path message carries a RESV_CONFIRM object, then the LSR MUST include a RESV_CONFIRM object in the matching Resv message it sends upstream, and:
- If there is at least one other incoming Resv message that carries a RESV_CONFIRM object, and the LSR merges these Resv messages into one Resv message that gets sent upstream, the LSR MUST set the receiver address in the RESV_CONFIRM object to its Router ID. 💅
- If the LSR sets the Sub-Group Originator ID (in the outgoing Path message that matches the received Resv message) to its own address, the LSR MUST set the receiver address in the RESV_CONFIRM object to its Router ID.
- Else the LSR MUST pass the RESV_CONFIRM object along unchanged, in the Resv message it sends upstream.
If this LSR later gets a matching ResvConf message from an upstream LSR, then it MUST:
- process the Sub-Group fields of the
FILTER_SPECobject in the received ResvConf message, and change their values in the forwarded ResvConf message so they match the Sub-Group field values in the original Path message this LSR sent downstream. 🫶 - send a ResvConf message downstream toward the receiver address that the LSR got in the RESV_CONFIRM object in the Resv message.
The receiver of a ResvConf message MUST identify the state referenced in this message based on the SESSION and FILTER_SPEC objects 🎀
The consequence for a P2MP LSP is that a ResvConf message generated at the ingress results in a ResvConf message being delivered to the branch and then to the receiver address in the original RESV_CONFIRM object. The receiver of a ResvConf message MUST NOT assume the ResvConf message should go to all downstream egresses, but MUST replicate the message according to the RESV_CONFIRM objects received in Resv messages. Some downstream branches might not ask for ResvConf messages, and ResvConf messages SHOULD NOT be sent on those branches. Every downstream branch that asked for ResvConf messages MUST be sent one 🍓
9. Refresh Reduction ✨
The refresh reduction procedures described in [RFC2961] apply just as well to the P2MP LSPs in this document 🌈 Refresh reduction works on individual messages and the state they install or maintain, and that's still true for P2MP LSPs 💜
10. State Management 👑
State signaled by a P2MP Path message is identified by a local implementation using the <P2MP ID, Tunnel ID, Extended Tunnel ID> tuple as part of the SESSION object, and the <Tunnel Sender Address, LSP ID, Sub-Group Originator ID, Sub-Group ID> tuple as part of the SENDER_TEMPLATE object 🦋
Extra information signaled in the Path/Resv message is part of the state a local implementation creates. This includes PHOP/NHOP and SENDER_TSPEC/FILTER_SPEC objects 🧚
10.1. Incremental State Update
okay so RSVP (as defined in [RFC2205], and as extended by RSVP-TE [RFC3209] and GMPLS [RFC3473]) uses the same basic approach to state communication and sync -- full state gets sent in every state advertisement message 💅 Per [RFC2205], Path and Resv messages are idempotent. [RFC2961] also sorts RSVP messages into two types (trigger and refresh messages) and improves RSVP message handling and state refresh scaling, but it doesn't change the full state advertisement nature of Path and Resv messages 🌸 That nature has lots of benefits, but also some drawbacks. One notable drawback shows up when you make an incremental change to previously advertised state: you pay the message overhead of sending the full state, plus the cost of processing it 🙈 It's desirable to fix this and add or delete S2L sub-LSPs to or from a P2MP LSP by incrementally updating the existing state ✨
The procedures in this document can be used to add S2L sub-LSPs to a P2MP LSP incrementally, or delete them, by letting a Path or a PathTear message incrementally change the existing P2MP LSP Path state 🎀
As described in section 5.2, multiple Path messages can be used to signal a P2MP LSP. The Path messages are told apart by different <Sub-Group Originator ID, Sub-Group ID> tuples in the SENDER_TEMPLATE object. To add S2L sub-LSP state incrementally, the ingress LSR uses a separate Path message with a new Sub-Group ID to add the new S2L sub-LSPs 🌈 The Sub-Group Originator ID MUST be set to the TE Router ID [RFC3477] of the node that sets the Sub-Group ID 💖
This keeps the idempotent nature of RSVP Path messages, avoids tracking the expiration of individual S2L sub-LSP state, and still gives you the ability to do incremental P2MP LSP state updates 🦋
10.2. Combining Multiple Path Messages ✨
okay so there's a tradeoff here, bestie 🦋 the ingress needs Path messages to keep the P2MP LSP alive, but if it keeps stuffing S2L sub-LSPs into one existing Path message, every add means full state messages all over again 😭 so you can combine S2L sub-LSPs that were advertised in different Path messages into one single Path message, which cuts down how many Path messages you need. a transit node that did fragmentation can do this too 💅 once it's able to merge the Path messages it generated earlier. this usually comes up when one or more S2L sub-LSPs get pruned from the existing Path states.
the node doing the combining signals the new Path message with all the S2L sub-LSPs that are being combined into it. this Path message MAY contain new Sub-Group ID field values 🌸 and when a transit LSR gets a new Path and Resv message for an S2L sub-LSP that already exists, it creates state that includes the new instance of that S2L sub-LSP ✨
the S2L sub-LSP SHOULD keep being advertised in both the old and new Path messages until a Resv message that lists the S2L sub-LSP and corresponds to the new Path message gets received by the combining node 🫶 so until that moment, state for the S2L sub-LSP SHOULD be maintained as part of the Path state for both the old and the new Path message (see section 3.1.3 of [RFC2205]). once that happens, the S2L sub-LSP SHOULD be deleted from the old Path state using the procedures of section 7. iconic cleanup 🧹💖
a Path message with Sub-Group_ID(n) may signal a set of S2L sub-LSPs that belong partially or entirely to an already existing Sub-Group_ID(i), or a totally non-overlapping new set. a newly received Path message that matches the SESSION object and Sender Tunnel Address, LSP ID, Sub-Group Originator ID> with existing Path state carrying the same or different Sub-Group_ID, referred to as Sub-Group_ID(n), gets processed like this:
- if
Sub-Group_ID(i)=Sub-Group_ID(n), then the S2L Sub-LSPs that are in both get refreshed 🔄 new S2L Sub-LSPs get added to theSub-Group_ID(i)Path state, and any S2L Sub-LSPs that are inSub-Group_ID(i)but not inSub-Group_ID(n)get deleted from that state. main character glow-up ✨ - if
Sub-Group_ID(i)!=Sub-Group_ID(n), then a newSub-Group_ID(n)Path state gets created for the S2L Sub-LSPs signaled bySub-Group_ID(n). the S2L Sub-LSPs in the existingSub-Group_ID(i)Path state (whether or not they're in the newly receivedSub-Group_ID(n)Path message) get left unmodified, see above 🦋
11. Error Processing 🚨
okay bestie, PathErr and ResvErr messages get processed the regular RSVP-TE way 💅 and here's the tea: an LSR that gets a PathErr/ResvErr for one particular S2L sub-LSP only changes the state for that S2L sub-LSP. the other S2L sub-LSPs are not impacted at all 🫶 BUT if the ingress node asks for 'LSP integrity', an error reported on one branch of a P2MP TE LSP for a particular S2L sub-LSP can change the state of any other S2L sub-LSP of that same P2MP TE LSP 😭 we'll dig into that more in section 11.3.
11.1. PathErr Messages 🌈
the PathErr message will include one or more S2L_SUB_LSP objects 🎀 and the updated format looks like this:
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[ <S2L sub-LSP descriptor list> ]the way a PathErr message gets generated is totally unchanged 💁♀️ but nodes that set the Sub-Group Originator field and then pass a received PathErr message upstream MUST replace the Sub-Group fields in that message with the values they got in the Sub-Group fields of the Path message from the upstream neighbor 🔁 and bestie, the receiver of a PathErr can figure out exactly which outgoing Path message and outgoing interface got the error, just from those Sub-Group fields 🧚 the S2L sub-LSP descriptor list is defined in section 5.1.
11.2. ResvErr Messages 💜
the ResvErr message will include one or more S2L_SUB_LSP objects too 😤 and its updated format is:
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>ResvErr generation is also unmodified 🍓 but nodes that set the Sub-Group Originator field and then pass a received ResvErr message downstream MUST replace the Sub-Group fields in it with the values that were set in the Sub-Group fields of the Path message sent to the downstream neighbor 💅 same deal as before: the receiver can tell which outgoing Resv message and outgoing interface are affected, just from those Sub-Group fields. the flow descriptor list is defined in section 6.1.
11.3. Branch Failure Handling 🌸
during setup and during normal operation, PathErr messages may get received at a branch node 👀 in every case, a received PathErr message gets processed per the standard rules first. so the PathErr message travels hop-by-hop to the ingress/branch LSR for that Path message. the intermediate nodes between here and that ingress/branch LSR MAY inspect the message but take no action on it 🙈 and the behavior of a branch LSR that generates a PathErr message is under the control of the ingress LSR.
the default is that the PathErr message does not have the Path_State_Removed flag set. BUT if the ingress LSR set the LSP integrity flag on the Path message (see the LSP_REQUIRED_ATTRIBUTEs object in section 5.2.4), and the Path_State_Removed flag is supported, then the LSR generating a PathErr to report a branch failure of the P2MP LSP SHOULD set the Path_State_Removed flag 🚩
a branch LSR that receives a PathErr during LSP setup with the Path_State_Removed flag set MUST act according to the wishes of the ingress LSR. the default is that the branch LSR clears the Path_State_Removed flag on the PathErr and sends it further upstream, and it does not tear down any other branches of the LSP 🫧 however, if the LSP integrity flag is set on the Path message, the branch LSR MUST send PathTear on all other downstream branches and send the PathErr message upstream with the Path_State_Removed flag set.
a branch LSR that receives a PathErr message with the Path_State_Removed flag clear MUST act according to the wishes of the ingress LSR 💖 the default is that the branch LSR forwards the PathErr upstream and takes no further action. but if the LSP integrity flag is set on the Path message, the branch LSR MUST send PathTear on all downstream branches and send the PathErr upstream with the Path_State_Removed flag set (per [RFC3473]).
in all cases, the PathErr message forwarded by a branch LSR MUST contain the S2L sub-LSP identification and explicit routes of all branches that are reported by received PathErr messages, AND all branches that the branch LSR explicitly tears down 🧾 complete accountability, no notes 😤
12. Admin Status Change 🔄
a branch node that receives an ADMIN_STATUS object processes it normally, and it also relays the ADMIN_STATUS object in a Path on every branch 🦋 all the Path messages may be sent to the downstream neighbors at the same time.
downstream nodes process the change in the ADMIN_STATUS object per [RFC3473], including generating Resv messages 💅 and when the last upstream ADMIN_STATUS object that was received had the R bit set, branch nodes wait for a Resv message with a matching ADMIN_STATUS object (or a corresponding PathErr or ResvTear message) on all branches before they relay a corresponding Resv message upstream ⏳ patience is a whole vibe, bestie 🫶
13. Label Allocation on LANs with Multiple Downstream Nodes 🧚
a branch LSR of a P2MP LSP on an Ethernet LAN segment SHOULD send one copy of the data traffic per downstream LSR connected on that LAN for that P2MP LSP 🌈 and procedures for preventing MPLS labeled traffic replication in this case are beyond the scope of this document, so that's a whole other story 📚
14. P2MP LSP and Sub-LSP Re-Optimization 🦋
okay so it's totally possible to change the path that P2MP LSPs use to reach the destinations of the P2MP tunnel ✨ there are two methods for this. the first is make-before-break, defined in [RFC3209], and the second uses the sub-groups we defined above 💜
14.1. Make-before-Break 💖
in this case, all the S2L sub-LSPs get signaled with a different LSP ID by the ingress LSR, and they follow the make-before-break procedure defined in [RFC3209] 🫶 so a brand new P2MP LSP gets established. each S2L sub-LSP is signaled with a different LSP ID that matches the new P2MP LSP. once traffic has moved over to the new P2MP LSP, the ingress can tear down the old P2MP LSP 🧹 this works for re-optimizing the path of the entire P2MP LSP OR just the paths to a subset of its destinations. but heads up bestie: when you're modifying just a portion of the P2MP LSP, this approach still requires the entire P2MP LSP to be re-signaled 😭
14.2. Sub-Group-Based Re-Optimization 🌸
any node may start re-optimizing a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple Path messages ✨
to alter the path taken by a particular set of S2L sub-LSPs, the node starting the path change sends one or more separate Path messages for the same P2MP LSP, each with a new Sub-Group ID 🔁 generating these Path messages, each with one or more S2L sub-LSPs, follows the procedures in section 5.2. just like in section 10.2, a particular egress keeps getting advertised in both the old and new Path messages until a Resv message that lists the egress and corresponds to the new Path message gets received by the re-optimizing node 🫧 at that point, the egress SHOULD be deleted from the old Path state using the procedures of section 7, and then sub-tree re-optimization is complete 🎉👑
sub-group-based re-optimization may cause some transient data duplication 😬 because the new Path messages for a set of S2L sub-LSPs might transit one or more nodes that still have the old Path state for that same set of S2L sub-LSPs 💀
and as always, a node may choose to combine multiple Path messages as described in section 10.2 💅🫶
15. Fast Reroute ✨
okay bestie, fast reroute time 🏃♀️💨 [RFC4090] extensions can be used to do fast reroute for the mechanism in this doc when it's applied within packet networks. GMPLS also brings other protection techniques that work for packet and non-packet environments [RFC4873], but we're not going into those here 🙈. This section only applies to LSRs that support [RFC4090].
This section uses terminology from [RFC4090], and the fast reroute procedures defined in [RFC4090] MUST be followed unless stated below 💅. The head-end and transit LSRs MUST follow the SESSION_ATTRIBUTE and FAST_REROUTE object processing from [RFC4090] for each Path message and S2L sub-LSP of a P2MP LSP. Each S2L sub-LSP of a P2MP LSP MUST have the same protection characteristics, no mixing 🫶. The RRO processing MUST apply to SRRO as well unless modified below.
The sections that follow walk through how fast reroute can be applied to P2MP MPLS TE LSPs in all the main operational scenarios. This doc doesn't go through the detailed steps for every imaginable usage case, and those might show up in future documents if they're needed 🧚.
15.1. Facility Backup
Facility backup can be used for link or node protection of LSRs on the path of a P2MP LSP. The downstream labels MUST be learned by the Point of Local Repair (PLR), as specified in [RFC4090], from the label corresponding to the S2L sub-LSP in the RESV message. Processing of SEROs signaled in a backup tunnel MUST follow backup tunnel ERO processing described in [RFC4090].
15.1.1. Link Protection
If link protection is desired, a bypass tunnel MUST be used to protect the link between the PLR and next-hop. Thus all S2L sub-LSPs that use the link SHOULD be protected in the event of link failure. Note that all such S2L sub-LSPs belonging to a particular instance of a P2MP tunnel SHOULD share the same outgoing label on the link between the PLR and the next-hop as per section 5.2.1. This is the P2MP LSP label on the link. Label stacking is used to send data for each P2MP LSP into the bypass tunnel. The inner label is the P2MP LSP label allocated by the next-hop 🎀.
During failure, Path messages for each S2L sub-LSP that is affected MUST be sent to the Merge Point (MP) by the PLR. It is RECOMMENDED that the PLR uses the sender template-specific method to identify these Path messages. Hence, the PLR will set the source address in the sender template to a local PLR address.
The MP MUST use the LSP-ID to identify the corresponding S2L sub-LSPs. The MP MUST NOT use the <Sub-Group Originator ID, Sub-Group ID> tuple while identifying the corresponding S2L sub-LSPs. In order to further process an S2L sub-LSP the MP MUST determine the protected S2L sub-LSP using the LSP-ID and the S2L_SUB_LSP object 🦋.
15.1.2. Node Protection
If node protection is desired the PLR SHOULD use one or more P2P bypass tunnels to protect the set of S2L sub-LSPs that transit the protected node. Each of these P2P bypass tunnels MUST intersect the path of the S2L sub-LSPs that they protect on an LSR that is downstream from the protected node. This constrains the set of S2L sub-LSPs being backed-up via that bypass tunnel to those S2L sub-LSPs that pass through a common downstream MP. This MP is the destination of the bypass tunnel. When the PLR forwards incoming data for a P2MP LSP into the bypass tunnel, the outer label is the bypass tunnel label and the inner label is the label allocated by the MP to the set of S2L sub-LSPs belonging to that P2MP LSP.
After detecting failure of the protected node the PLR MUST send one or more Path messages for all protected S2L sub-LSPs to the MP of the protected S2L sub-LSP. It is RECOMMENDED that the PLR uses the sender template-specific method to identify these Path messages. Hence the PLR will set the source address in the sender template to a local PLR address. The MP MUST use the LSP-ID to identify the corresponding S2L sub-LSPs. The MP MUST NOT use the <Sub-Group Originator ID, Sub-Group ID> tuple while identifying the corresponding S2L sub-LSPs, because the Sub-Group Originator ID might be changed by some LSR that is bypassed by the bypass tunnel. In order to further process an S2L sub-LSP the MP MUST determine the protected S2L sub-LSP using the LSP-ID and the S2L_SUB_LSP object.
Note that node protection MAY require the PLR to be branch capable in the data plane, as multiple bypass tunnels may be required to back up the set of S2L sub-LSPs passing through the protected node. If the PLR is not branch capable, the node protection mechanism described here is applicable to only those cases where all the S2L sub-LSPs passing through the protected node also pass through a single MP that is downstream from the protected node. A PLR MUST set the Node protection flag in the RRO/SRRO as specified in [RFC4090]. If a PLR is not branch capable, and one or more S2L sub-LSPs are added to a P2MP tree, and these S2L sub-LSPs do not transit the existing MP downstream of the protected node, then the PLR MUST reset this flag.
⚠️ It is to be noted that procedures in this section require P2P bypass tunnels. Procedures for using P2MP bypass tunnels are for further study.
15.2. One-to-One Backup
One-to-one backup, as described in [RFC4090], can be used to protect a particular S2L sub-LSP against link and next-hop failure. Protection may be used for one or more S2L sub-LSPs between the PLR and the next-hop. All the S2L sub-LSPs corresponding to the same instance of the P2MP tunnel between the PLR and the next-hop SHOULD share the same P2MP LSP label, as per section 5.2.1. All such S2L sub-LSPs belonging to a P2MP LSP MUST be protected.
The backup S2L sub-LSPs may traverse different next-hops at the PLR. Thus, the set of outgoing labels and next-hops for a P2MP LSP, at the PLR, may change once protection is triggered. Consider a P2MP LSP that is using a single next-hop and label between the PLR and the next-hop of the PLR. This may no longer be the case once protection is triggered. This MAY require a PLR to be branch capable in the data plane. If the PLR is not branch capable, the one-to-one backup mechanisms described here are only applicable to those cases where all the backup S2L sub-LSPs pass through the same next-hop downstream of the PLR. Procedures for one-to-one backup when a PLR is not branch capable and when all the backup S2L sub-LSPs do not pass through the same downstream next-hop are for further study 🌸.
It is recommended that the path-specific method be used to identify a backup S2L sub-LSP. Hence, the DETOUR object SHOULD be inserted in the backup Path message. A backup S2L sub-LSP MUST be treated as belonging to a different P2MP tunnel instance than the one specified by the LSP-ID. Furthermore, multiple backup S2L sub-LSPs MUST be treated as part of the same P2MP tunnel instance if they have the same LSP-ID and the same DETOUR objects. Note that, as specified in section 4, S2L sub-LSPs between different P2MP tunnel instances use different labels.
If there is only one S2L sub-LSP in the Path message, the DETOUR object applies to that sub-LSP. If there are multiple S2L sub-LSPs in the Path message, the DETOUR object applies to all the S2L sub-LSPs.
16. Support for LSRs That Are Not P2MP Capable
It may be that some LSRs in a network are capable of processing the P2MP extensions described in this document, but do not support P2MP branching in the data plane. If such an LSR is requested to become a branch LSR by a received Path message, it MUST respond with a PathErr message carrying the Error Code Routing Error and Error Value Unable to Branch 🙅♀️.
It is also conceivable that some LSRs, in a network deploying P2MP capability, may not support the extensions described in this document. If a Path message for the establishment of a P2MP LSP reaches such an LSR, it will reject it with a PathErr because it will not recognize the C-Type of the P2MP SESSION object 💀.
LSRs that do not support the P2MP extensions in this document may be included as transit LSRs by the use of LSP stitching [LSP-STITCH] and LSP hierarchy [RFC4206]. Note that LSRs that are required to play any other role in the network (ingress, branch or egress) MUST support the extensions defined in this document 👑.
The use of LSP stitching and LSP hierarchy [RFC4206] allows P2MP LSPs to be built in such an environment. A P2P LSP segment is signaled from the last P2MP-capable hop that is upstream of a legacy LSR to the first P2MP-capable hop that is downstream of it. This assumes that intermediate legacy LSRs are transit LSRs: they cannot act as P2MP branch points. Transit LSRs along this LSP segment do not process control plane messages associated with the P2MP LSP. Furthermore, these transit LSRs also do not need to have P2MP data plane capabilities, as they only need to process data belonging to the P2P LSP segment. Hence, these transit LSRs do not need to support P2MP MPLS. This P2P LSP segment is stitched to the incoming P2MP LSP. After the P2P LSP segment is established, the P2MP Path message is sent to the next P2MP-capable LSR as a directed Path message. The next P2MP-capable LSR stitches the P2P LSP segment to the outgoing P2MP LSP 🧵.
In packet networks, the S2L sub-LSPs may be nested inside the outer P2P LSP. Hence, label stacking can be used to enable use of the same LSP segment for multiple P2MP LSPs. Stitching and nesting considerations and procedures are described further in [LSP-STITCH] and [RFC4206].
There maybe overhead for an operator to configure the P2P LSP segments in advance, when it is desired to support legacy LSRs. It may be desirable to do this dynamically. The ingress can use IGP extensions to determine P2MP-capable LSRs [TE-NODE-CAP]. It can use this information to compute S2L sub-LSP paths such that they avoid legacy non-P2MP-capable LSRs. The explicit route object of an S2L sub-LSP path may contain loose hops if there are legacy LSRs along the path. The corresponding explicit route contains a list of objects up to the P2MP-capable LSR that is adjacent to a legacy LSR, followed by a loose object with the address of the next P2MP-capable LSR. The P2MP-capable LSR expands the loose hop using its Traffic Engineering Database (TED). When doing this it determines that the loose hop expansion requires a P2P LSP to tunnel through the legacy LSR. If such a P2P LSP exists, it uses that P2P LSP. Else it establishes the P2P LSP. The P2MP Path message is sent to the next P2MP-capable LSR using non-adjacent signaling 🔥.
The P2MP-capable LSR that initiates the non-adjacent signaling message to the next P2MP-capable LSR may have to employ a fast detection mechanism (such as [BFD] or [BFD-MPLS]) to the next P2MP-capable LSR. This may be needed for the directed Path message head-end to use node protection fast reroute when the protected node is the directed Path message tail 🫧.
Note that legacy LSRs along a P2P LSP segment cannot perform node protection of the tail of the P2P LSP segment 🥀.
17. Reduction in Control Plane Processing with LSP Hierarchy ✨
Okay bestie, so you can team up LSP hierarchy [RFC4206] with the P2MP LSP setup we just covered to cut down on control plane work on transit LSRs that are P2MP capable 💅. This only works in environments where LSP hierarchy can be used. Transit LSRs along a P2P LSP segment that a P2MP LSP is using don't process control plane messages for that P2MP LSP. Honestly, they aren't even aware of those messages, because they get tunneled over the P2P LSP segment 🫶. Less processing for them = iconic.
The P2P LSPs can be set up dynamically, like in the previous section, or they can be preconfigured. Take Figure 2 in section 24: PE1 can set up a P2P LSP to P1 and use that as an LSP segment 🦋. Then the Path messages for PE3 and PE4 can get tunneled over that segment. So P3 is totally not aware of the P2MP LSP and doesn't process the P2MP control messages. Main character energy 😌🌸
18. P2MP LSP Re-Merging and Cross-Over 🔥
This section is all about how to detect and deal with re-merge and cross-over 💜. A "re-merge" is when an ingress or transit node creates a branch of a P2MP LSP (a re-merge branch) that runs into the P2MP LSP again at another node farther down the tree 😭. This may happen because of stuff like a path calculation error, a manual configuration error, or network topology changes while the P2MP LSP is still being established. If you skip the procedures in this section, data duplication will happen 💀.
A "cross-over" is basically the same idea, with one big difference: at the intersecting node, the cross-over branch has a different outgoing interface and a different incoming interface, while re-merge doesn't 🌈. Cross-over might be necessary for certain combos of topology and technology, e.g., a transparent optical network where different wavelengths are needed to reach different leaf nodes ✨.
Normally, a P2MP LSP has a single incoming interface where all of its data comes in 🍓. That interface is identified by the IF_ID RSVP_HOP object if it's present, and by the interface the Path message was received on if the IF_ID RSVP_HOP object isn't there. But with dynamic LSP re-routing, the incoming interface can change 🔄.
Similarly, in both the re-merge and cross-over cases, a node gets a Path message for a given P2MP LSP that names a different incoming interface for the data. So the node needs to be able to tell dynamic LSP re-routing apart from the re-merge and cross-over cases 🧠.
Make-before-break is yet another similar-but-different case 🎀: the incoming interface for the make-before-break P2MP LSP might be different from the one for the original P2MP LSP. Even so, the two P2MP LSPs get treated as distinct (but related) LSPs, because they have different LSP ID field values in their SENDER_TEMPLATE objects.
18.1. Procedures
When a node receives a Path message, it MUST check whether it already has matching state for the P2MP LSP 🔍. Matching state is found by comparing the SESSION and SENDER_TEMPLATE objects in the received Path message with the SESSION and SENDER_TEMPLATE objects of each locally maintained P2MP LSP Path state. The P2MP ID, Tunnel ID, and Extended Tunnel ID in the SESSION object, plus the sender address and LSP ID in the SENDER_TEMPLATE object, are what get compared. If the node has matching state, and the incoming interface for the received Path message is different from the incoming interface of the matching P2MP LSP Path state, then the node MUST determine whether it's dealing with dynamic LSP rerouting or re-merge/cross-over 👀.
Dynamic LSP rerouting gets identified by checking whether there's any intersection between the set of S2L_SUB_LSP objects associated with the matching P2MP LSP Path state and the set of S2L_SUB_LSP objects in the received Path message. If there's any intersection, dynamic re-routing has happened. If there's no intersection between the two sets, then either re-merge or cross-over has happened. (Heads up: in the dynamic rerouting case, Path messages for the non-intersecting members of the set of S2L_SUB_LSPs associated with the matching P2MP LSP Path state will show up later on the new incoming interface ⏳.)
To identify the re-merge case, the node processing the received Path message MUST identify the outgoing interfaces associated with the matching P2MP Path state. Re-merge has happened if there's any intersection between the set of outgoing interfaces associated with the matching P2MP LSP Path state and the set of outgoing interfaces in the received Path message 🫣.
18.1.1. Re-Merge Procedures
There are two ways to deal with the re-merge case 💅. In the first, the node detecting the re-merge case (the re-merge node) lets the re-merge case persist, but data from all but one incoming interface gets dropped at the re-merge node. In the second, the re-merge node starts removing the re-merge branch(es) via signaling. Which approach you use is a matter of local policy 🎀.
A node MUST support both approaches, and it MUST allow user configuration of which approach is used 🙌.
When configured to let a re-merge case persist, the re-merge node MUST validate consistency between the objects in the received Path message and the matching P2MP LSP Path state. Any inconsistencies MUST result in a PathErr message sent to the previous hop of the received Path message. The Error Code is set to "Routing Problem", and the Error Value is set to "P2MP Re-Merge Parameter Mismatch" 🙅♀️.
If there are no inconsistencies, the node logically merges, from the downstream perspective, the control state of the incoming Path message with the matching P2MP LSP Path state 🧩. Specifically, procedures related to processing of messages received from upstream MUST NOT be modified from the upstream perspective. This includes processing related to refresh and state timeout. In addition to the standard upstream-related procedures, the node MUST ensure that each object received from upstream is appropriately represented within the set of Path messages sent downstream. For example, the received <S2L sub-LSP descriptor list> MUST be included in the set of outgoing Path messages. If there are any NOTIFY_REQUEST objects present, then the procedures defined in section 8 MUST be followed for all Path and Resv messages. Special processing is also needed for Resv processing. Specifically, any Resv message received from downstream MUST be mapped into an outgoing Resv message that gets sent to the previous hop of the received Path message. In practice, this means breaking the complete <S2L sub-LSP descriptor list> into subsets that match the incoming Path messages, and then building an outgoing Resv message for each incoming Path message 🧁.
When configured to let a re-merge case persist, the re-merge node receives data for the P2MP LSP on multiple incoming interfaces, but it MUST only send the data from one of those interfaces to its outgoing interfaces. In other words, the node MUST drop data from all but one incoming interface. This makes sure duplicate data doesn't go out on any outgoing interface 🚫. The mechanism used to pick the incoming interface is implementation specific and is outside the scope of this document 🤷♀️.
When configured to correct the re-merge branch via signaling, the re-merge node MUST send a PathErr message corresponding to the received Path message. The PathErr message MUST include all of the objects normally included in a PathErr message, plus one or more S2L_SUB_LSP objects from the set of sub-LSPs associated with the matching P2MP LSP Path state. A minimum of three S2L_SUB_LSP objects is RECOMMENDED. This lets the node that caused the re-merge identify the outgoing Path state associated with the valid portion of the P2MP LSP 🔎. The set of S2L_SUB_LSP objects in the received Path message MUST also be included. The PathErr message MUST include the Error Code "Routing Problem" and Error Value of "P2MP Re-Merge Detected". The node MAY set the Path_State_Removed flag [RFC3473]. As always, the PathErr message is sent to the previous hop of the received Path message 📨.
A node that receives a PathErr message containing the Error Value "Routing Problem/P2MP Re-Merge Detected" MUST determine if it's the node that created the re-merge case 🕵️♀️. It does this by checking whether there's any intersection between the set of S2L_SUB_LSP objects associated with the matching P2MP LSP Path state and the set of other-branch S2L_SUB_LSP objects in the received PathErr message. If there is, then that node created the re-merge case. Other-branch S2L_SUB_LSP objects are the ones the node detecting the re-merge case included in the PathErr message, taken from the matching P2MP LSP Path state. You can spot them because they won't be included in the Path message associated with the received PathErr message. See section 11.1 for more details on how that association is identified 🧵.
The node SHOULD remove the re-merge case by moving the S2L_SUB_LSP objects included in the Path message associated with the received PathErr message over to the outgoing interface associated with the matching P2MP LSP Path state 🚚. A trigger Path message for the moved S2L_SUB_LSP objects is then sent via that outgoing interface. If the received PathErr message did not have the Path_State_Removed flag set, the node SHOULD send a PathTear via the outgoing interface associated with the re-merge branch 🧹.
If using a new outgoing interface violates one or more SERO constraints, then a PathErr message containing the associated egresses and any identified S2L_SUB_LSP objects SHOULD be generated with the Error Code "Routing Problem" and Error Value of "ERO Resulted in Re-Merge" 🙃.
The only case where this process will fail is when all the listed S2L_SUB_LSP objects get deleted before the PathErr message propagates to the ingress 😬. In that case, the whole process gets corrected on the next (refresh or trigger) transmission of the offending Path message 🔁.
19. New and Updated Message Objects
This section presents the RSVP object formats as modified by this document 💖.
19.1. SESSION Object ✨
Okay so the SESSION object is the one that says "this is the P2MP tunnel" 💖 It reuses the existing SESSION C-Num, and we define new C-Types so it can carry a logical P2MP destination identifier 🎀 It's giving point-to-point RSVP-TE SESSION object vibes, except the destination address gets swapped out for the P2MP ID instead of the unicast Tunnel Endpoint address. Every S2L sub-LSP in the same P2MP LSP shares this one SESSION object, because they all belong to the same tunnel 🫶
The combo of SESSION, SENDER_TEMPLATE, and S2L_SUB_LSP is what identifies each S2L sub-LSP 🦋 It follows the existing P2P RSVP-TE idea: a SESSION object identifies a P2P tunnel, and that tunnel can hold multiple LSPs, each told apart by its own unique SENDER_TEMPLATE object. Main character energy 👑
19.1.1. P2MP LSP Tunnel IPv4 SESSION Object
Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P2MP ID 🍓 A 32-bit identifier used in the SESSION object that stays constant for the whole life of the P2MP tunnel. It encodes the P2MP Identifier, which is unique within the scope of the ingress LSR.
Tunnel ID 🌸 A 16-bit identifier used in the SESSION object that stays constant for the whole life of the P2MP tunnel.
Extended Tunnel ID 🔥 A 32-bit identifier used in the SESSION object that stays constant for the whole life of the P2MP tunnel. Ingress LSRs that want a globally unique identifier for the P2MP tunnel SHOULD put their tunnel sender address here. This address, the P2MP ID, and the Tunnel ID together give you a globally unique identifier for the P2MP tunnel ✨
19.1.2. P2MP LSP Tunnel IPv6 SESSION Object
This is basically the same as the P2MP IPv4 LSP SESSION object, with one twist: the extended tunnel ID may be set to a 16-byte identifier [RFC3209] 🧚
Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (16 bytes) |
| |
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+19.2. SENDER_TEMPLATE Object 💅
The SENDER_TEMPLATE object carries the ingress LSR source address. The LSP ID can be changed so a sender can share resources with itself, which means you can create multiple instances of the P2MP tunnel, each with a different LSP ID 🌈 Those instances are allowed to share resources with each other, and the S2L sub-LSPs for a particular instance all use the same LSP ID.
As described in section 4.2, we need a way to tell apart the different Path messages that signal state for the same P2MP LSP. That's done with a <Sub-Group ID Originator ID, Sub-Group ID> tuple, so the SENDER_TEMPLATE object gets modified to carry this info, as you'll see below 🦋
19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object
Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Group Originator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IPv4 tunnel sender address 🎀 See [RFC3209].
Sub-Group Originator ID 🫶 This is set to the TE Router ID of the LSR that originates the Path message. That's either the ingress LSR, or an LSR that re-originates the Path message with its own Sub-Group Originator ID.
Sub-Group ID 💜 An identifier of a Path message, used to tell apart multiple Path messages that signal state for the same P2MP LSP. You can think of it as identifying a group of one or more egress nodes targeted by this Path message.
LSP ID 🍓 See [RFC3209].
19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object
Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Sub-Group Originator ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IPv6 tunnel sender address 🌸 See [RFC3209].
Sub-Group Originator ID 👑 This is set to the IPv6 TE Router ID of the LSR that originates the Path message. That's either the ingress LSR, or an LSR that re-originates the Path message with its own Sub-Group Originator ID.
Sub-Group ID 🦋 As above in section 19.2.1.
LSP ID 🧚 See [RFC3209].
19.3. S2L_SUB_LSP Object 🫧
An S2L_SUB_LSP object identifies one particular S2L sub-LSP that belongs to the P2MP LSP 💖
19.3.1. S2L_SUB_LSP IPv4 Object
S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv4 C-Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 S2L Sub-LSP destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IPv4 Sub-LSP destination address 🎀 The IPv4 address of the S2L sub-LSP destination.
19.3.2. S2L_SUB_LSP IPv6 Object
S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv6 C-Type = 2
This is the same as the S2L IPv4 Sub-LSP object, except the destination address is a 16-byte IPv6 address 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 S2L Sub-LSP destination address (16 bytes) |
| .... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+19.4. FILTER_SPEC Object 🪞
The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE object, so it lines up with it perfectly ✨
19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object
Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = 12
The format of the P2MP LSP_IPv4 FILTER_SPEC object is identical to the P2MP LSP_IPv4 SENDER_TEMPLATE object 🎀
19.4.2. P2MP LSP_IPv6 FILTER_SPEC Object
Class = FILTER_SPEC, P2MP LSP_IPv6 C-Type = 13
The format of the P2MP LSP_IPv6 FILTER_SPEC object is identical to the P2MP LSP_IPv6 SENDER_TEMPLATE object 💜
19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) 🧭
The P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) is defined as identical to the ERO. Its class is the same as the SERO defined in [RFC4873], and it uses a new C-Type = 2. Its sub-objects are identical to the ones defined for the ERO 🦋
19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO) 🛤️
The P2MP SECONDARY_RECORD_ROUTE Object (SRRO) is defined as identical to the ERO. Its class is the same as the SRRO defined in [RFC4873], and it uses a new C-Type = 2. Its sub-objects are identical to the ones defined for the RRO 🫶
20. IANA Considerations 🏛️
20.1. New Class Numbers
IANA has assigned the following Class Numbers for the new object classes introduced 🎀 The Class Types for each of them are to be assigned via standards action. The sub-object types for the P2MP SECONDARY_EXPLICIT_ROUTE and P2MP_SECONDARY_RECORD_ROUTE follow the same IANA considerations as the ERO and RRO [RFC3209].
50 Class Name = S2L_SUB_LSP
C-Type
1 S2L_SUB_LSP_IPv4 C-Type
2 S2L_SUB_LSP_IPv6 C-Type20.2. New Class Types 💖
IANA has assigned the following C-Type values 🌈
Class Name = SESSION
C-Type
13 P2MP_LSP_TUNNEL_IPv4 C-Type
14 P2MP_LSP_TUNNEL_IPv6 C-Type
Class Name = SENDER_TEMPLATE
C-Type
12 P2MP_LSP_TUNNEL_IPv4 C-Type
13 P2MP_LSP_TUNNEL_IPv6 C-Type
Class Name = FILTER_SPEC
C-Type
12 P2MP LSP_IPv4 C-Type
13 P2MP LSP_IPv6 C-Type
Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])
C-Type
2 P2MP SECONDARY_EXPLICIT_ROUTE C-Type
Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])
C-Type
2 P2MP_SECONDARY_RECORD_ROUTE C-Type20.3. New Error Values ✨
Okay bestie, the "Routing Problem" Error Code gets five shiny new Error Values 💅 IANA has handed each one a number:
- The Error Value
Unable to Branchmeans the reporting LSR can't form a P2MP branch. 🌿 It got value 23. - The Error Value
Unsupported LSP Integritymeans a P2MP branch doesn't support the LSP integrity function that was asked for. 🔒 It got value 24. - The Error Value
P2MP Re-Merge Detectedmeans a node noticed a re-merge happening. 👀 It got value 25. - The Error Value
P2MP Re-Merge Parameter Mismatchis covered in section 18. 🧩 It got value 26. - The Error Value
ERO Resulted in Re-Mergeis also covered in section 18. 🔁 It got value 27.
20.4. LSP Attributes Flags 🏷️
IANA has been asked to look after the flags space in the Attributes Flags TLV, which rides inside the LSP_REQUIRED_ATTRIBUTES object [RFC4420]. This document adds one new flag, and it's a cutie:
Bit Number: 3
Meaning: LSP Integrity Required
Used in Attributes Flags on Path: Yes
Used in Attributes Flags on Resv: No
Used in Attributes Flags on RRO: No
Referenced Section of this Doc: 5.2.421. Security Considerations 🔐
Okay, this one is serious, so let's go slow. 🫶
In principle, this document doesn't add any brand new security issues on top of the ones already covered in [RFC3209], [RFC3473], and [RFC4206]. [RFC2205] spells out the message integrity mechanisms for hop-by-hop RSVP signaling, and those mechanisms apply to the hop-by-hop P2MP RSVP-TE signaling in this document. Then, [RFC3473] and [RFC4206] describe the security mechanisms for non hop-by-hop RSVP-TE signaling. Those cover the non hop-by-hop P2MP RSVP-TE signaling in this document too, especially in sections 16 and 17. 🛡️
An administration might want to limit the domain where P2MP TE tunnels can be set up. 🚧 This can be done by putting filters on various ports so they deny action on an RSVP path message with a SESSION object of type P2MP_LSP_IPv4 or P2MP_LSP_IPv6. Not me blocking the wrong tunnel 😭
The ingress LSR of a P2MP TE LSP figures out the leaves of that LSP based on the application using it. How an application uses a P2MP TE LSP is outside the scope of this document, so that's not our tea to spill here. 🍵 Applications MUST provide a mechanism that tells the ingress LSR which leaves belong to the P2MP LSP. ✅ Applications specified within the IETF MUST spell out this mechanism in enough detail that an ingress LSR from one vendor can work with an application implementation from another vendor. 🤝 Manually configuring security parameters when other parameters are auto-discovered is generally not enough to meet the security and interoperability requirements of IETF specifications. 🙅♀️ Main character energy is interop, bestie 💖
22. Acknowledgements 💌
This document is the product of a whole squad of people 🎀 The contributors are listed in Appendix B.
Huge thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger, and Nischal Sheth for their suggestions and comments. ✨ Thanks also to Dino Farninacci and Benjamin Niven for their comments too. 🌸
23. References 📚
23.1. Normative References 🧾
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 2005.
[RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and
A. Ayyangar, "Encoding of Attributes for Multiprotocol
Label Switching (MPLS) Label Switched Path (LSP)
Establishment Using Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)", RFC 4420, February
2006.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed.,
"Fast Reroute Extensions to RSVP-TE for LSP Tunnels",
RFC 4090, May 2005.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A.
Farrel, "GMPLS Segment Recovery", RFC 4873, April 2007.23.2. Informative References 🌟
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-
to-Multipoint Traffic-Engineered MPLS Label Switched
Paths (LSPs)", RFC 4461, April 2006.
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", Work in Progress, March 2007.
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"BFD for MPLS LSPs", Work in Progress, March 2007.
[LSP-STITCH] Ayyanger, A., Kompella, K., Vasseur, JP., and A.
Farrel, "Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering
(GMPLS TE)", Work in Progress, March 2007.
[TE-NODE-CAP] Vasseur, JP., Ed., Le Roux, JL., Ed., "IGP Routing
Protocol Extensions for Discovery of Traffic
Engineering Node Capabilities", Work in Progress, April
2007.
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress
Control", RFC 4003, February 2005.Appendix A. Example of P2MP LSP Setup 🧚
Here's one example of setting up a P2MP LSP using the procedures from this document. Let's picture it! 🦋
Source 1 (S1)
|
PE1
| |
|L5 |
P3 |
| |
L3 |L1 |L2
R2----PE3--P1 P2---PE2--Receiver 1 (R1)
| L4
PE5----PE4----R3
|
|
R4
Figure 2.PE1 is the ingress LSR. PE2, PE3, and PE4 are egress LSRs. We'll use Figure 2 to walk through it. 🗺️
a) PE1 learns that PE2, PE3, and PE4 want to join a P2MP tree with a P2MP ID of P2MP ID1. We assume PE1 learns about the egress LSRs at different points in time. ⏰
b) PE1 computes the P2P path to reach PE2. 🧭
c) PE1 sets up the S2L sub-LSP to PE2 along <PE1, P2, PE2>. 🎀
d) PE1 computes the P2P path to reach PE3 when it discovers PE3. This path is computed to share the same links where possible with the sub-LSP to PE2, since they belong to the same P2MP session. 🤝
e) PE1 sets up the S2L sub-LSP to PE3 along <PE1, P3, P1, PE3>. 🌈
f) PE1 computes the P2P path to reach PE4 when it discovers PE4. This path is computed to share the same links where possible with the sub-LSPs to PE2 and PE3, since they belong to the same P2MP session. 💜
g) PE1 signals the Path message for the PE4 sub-LSP along <PE1, P3, P1, PE4>. 📨
h) P1 gets a Resv message from PE4 with label L4. It had already received a Resv message from PE3 with label L3, and it had allocated a label L1 for the sub-LSP to PE3. It reuses the same label and sends the Resv messages to P3. Note that it may send only one Resv message with multiple flow descriptors in the flow descriptor list. If that happens and FF style is used, the FF flow descriptor will contain the S2L sub-LSP descriptor list with two entries: one for PE4 and one for PE3. For SE style, the SE filter spec will contain this S2L sub-LSP descriptor list. P1 also creates a label mapping of (L1 -> {L3, L4}). P3 uses the existing label L5 and sends the Resv message to PE1, with label L5. It reuses the label mapping of {L5 -> L1}. 🥳
Appendix B. Contributors 🫂
John Drake
Boeing
EMail: john.E.Drake2@boeing.com
Alan Kullberg
Motorola Computer Group
120 Turnpike Road 1st Floor
Southborough, MA 01772
EMail: alan.kullberg@motorola.com
Lou Berger
LabN Consulting, L.L.C.
EMail: lberger@labn.net
Liming Wei
Redback Networks
350 Holger Way
San Jose, CA 95134
EMail: lwei@redback.com
George Apostolopoulos
Redback Networks
350 Holger Way
San Jose, CA 95134
EMail: georgeap@redback.com
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
EMail: swallow@cisco.com
JP Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
EMail: jpv@cisco.com
Dean Cheng
Cisco Systems Inc.
170 W Tasman Dr.
San Jose, CA 95134
Phone 408 527 0677
EMail: dcheng@cisco.com
Markus Jork
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
Phone: +1 978 964 2142
EMail: mjork@avici.com
Hisashi Kojima
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 6070
EMail: kojima.hisashi@lab.ntt.co.jp
Andrew G. Malis
Tellabs
2730 Orchard Parkway
San Jose, CA 95134
Phone: +1 408 383 7223
EMail: Andy.Malis@tellabs.com
Koji Sugisono
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 2605
EMail: sugisono.koji@lab.ntt.co.jp
Masanori Uga
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 4804
EMail: uga.masanori@lab.ntt.co.jp
Igor Bryskin
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
ibryskin@movaz.com
Adrian Farrel
Old Dog Consulting
Phone: +44 0 1978 860944
EMail: adrian@olddog.co.uk
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
EMail: jeanlouis.leroux@francetelecom.comEditors' Addresses 🖊️
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
EMail: rahul@juniper.net
Seisho Yasukawa
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 4769
EMail: yasukawa.seisho@lab.ntt.co.jp
Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
EMail: Dimitri.Papadimitriou@alcatel-lucent.beFull Copyright Statement 💖
Okay so, the legal bit, but make it cute 🎀 The copyright belongs to The IETF Trust (2007). This document is subject to the rights, licenses, and restrictions in BCP 78. Except where BCP 78 says otherwise, the authors keep all their rights. ✨
This document and the information in it are provided on an "AS IS" basis. The contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust, and the Internet Engineering Task Force all disclaim every warranty, express or implied. That includes, but isn't limited to, any warranty that using the information won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. 💀
Intellectual Property 🦋
The IETF doesn't take a position on whether any Intellectual Property Rights (or other rights) claimed for the technology in this document are valid or in scope. It also doesn't say whether any license for those rights is or isn't available. And it hasn't made any independent effort to find such rights, so don't assume it did 🙈 If you want to know how rights work for RFC documents, check out BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances that licenses will be available, or the results of any attempt to get a general license or permission for implementers or users to use these proprietary rights, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. 🌈
The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. We love a good transparency moment 🫶
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you to the Internet Society for keeping the lights on for the RFC Editor 💜
📦 where this page comes from
- ietf: rfc4875 2007-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms