draft-ietf-mpls-rsvp-te-p2mp-01.txt   draft-ietf-mpls-rsvp-te-p2mp-02.txt 
Network Working Group R. Aggarwal (Juniper) Network Working Group R. Aggarwal (Editor)
Internet Draft D. Papadimitriou (Alcatel) Internet Draft Juniper Networks
Expiration Date: June 2005 S. Yasukawa (NTT) Expiration Date: January 2006
Editors D. Papadimitriou (Editor)
Alcatel
S. Yasukawa (Editor)
NTT
July 2005
Extensions to RSVP-TE for Point to Multipoint TE LSPs Extensions to RSVP-TE for Point to Multipoint TE LSPs
draft-ietf-mpls-rsvp-te-p2mp-01.txt draft-ietf-mpls-rsvp-te-p2mp-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, we certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or IPR claims of which we are aware have been disclosed, and applicable patent or other IPR claims of which he or she is aware
any of which we become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes extensions to Resource Reservation Protocol - This document describes extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for the setup of Traffic Engineered Traffic Engineering (RSVP-TE) for the setup of Traffic Engineered
(TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-
Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
networks. The solution relies on RSVP-TE without requiring a networks. The solution relies on RSVP-TE without requiring a
multicast routing protocol in the Service Provider core. Protocol multicast routing protocol in the Service Provider core. Protocol
elements and procedures for this solution are described. There can be elements and procedures for this solution are described. There can be
various applications for P2MP TE LSPs such as IP multicast. various applications for P2MP TE LSPs such as IP multicast.
Specification of how such applications will use a P2MP TE LSP is Specification of how such applications will use a P2MP TE LSP is
outside the scope of this document. outside the scope of this document.
Conventions used in this document Table of Contents
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS].
Authors' Note 1 Conventions used in this document ..................... 5
2 Terminology ........................................... 5
3 Introduction .......................................... 5
4 Mechanism ............................................. 5
4.1 P2MP Tunnels .......................................... 6
4.2 P2MP LSP ............................................. 6
4.3 Sub-Groups ............................................ 6
4.4 S2L Sub-LSPs .......................................... 7
4.4.1 Representation of a S2L Sub-LSP ....................... 7
4.4.2 S2L Sub-LSPs and Path Messages ........................ 7
4.5 Explicit Routing ...................................... 8
5 Path Message .......................................... 10
5.1 Path Message Format ................................... 10
5.2 Path Message Processing ............................... 11
5.2.1 Multiple Path Messages ................................ 12
5.2.2 Multiple S2L Sub-LSPs in one Path message ............. 13
5.2.3 Transit Fragmentation ................................. 14
5.2.4 Control of Branch Fate Sharing ........................ 15
5.3 Grafting .............................................. 15
6 Resv Message .......................................... 16
6.1 Resv Message Format ................................... 16
6.2 Resv Message Processing ............................... 17
6.2.1 Resv Message Throttling ............................... 18
6.3 Record Routing ........................................ 18
6.3.1 RRO Processing ........................................ 18
6.4 Reservation Style ..................................... 19
7 PathTear Message ...................................... 19
7.1 PathTear Message Format ............................... 19
7.2 Pruning ............................................... 20
7.2.1 Implicit S2L Sub-LSP Teardown ......................... 20
7.2.2 Explicit S2L Sub-LSP Teardown ........................ 20
8 Notify and ResvConf Messages .......................... 21
9 Refresh Reduction ..................................... 21
10 State Management ...................................... 22
10.1 Incremental State Update .............................. 22
10.2 Combining Multiple Path Messages ...................... 23
11 Error Processing ...................................... 24
11.1 PathErr Messages ...................................... 24
11.2 ResvErr Messages ...................................... 24
11.3 Branch Failure Handling ............................... 25
12 Admin Status Change ................................... 26
13 Label Allocation on LANs with Multiple Downstream Nodes ...26
14 P2MP LSP and Sub-LSP Re-optimization .................. 26
Some of the text in the document needs further discussion between 14.1 Make-before-break ..................................... 27
authors and feedback from MPLS WG. This has been pointed out when 14.2 Sub-Group Based Re-optimization ....................... 27
applicable. A change log and reviewed/updated text will be made 15 Fast Reroute .......................................... 27
available online. 15.1 Facility Backup ....................................... 28
15.2 One to One Backup ..................................... 29
16 Support for LSRs that are not P2MP Capable ............ 29
17 Reduction in Control Plane Processing with LSP Hierarchy ..31
18 P2MP LSP Remerging and Cross-Over ..................... 31
19 New and Updated Message Objects ....................... 34
19.1 SESSION Object ........................................ 34
19.1.1 P2MP LSP Tunnel IPv4 SESSION Object ................... 34
19.1.2 P2MP LSP Tunnel IPv6 SESSION Object ................... 35
19.2 SENDER_TEMPLATE object ................................ 35
19.2.1 P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object ........... 35
19.2.2 P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object ........... 36
19.3 S2L SUB-LSP Object .................................... 37
19.3.1 S2L SUB-LSP IPv4 Object ............................... 37
19.3.2 S2L SUB-LSP IPv6 Object ............................... 38
19.4 FILTER_SPEC Object .................................... 38
19.4.1 P2MP LSP_IPv4 FILTER_SPEC Object ...................... 38
19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object ...................... 38
19.5 P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) ........... 38
19.6 P2MP_SECONDARY_RECORD_ROUTE Object (SRRO) ............. 39
20 IANA Considerations ................................... 39
20.1 New Class Numbers ..................................... 39
20.2 New Class Types ....................................... 39
20.3 New Error Codes ....................................... 40
20.4 LSP Attributes Flags .................................. 40
21 Security Considerations ............................... 41
22 Acknowledgements ...................................... 41
23 Appendix .............................................. 41
23.1 Example ............................................... 41
24 References ............................................ 42
24.1 Normative References .................................. 42
24.2 Informative References ................................ 43
25 Author Information .................................... 44
25.1 Editor Information .................................... 44
25.2 Contributor Information ............................... 45
26 Intellectual Property ................................. 47
27 Full Copyright Statement .............................. 48
28 Acknowledgement ....................................... 48
Table of Contents 1. Conventions used in this document
1 Terminology............................................. 4 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
2 Introduction.............................................4 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
3 Mechanisms.............................................. 4 document are to be interpreted as described in RFC-2119 [KEYWORDS].
3.1 P2MP Tunnels............................................ 5
3.2 P2MP LSP Tunnels........................................ 5
3.3 Sub-Groups.............................................. 5
3.4 S2L Sub-LSPs............................................ 6
3.4.1 Representation of a S2L sub-LSP......................... 6
3.4.2 S2L Sub-LSPs and Path Messages.......................... 6
3.5 Explicit Routing........................................ 7
4 Path Message............................................ 9
4.1 Path Message Format..................................... 9
4.2 Path Message Processing................................. 10
4.2.1 Multiple Path Messages.................................. 11
4.2.2 Multiple S2L Sub-LSPs in One Path Message............... 12
4.2.3 Transit Fragmentation................................... 13
4.3 Grafting................................................ 14
4.3.1 Addition of S2L Sub-LSP................................. 14
5 Resv Message............................................ 14
5.1 Resv Message Format..................................... 14
5.2 Resv Message Processing................................. 15
5.2.1 Resv Message Throttling................................. 16
5.3 Record Routing.......................................... 17
5.3.1 RRO Processing.......................................... 17
6 Reservation Style....................................... 17
7 Path Tear Message....................................... 17
7.1 Path Tear Message Format................................ 17
7.2 Pruning................................................. 17
7.2.1 Explicit S2L Sub-LSP Teardown........................... 17
7.2.2 Implicit S2L Sub-LSP Teardown........................... 18
7.2.1 P2MP TE LSP Teardown.................................... 19
8 Notify and ResvConf Messages............................ 20
9 Error Processing........................................ 20
9.1 PathErr Message Format.................................. 20
9.2 Handling of Failures at Branch LSRs..................... 21
10 Refresh Reduction....................................... 22
11 State Management........................................ 22
11.1 Incremental State Update................................ 22
11.2 Combining Multiple Path Messages........................ 23
12 Control of Branch Fate Sharing.......................... 24
13 Admin Status Change..................................... 24
14 Label Allocation on LANs with Multiple Downstream Nodes. 25
15 Make-Before-Break....................................... 25
15.1 P2MP Tree re-optimization............................... 25
15.2 Re-optimization of a subset of S2L sub-LSPs ............ 25
16 Fast Reroute............................................ 26
16.1 Facility Backpup........................................ 26
16.2 One to One Backup....................................... 26
17 Support for LSRs that are not P2MP Capable.............. 27
18 Reduction in Control Plane Processing with LSP Hierarchy 29
19 P2MP LSP Tunnel Remerging and Cross-Over................ 29
20 New and Updated Message Objects......................... 31
20.1 P2MP SESSION Object..................................... 31
20.2 P2MP LSP Tunnel SENDER_TEMPLATE Object.................. 32
20.2.1 P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object............. 33
20.2.2 P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object............. 33
20.3 S2L SUB-LSP Object...................................... 34
20.3.1 S2L IPv4 SUB-LSP Object................................. 34
20.3.2 S2L IPv6 SUB-LSP Object................................. 35
20.4 FILTER_SPEC Object...................................... 35
20.5 SUB EXPLICIT ROUTE Object (SERO)........................ 36
20.6 SUB RECORD ROUTE Object (SRRO).......................... 36
21 IANA Considerations..................................... 37
22 Security Considerations................................. 37
23 Acknowledgements........................................ 37
24 Example P2MP LSP Establishment ......................... 37
25 References.............................................. 39
26 Authors................................................. 40
27 Intellectual Property................................... 43
28 Full Copyright Statement................................ 43
29 Acknowledgement......................................... 44
1. Terminology 2. Terminology
This document uses terminologies defined in [RFC3031], [RFC2205], This document uses terminologies defined in [RFC3031], [RFC2205],
[RFC3209], [RFC3473] and [P2MP-REQ]. In particular, this document [RFC3209], [RFC3473] and [P2MP-REQ].
uses the notation defined in [P2MP-REQ] for describing the components
on a P2MP LSP between root, branches and leaves.
2. Introduction 3. Introduction
[RFC3209] defines a mechanism for setting up point-to-point (P2P) [RFC3209] defines a mechanism for setting up P2P TE LSPs in MPLS net-
Traffic Engineered (TE) LSPs in MPLS networks. [RFC3473] defines works. [RFC3473] defines extensions to [RFC3209] for setting up P2P
extensions to [RFC3209] for setting up P2P TE LSPs in GMPLS networks. TE LSPs in GMPLS networks. However these specifications do not pro-
However these specifications do not provide a mechanism for building vide a mechanism for building P2MP TE LSPs.
point-to-multipoint P2MP TE LSPs.
This document defines extensions to RSVP-TE [RFC3209] and [RFC3473] This document defines extensions to RSVP-TE protocol [RFC3209,
protocol to support P2MP TE LSPs satisfying the set of requirements RFC3473] to support P2MP TE LSPs satisfying the set of requirements
described in [P2MP-REQ]. described in [P2MP-REQ].
This document relies on the semantics of RSVP that RSVP-TE inherits This document relies on the semantics of RSVP that RSVP-TE inherits
for building P2MP LSP Tunnels. A P2MP LSP Tunnel is comprised of for building P2MP LSPs. A P2MP LSP is comprised of multiple S2L sub-
multiple S2L sub-LSPs. These S2L sub-LSPs are set up between the LSPs. These S2L sub-LSPs are set up between the ingress and egress
ingress and egress LSRs and are appropriately combined by the branch LSRs and are appropriately combined by the branch LSRs using RSVP
LSRs using RSVP semantics to result in a P2MP TE LSP. One Path semantics to result in a P2MP TE LSP. One Path message may signal one
message may signal one or multiple S2L sub-LSPs. Hence the S2L sub- or multiple S2L sub-LSPs. Hence the S2L sub-LSPs belonging to a P2MP
LSPs belonging to a P2MP LSP Tunnel can be signaled using one Path LSP can be signaled using one Path message or split across multiple
message or split across multiple Path messages. Path messages.
Path computation and P2MP application specific aspects are outside of Path computation and P2MP application specific aspects are outside of
the scope of this document. the scope of this document.
3. Mechanism 4. Mechanism
This document describes a solution that optimizes data replication by This document describes a solution that optimizes data replication by
allowing non-ingress nodes in the network to be replication/branch allowing non-ingress nodes in the network to be replication/branch
nodes. A branch node is a LSR that is capable of replicating the nodes. A branch node is a LSR that is capable of replicating the
incoming data on two or more outgoing interfaces. The solution uses incoming data on two or more outgoing interfaces. The solution uses
RSVP-TE in the core of the network for setting up a P2MP TE LSP. RSVP-TE in the core of the network for setting up a P2MP TE LSP.
The P2MP TE LSP is set up by associating multiple S2L TE sub-LSPs and The P2MP TE LSP is set up by associating multiple S2L TE sub-LSPs and
relying on data replication at branch nodes. This is described relying on data replication at branch nodes. This is described fur-
further in the following sub-sections by describing P2MP tunnels and ther in the following sub-sections by describing P2MP Tunnels and how
how they relate to S2L sub-LSPs. they relate to S2L sub-LSPs.
3.1. P2MP Tunnels 4.1. P2MP Tunnels
The specific aspect related to P2MP TE LSP is the action required at The specific aspect related to P2MP TE LSP is the action required at
a branch node, where data replication occurs. Incoming labeled data a branch node, where data replication occurs. For instance, in the
is appropriately replicated to several outgoing interfaces which may MPLS case, incoming labeled data is appropriately replicated to sev-
have different labels. eral outgoing interfaces which may have different labels.
A P2MP TE tunnel comprises of one or more P2MP LSPs referred to as A P2MP TE Tunnel comprises of one or more P2MP LSPs. A P2MP TE Tunnel
P2MP LSP tunnels. A P2MP TE Tunnel is identified by a P2MP SESSION is identified by a P2MP SESSION object. This object contains the
object. This object contains an identifier of the P2MP session identifier of the P2MP Session which includes the P2MP ID, a tunnel
defined as a P2MP ID, a tunnel ID and an extended tunnel ID. ID and an extended tunnel ID.
The fields of a P2MP SESSION object are identical to those of the The fields of a P2MP SESSION object are identical to those of the
SESSION object defined in [RFC3209] except that the Tunnel Endpoint SESSION object defined in [RFC3209] except that the Tunnel Endpoint
Address field is replaced by the P2MP Identifier (P2MP ID) field. Address field is replaced by the P2MP Identifier (P2MP ID) field.
The P2MP ID provides an identifier for the set of destinations of the The P2MP ID provides an identifier for the set of destinations of the
P2MP TE Tunnel. The P2MP SESSION object is defined in section 20.1. P2MP TE Tunnel.
3.2. P2MP LSP Tunnel 4.2. P2MP LSP
A P2MP LSP Tunnel is identified by the combination of the P2MP ID, A P2MP LSP is identified by the combination of the P2MP ID, Tunnel
Tunnel ID, and Extended Tunnel ID that are part of the P2MP SESSION ID, and Extended Tunnel ID that are part of the P2MP SESSION object,
object, and the tunnel sender address and LSP ID fields of the P2MP and the tunnel sender address and LSP ID fields of the P2MP
SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is
defined in section 20.2. defined in section 20.2.
3.3. Sub-Groups 4.3. Sub-Groups
As with all other RSVP controlled LSP Tunnels, P2MP LSP Tunnel state As with all other RSVP controlled LSPs, P2MP LSP state is managed
is managed using RSVP messages. While use of RSVP messages is the using RSVP messages. While use of RSVP messages is the same, P2MP LSP
same, P2MP LSP Tunnel state differs from P2P LSP state in a number of state differs from P2P LSP state in a number of ways. The two most
ways. A notable difference is that a P2MP LSP Tunnel is comprised of notable differences are that a P2MP LSP comprises multiple S2L Sub-
multiple S2L Sub-LSPs As a result of this, it may not be possible to LSPs and that, as a result of this, it may not be possible to repre-
signal a P2MP LSP Tunnel in a single RSVP-TE Path/Resv message. It is sent full state in a single IP datagram and even more likely that it
also possible that such a signaling message can not fit into a single can't fit into a single IP packet. It must also be possible to effi-
IP packet. It must also be possible to efficiently add and remove ciently add and remove endpoints to and from P2MP TE LSPs. An addi-
endpoints to and from P2MP TE LSPs. An additional issue is that P2MP tional issue is that P2MP LSP must also handle the state "remerge"
LSP Tunnels must also handle the state "remerge" problem [P2MP-REQ]. problem, see [P2MP-REQ].
These differences in P2MP state are addressed through the addition of These differences in P2MP state are addressed through the addition of
a sub-group identifier (Sub-Group ID) and sub-group originator (Sub- a sub-group identifier (Sub-Group ID) and sub-group originator (Sub-
Group Originator ID) to the SENDER_TEMPLATE and FILTER_SPEC objects. Group Originator ID) to the SENDER_TEMPLATE and FILTER_SPEC objects.
Taken together the Sub-Group ID and Sub-Group Originator ID are Taken together the Sub-Group ID and Sub-Group Originator ID are
referred to as the Sub-Group fields. referred to as the Sub-Group fields.
The Sub-Group fields, together with rest of the SENDER_TEMPLATE and The Sub-Group fields, together with rest of the SENDER_TEMPLATE and
SESSION objects, are used to represent a portion of a P2MP LSP SESSION objects, are used to represent a portion of a P2MP LSP's
Tunnel's state. The portion of P2MP LSP Tunnel state identified by state. This portion of a P2MP LSP's state refers only to signaling
specific subgroup field values is referred to as a signaling sub- state and not data plane replication or branching. For example, it is
tree. It is important to note that the term "signaling sub-tree" possible for a node to "branch" signaling state for a P2MP LSP, but
refers only to signaling state and not data plane replication or to not branch the data associated with the P2MP LSP. Typical applica-
branching. For example, it is possible for a node to "split" tions for generation and use of multiple subgroups are adding an
signaling state for a P2MP LSP Tunnel, but to not branch the data egress and semantic fragmentation to ensure that a Path message
associated with the P2MP LSP Tunnel. Typical applications for remains within a single IP packet.
generation and use of multiple subgroups are adding an egress and
semantic fragmentation to ensure that a Path message remains within a
single IP packet.
3.4. S2L Sub-LSPs
A P2MP LSP Tunnel is constituted of one or more S2L sub-LSPs. 4.4. S2L Sub-LSPs
3.4.1. Representation of a S2L Sub-LSP A P2MP LSP is constituted of one or more S2L sub-LSPs.
A S2L sub-LSP exists within the context of a P2MP LSP Tunnel. Thus it 4.4.1. Representation of a S2L Sub-LSP
is identified by the P2MP ID, Tunnel ID, and Extended Tunnel ID that
are part of the P2MP SESSION, the tunnel sender address and LSP ID
fields of the P2MP SENDER_TEMPLATE object, and the S2L sub-LSP
destination address that is part of the S2L_SUB_LSP object. The
S2L_SUB_LSP object is defined in section 20.3.
Additionally, a sub-LSP ID contained in the S2L_SUB_LSP object may be A S2L sub-LSP exists within the context of a P2MP LSP. Thus it is
used depending on further discussions about the make-before-break identified by the P2MP ID, Tunnel ID, and Extended Tunnel ID that are
procedures described in section 14. part of the P2MP SESSION, the tunnel sender address and LSP ID fields
of the P2MP SENDER_TEMPLATE object, and the S2L sub-LSP destination
address that is part of the S2L_SUB_LSP object. The S2L_SUB_LSP
object is defined in section 20.3.
An EXPLICIT_ROUTE Object (ERO) or SUB_EXPLICIT_ROUTE Object (SERO) is An EXPLICIT_ROUTE Object (ERO) or P2MP SECONDARY_EXPLICIT_ROUTE
used to optionally specify the explicit route of a S2L sub-LSP. Each Object (SERO) is used to optionally specify the explicit route of a
ERO or a SERO that is signaled corresponds to a particular S2L sub-LSP. Each ERO or a SERO that is signaled corresponds to a
S2L_SUB_LSP object. Details of explicit route encoding are specified particular S2L_SUB_LSP object. Details of explicit route encoding are
in section 3.5. specified in section 4.5. The SECONDARY_EXPLICIT_ROUTE Object is
defined in [RECOVERY], a new P2MP SECONDARY_EXPLICIT_ROUTE Object C-
type is defined in Section 20.5 and a matching P2MP SEC-
ONDARY_RECORD_ROUTE Object C-type is defined in Section 20.6.
3.4.2. S2L Sub-LSPs and Path Messages 4.4.2. S2L Sub-LSPs and Path Messages
The mechanism in this document allows a P2MP LSP Tunnel to be The mechanism in this document allows a P2MP LSP to be signaled using
signaled using one or more Path messages. Each Path message may one or more Path messages. Each Path message may signal one or more
signal one or more S2L sub-LSPs. Support for multiple Path messages S2L sub-LSPs. Support for multiple Path messages is desirable as one
is desirable as one Path message may not be large enough to fit all Path message may not be large enough to fit all the S2L sub-LSPs; and
the S2L sub-LSPs; and they also allow separate manipulation of sub- they also allow separate manipulation of sub-trees of the P2MP LSP.
trees of the P2MP LSP Tunnel. The reason for allowing a single Path The reason for allowing a single Path message, to signal multiple S2L
message, to signal multiple S2L sub-LSPs, is to optimize the number sub-LSPs, is to optimize the number of control messages needed to
of control messages needed to setup a P2MP LSP Tunnel. setup a P2MP LSP.
3.5. Explicit Routing 4.5. Explicit Routing
When a Path message signals a single S2L sub-LSP (that is, the Path When a Path message signals a single S2L sub-LSP (that is, the Path
message is only targeting a single leaf in the P2MP tree), the message is only targeting a single leaf in the P2MP tree), the
EXPLICIT_ROUTE object may encode the path to the egress LSR. The Path EXPLICIT_ROUTE object encodes the path from the ingress LSR to the
message also includes the S2L_SUB_LSP object for the S2L sub-LSP egress LSR. The Path message also includes the S2L_SUB_LSP object for
being signaled. The < [<EXPLICIT_ROUTE>], <S2L_SUB_LSP> > tuple the S2L sub-LSP being signaled. The < [<EXPLICIT_ROUTE>],
represents the S2L sub-LSP. The absence of the ERO should be <S2L_SUB_LSP> > tuple represents the S2L sub-LSP and is referred to
interpreted as requiring hop-by-hop routing for the sub-LSP based on as the sub-LSP descriptor. The absence of the ERO should be inter-
the S2L sub-LSP destination address field of the S2L_SUB_LSP object. preted as requiring hop-by-hop routing for the sub-LSP based on the
S2L sub-LSP destination address field of the S2L_SUB_LSP object.
When a Path message signals multiple S2L sub-LSPs the path of the When a Path message signals multiple S2L sub-LSPs the path of the
first S2L sub-LSP, to the egress LSR, is encoded in the ERO. The first S2L sub-LSP, from the ingress LSR to the egress LSR, is encoded
first S2L sub-LSP is the one that corresponds to the first in the ERO. The first S2L sub-LSP is the one that corresponds to the
S2L_SUB_LSP object in the Path message. The S2L sub-LSPs first S2L_SUB_LSP object in the Path message. The S2L sub-LSPs corre-
corresponding to the S2L_SUB_LSP objects that follow are termed as sponding to the S2L_SUB_LSP objects that follow are termed as subse-
subsequent S2L sub-LSPs. One approach to encode the explicit route quent S2L sub-LSPs. One approach to encode the explicit route of a
of a subsequent S2L sub-LSP is to include the path from the ingress subsequent S2L sub-LSP is to include all the hops from the ingress to
to the egress of the S2L sub-LSP. However this implies potential the egress of the S2L sub-LSP. However this implies potential repeti-
repetition of hops that could be learned from the ERO or explicit tion of hops that can be learned from the ERO or explicit routes of
routes of other S2L sub-LSPs. Explicit route compression using SEROs other S2L sub-LSPs. Explicit route compression using SEROs attempts
attempts to minimize such repetition and is described below. to minimize such repetition.
The path of each subsequent S2L sub-LSP is encoded in a The path of each subsequent S2L sub-LSP is encoded in a P2MP SEC-
SUB_EXPLICIT_ROUTE object (SERO). The format of the SERO is the same ONDARY_EXPLICIT_ROUTE object (SERO). The format of the SERO is the
as an ERO (as defined in [RFC3209]). Each subsequent S2L sub-LSP is same as an ERO (as defined in [RFC3209]). Each subsequent S2L sub-LSP
represented by tuples of the form [<SUB_EXPLICIT_ROUTE>] is represented by tuples of the form < [<P2MP SEC-
<S2L_SUB_LSP>. There is a one to one correspondence between a ONDARY_EXPLICIT_ROUTE>] <S2L_SUB_LSP> >. There is a one to one corre-
S2L_SUB_LSP object and a SERO. A SERO for a particular S2L sub-LSP spondence between a S2L_SUB_LSP object and a SERO. A SERO for a par-
includes only the path from a certain branch LSR to the egress LSR if ticular S2L sub-LSP includes only the path from a certain branch LSR
the path to that branch LSR can be derived from the ERO or other to the egress LSR if the path to that branch LSR can be derived from
SEROs. The absence of a SERO should be interpreted as requiring hop- the ERO or other SEROs. The absence of a SERO should be interpreted
by-hop routing for that S2L sub-LSP. Note that the destination as requiring hop-by-hop routing for that S2L sub-LSP. Note that the
address is carried in the S2L sub-LSP object. The encoding of the destination address is carried in the S2L sub-LSP object. The encod-
SERO and S2L sub-LSP object are described in detail in section 20. ing of the SERO and S2L sub-LSP object are described in detail in
section 20.
Explicit route compression is illustrated using the following figure. Explicit route compression is illustrated using the following figure.
A A
| |
| |
B B
| |
| |
C----D----E C----D----E
skipping to change at page 8, line 14 skipping to change at page 9, line 16
F G H-------I F G H-------I
| |\ | | |\ |
| | \ | | | \ |
J K L M J K L M
| | | | | | | |
| | | | | | | |
N O P Q--R N O P Q--R
Figure 1. Explicit Route Compression Figure 1. Explicit Route Compression
Figure 1. shows a P2MP LSP Tunnel with LSR A as the ingress LSR and Figure 1. shows a P2MP LSP with LSR A as the ingress LSR and six
six egress LSRs: (F, N, O, P, Q and R). When all the six S2L sub-LSPs egress LSRs: (F, N, O, P, Q and R). When all the six S2L sub-LSPs are
are signaled in one Path message let us assume that the S2L sub-LSP signaled in one Path message let us assume that the S2L sub-LSP to
to LSR F is the first S2L sub-LSP and the rest are subsequent S2L LSR F is the first S2L sub-LSP and the rest are subsequent S2L sub-
sub-LSPs. Following is one way for the ingress LSR A to encode the LSPs. Following is one way for the ingress LSR A to encode the S2L
S2L sub-LSP explicit routes using compression: sub-LSP explicit routes using compression:
S2L sub-LSP-F: ERO = {B, E, D, C, F}, S2L_SUB_LSP Object-F 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-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-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-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-Q: SERO = {H, I, M, Q}, S2L_SUB_LSP Object-Q,
S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP Object-R, S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP Object-R,
After LSR E processes the incoming Path message from LSR B it sends a After LSR E processes the incoming Path message from LSR B it sends a
Path message to LSR D with the S2L sub-LSP explicit routes encoded as Path message to LSR D with the S2L sub-LSP explicit routes encoded as
skipping to change at page 8, line 48 skipping to change at page 10, line 4
S2L sub-LSP-O: ERO = {H, K, O}, S2L_SUB_LSP Object-O 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-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-Q: SERO = {H, I, M, Q}, S2L_SUB_LSP Object-Q,
S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP Object-R, S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP Object-R,
After LSR H processes the incoming Path message from E it sends a After LSR H processes the incoming Path message from E it sends a
Path message to LSR K, LSR L and LSR I. The encoding for the Path Path message to LSR K, LSR L and LSR I. The encoding for the Path
message to LSR K is as follows: message to LSR K is as follows:
S2L sub-LSP-O: ERO = {K, O}, S2L_SUB_LSP Object-O S2L sub-LSP-O: ERO = {K, O}, S2L_SUB_LSP Object-O
The encoding of the Path message sent by LSR H to LSR L is as fol-
The encoding of the Path message sent by LSR H to LSR L is as lows:
follows:
S2L sub-LSP-P: ERO = {L, P}, S2L_SUB_LSP Object-P, S2L sub-LSP-P: ERO = {L, P}, S2L_SUB_LSP Object-P,
Following is one way for LSR H to encode the S2L sub-LSP explicit Following is one way for LSR H to encode the S2L sub-LSP explicit
routes in the Path message sent to LSR I: routes in the Path message sent to LSR I:
S2L sub-LSP-Q: ERO = {I, M, Q}, S2L_SUB_LSP Object-Q, S2L sub-LSP-Q: ERO = {I, M, Q}, S2L_SUB_LSP Object-Q,
S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP Object-R, S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP Object-R,
The explicit route encodings in the Path messages sent by LSRs D and The explicit route encodings in the Path messages sent by LSRs D and
Q are left as an exercise to the reader. Q are left as an exercise to the reader.
This compression mechanism reduces the Path message size. It also This compression mechanism reduces the Path message size. It also
reduces the processing that can result if explicit routes are encoded reduces extra processing that can result if explicit routes are
from ingress to egress for each S2L sub-LSP. No assumptions are encoded from ingress to egress for each S2L sub-LSP. No assumptions
placed on the ordering of the subsequent S2L sub-LSPs and hence on are placed on the ordering of the subsequent S2L sub-LSPs and hence
the ordering of the SEROs in the Path message. All LSRs need to on the ordering of the SEROs in the Path message. All LSRs need to
process the ERO corresponding to the first S2L sub-LSP. A LSR needs process the ERO corresponding to the first S2L sub-LSP. A LSR needs
to process a SERO for a subsequent S2L sub-LSP only if the first hop to process a S2L sub-LSP descriptor for a subsequent S2L sub-LSP only
in the corresponding SERO is a local address of that LSR. The branch if the first hop in the corresponding SERO is a local address of that
LSR that is the first hop of a SERO propagates the corresponding S2L LSR. The branch LSR that is the first hop of a SERO propagates the
sub-LSP downstream. corresponding S2L sub-LSP downstream.
4. Path Message 5. Path Message
4.1. Path Message Format 5.1. Path Message Format
This section describes modifications made to the Path message format This section describes modifications made to the Path message format
as specified in [RFC3209] and [RFC3473]. The Path message is enhanced as specified in [RFC3209] and [RFC3473]. The Path message is enhanced
to signal one or more S2L sub-LSPs. This is done by including the S2L to signal one or more S2L sub-LSPs. This is done by including the S2L
sub-LSP descriptor list in the Path message as shown below. sub-LSP descriptor list in the Path message as shown below.
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <EXPLICIT_ROUTE> ] [ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST> <LABEL_REQUEST>
[ <PROTECTION> ] [ <PROTECTION> ]
[ <LABEL_SET> ... ] [ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ] [ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ] [ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ] [ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<sender descriptor> <sender descriptor>
[S2L sub-LSP descriptor list] [<S2L sub-LSP descriptor list>]
Following is the format of the S2L sub-LSP descriptor list. Following is 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 descriptor list> ] [ <S2L sub-LSP descriptor list> ]
<S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <SUB_EXPLICIT_ROUTE> ] <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <P2MP SEC-
ONDARY_EXPLICIT_ROUTE> ]
Each LSR MUST use the common objects in the Path message and the S2L Each LSR MUST use the common objects in the Path message and the S2L
sub-LSP descriptors to process each S2L sub-LSP represented by the sub-LSP descriptors to process each S2L sub-LSP represented by the
S2L sub-LSP object and the SUB-/EXPLICIT_ROUTE object combination. S2L sub-LSP object and the SUB-/EXPLICIT_ROUTE object combination.
The first S2L_SUB_LSP object's explicit route is specified by the The first S2L_SUB_LSP object's explicit route is specified by the
ERO. Explicit routes of subsequent S2L sub-LSPs are specified by the ERO. Explicit routes of subsequent S2L sub-LSPs are specified by the
corresponding SERO. A SERO corresponds to the following S2L_SUB_LSP corresponding SERO. A SERO corresponds to the following S2L_SUB_LSP
object. object.
The RRO in the sender descriptor contains the hops traversed by the The RRO in the sender descriptor contains the hops traversed by the
Path message and applies to all the S2L sub-LSPs signaled in the Path Path message and applies to all the S2L sub-LSPs signaled in the Path
message. message.
Path message processing is described in the next section. Path message processing is described in the next section.
4.2. Path Message Processing 5.2. Path Message Processing
The ingress-LSR initiates the set up of a S2L sub-LSP to each egress- The ingress-LSR initiates the set up of a S2L sub-LSP to each egress-
LSR that is the destination of the P2MP LSP Tunnel. Each S2L sub-LSP LSR that is the destination of the P2MP LSP. Each S2L sub-LSP is
is associated with the same P2MP LSP Tunnel using common P2MP SESSION associated with the same P2MP LSP using common P2MP SESSION object
object and <Source Address, LSP-ID> fields in the SENDER_TEMPLATE and <Source Address, LSP-ID> fields in the P2MP SENDER_TEMPLATE
object. Hence it can be combined with other S2L sub-LSPs to form a object. Hence it can be combined with other S2L sub-LSPs to form a
P2MP LSP Tunnel. Another S2L sub-LSP belonging to the same instance P2MP LSP. Another S2L sub-LSP belonging to the same instance of this
of this S2L sub-LSP (i.e. the same P2MP LSP Tunnel) can share S2L sub-LSP (i.e. the same P2MP LSP) shares resources with this S2L
resources with this LSP. The session corresponding to the P2MP TE sub-LSP. The session corresponding to the P2MP TE tunnel is deter-
tunnel is determined based on the P2MP SESSION object. Each S2L sub- mined based on the P2MP SESSION object. Each S2L sub-LSP is identi-
LSP is identified using the S2L_SUB_LSP object. Explicit routing for fied using the S2L_SUB_LSP object. Explicit routing for the S2L sub-
the S2L sub-LSPs is achieved using the ERO and SEROs. LSPs is achieved using the ERO and SEROs.
As mentioned earlier, it is possible to signal S2L sub-LSPs for a As mentioned earlier, it is possible to signal S2L sub-LSPs for a
given P2MP LSP Tunnel in one or more Path messages. And a given Path given P2MP LSP in one or more Path messages. And a given Path message
message can contain one or more S2L sub-LSPs. can contain one or more S2L sub-LSPs. A LSR that supports RSVP-TE
signaled P2MP LSPs MUST be able to receive and process multiple Path
messages for the same P2MP LSP and multiple S2L sub-LSPs in one Path
message. This implies that a LSR MUST be able to receive and process
all objects listed in section 20.
4.2.1. Multiple Path messages 5.2.1. Multiple Path Messages
As described in section 3, {<EXPLICIT_ROUTE>, <S2L SUB-LSP>} or As described in section 3, either the <EXPLICIT_ROUTE> <S2L SUB-LSP>
{<SUB_EXPLICIT_ROUTE>, <S2L_SUB_LSP>} tuple is used to specify a S2L or the <P2MP SECONDARY_EXPLICIT_ROUTE> <S2L_SUB_LSP> tuple is used to
sub-LSP. Multiple Path messages can be used to signal a P2MP LSP specify a S2L sub-LSP. Multiple Path messages can be used to signal a
Tunnel. Each Path message can signal one or more S2L sub-LSPs. If a P2MP LSP. Each Path message can signal one or more S2L sub-LSPs. If a
Path message contains only one S2L sub-LSP, each LSR along the S2L Path message contains only one S2L sub-LSP, each LSR along the S2L
sub-LSP follows [RFC3209] procedures for processing the Path message sub-LSP follows [RFC3209] procedures for processing the Path message
besides the S2L SUB-LSP object processing described in this document. besides the S2L SUB-LSP object processing described in this document.
Processing of Path messages containing more than one S2L sub-LSP is Processing of Path messages containing more than one S2L sub-LSP is
described in Section 4.3. described in Section 5.2.2.
An ingress LSR may use multiple Path messages for signaling a P2MP An ingress LSR may use multiple Path messages for signaling a P2MP
LSP. This may be because a single Path message may not be large LSP. This may be because a single Path message may not be large
enough to signal the P2MP LSP Tunnel. Or it may be while adding enough to signal the P2MP LSP. Or it may be while adding leaves to
leaves to the P2MP LSP Tunnel the new leaves are signaled in a new the P2MP LSP the new leaves are signaled in a new Path message. Or an
Path message. Or an ingress LSR MAY choose to break the P2MP tree ingress LSR MAY choose to break the P2MP tree into separate manage-
into separate manageable S2L sub-trees. These trees share the same able P2MP trees. These trees share the same root and may share the
root and may share the trunk and certain branches. The scope of this trunk and certain branches. The scope of this management decomposi-
management decomposition of P2MP trees is bounded by a single tree tion of P2MP trees is bounded by a single tree (the P2MP Tree) and
and multiple S2L sub-trees with a single leaf each. As defined in multiple trees with a single leaf each (S2L sub-LSPs). Per [P2MP-
[P2MP-REQ], a P2MP LSP Tunnel must have consistent attributes across REQ], a P2MP LSP MUST have consistent attributes across all portions
all portions of a tree. This implies that each Path message that is of a tree. This implies that each Path message that is used to signal
used to signal a P2MP LSP Tunnel is signaled using the same signaling a P2MP LSP is signaled using the same signaling attributes with the
attributes with the exception of the S2L sub-LSP information. exception of the S2L sub-LSP information.
The resulting S2L sub-LSPs from the different Path messages belonging The resulting sub-LSPs from the different Path messages belonging to
to the same P2MP LSP Tunnel SHOULD share labels and resources where the same P2MP LSP SHOULD share labels and resources where they share
they share hops to prevent multiple copies of the data being sent. hops to prevent multiple copies of the data being sent.
In certain cases a transit LSR may need to generate multiple Path In certain cases a transit LSR may need to generate multiple Path
messages to signal state corresponding to a single received Path messages to signal state corresponding to a single received Path mes-
message. For instance ERO expansion may result in an overflow of the sage. For instance ERO expansion may result in an overflow of the
resultant Path message. There are two cases occurring in such resultant Path message. In this case the message can be decomposed
circumstances, either the message can be decomposed into multiple into multiple Path messages such that each of the messages carry a
Path messages such that each of the message carries a subset of the subset of the X2L sub-tree carried by the incoming message.
incoming S2L sub-LSPs carried by the incoming message, or the message
can not be decomposed such that each of the outgoing Path message
fits its maximum size value.
Multiple Path messages generated by a LSR that signal state for the Multiple Path messages generated by a LSR that signal state for the
same P2MP LSP are signaled with the same SESSION object and have the same P2MP LSP are signaled with the same SESSION object and have the
same <Source address, LSP-ID> in the SENDER_TEMPLATE object. In order same <Source address, LSP-ID> in the SENDER_TEMPLATE object. In order
to disambiguate these Path messages a <Sub-Group Originator ID, sub- to disambiguate these Path messages a <Sub-Group Originator ID, sub-
Group ID> tuple is introduced (also referred to as the Sub-Group Group ID> tuple is introduced (also referred to as the Sub-Group
field). Multiple Path messages generated by a LSR to signal state field) and encoded in the SENDER_TEMPLATE object. Multiple Path mes-
for the same P2MP LSP have the same Sub-Group Originator ID and have sages generated by a LSR to signal state for the same P2MP LSP have
a different sub-Group ID. The Sub-Group Originator ID SHOULD be set the same Sub-Group Originator ID and have a different sub-Group ID.
to the TE Router ID of the LSR that originates the Path message. This The Sub-Group Originator ID SHOULD be set to the TE Router ID of the
is either the ingress LSR or a LSR which re-originates the Path LSR that originates the Path message. This is either the ingress LSR
message with its own Sub-Group Originator ID. Cases when a transit or a LSR which re-originates the Path message with its own Sub-Group
LSR may change the Sub-Group Originator ID of an incoming Path Originator ID. Cases when a transit LSR may change the Sub-Group
message are described below. The <Sub-Group Originator ID, sub-Group Originator ID of an incoming Path message are described below. The
ID> tuple is network-wide unique. The sub-Group ID space is specific <Sub-Group Originator ID, sub-Group ID> tuple is globally unique. The
to the Sub-Group Originator ID. Therefore the combination <Sub-Group sub-Group ID space is specific to the Sub-Group Originator ID. There-
Originator ID, sub-Group ID> is network-wide unique. Also, a router fore the combination <Sub-Group Originator ID, sub-Group ID> is net-
that changes the Sub-Group Originator ID MUST use the same Sub-Group work-wide unique. Also, a router that changes the Sub-Group origina-
Originator ID on all Path messages for the same P2MP LSP Tunnel and tor ID of an incoming Path message MUST use the same value of the
SHOULD not vary the value during the life of the P2MP LSP Tunnel. Sub-Group Originator ID for all outgoing Path messages, for a partic-
ular P2MP LSP, and SHOULD not vary it during the life of the P2MP
Note: This version of the document assumes that these additional LSP.
fields, i.e. <Sub-Group Originator ID, sub-Group ID>, are part of the
SENDER_TEMPLATE object.
4.2.2. Multiple S2L Sub-LSPs in one Path message 5.2.2. Multiple S2L Sub-LSPs in one Path message
The S2L sub-LSP descriptor list allows the signaling of one or more The S2L sub-LSP descriptor list allows the signaling of one or more
S2L sub-LSPs in one Path message. It is possible to signal multiple S2L sub-LSPs in one Path message. It is possible to signal multiple
S2L sub-LSP objects and ERO/SERO combinations in a single Path S2L sub-LSP object and ERO/SERO combinations in a single Path mes-
message. Note that these objects are the ones that differentiate a sage. Note that these two objects are the ones that differentiate a
S2L sub-LSP. Each LSR can use the common objects in the Path message S2L sub-LSP.
and the S2L sub-LSP descriptors to process each S2L sub-LSP.
All LSRs need to process the ERO corresponding to the first S2L sub- All LSRs MUST process the ERO corresponding to the first S2L sub-LSP
LSP when the ERO is present. If one or more SEROs are present an ERO when the ERO is present. If one or more SEROs are present an ERO MUST
MUST be present. The signaling information for the first S2L sub-LSP be present. The first S2L sub-LSP MUST be propagated in a Path mes-
is propagated in a Path message by each LSR along the explicit route sage by each LSR along the explicit route specified by the ERO. A LSR
specified by the ERO. A LSR needs to process a S2L sub-LSP descriptor MUST process a S2L sub-LSP descriptor for a subsequent S2L sub-LSP
for a subsequent S2L sub-LSP only if the first hop in the only if the first hop in the corresponding SERO is a local address of
corresponding SERO is a local address of that LSR. If this is not the that LSR. If this is not the case the S2L sub-LSP descriptor MUST be
case the S2L sub-LSP descriptor is included in the Path message sent included in the Path message sent to LSR that is the next hop to
to LSR that is the next hop to reach the first hop in the SERO. This reach the first hop in the SERO. This next hop is determined by using
next hop is determined by using the ERO or other SEROs that encode the ERO or other SEROs that encode the path to the SERO's first hop.
the path to the SERO's first hop. If this is the case and the LSR is If this is the case and the LSR is also the egress, the S2L sub-LSP
also the egress the S2L sub-LSP descriptor is not propagated descriptor MUST NOT be propagated downstream. If this is the case and
downstream. If this is the case and the LSR is not the egress the S2L the LSR is not the egress the S2L sub-LSP descriptor MUST be included
sub-LSP descriptor is included in a Path message sent to the next-hop in a Path message sent to the next-hop determined from the SERO.
determined from the SERO. Hence a branch LSR only propagates the Hence a branch LSR MUST only propagate the relevant S2L sub-LSP
relevant S2L sub-LSP descriptors on each downstream link. A S2L sub- descriptors on each downstream link. A S2L sub-LSP descriptor list
LSP descriptor that is propagated on a downstream link only contains that is propagated on a downstream link MUST only contain those S2L
those S2L sub-LSPs that are routed using that link. This processing sub-LSPs that are routed using that link. This processing MAY result
may result in a subsequent S2L sub-LSP in an incoming Path message to in a subsequent S2L sub-LSP in an incoming Path message to become the
become the first S2L sub-LSP in an outgoing Path message. first S2L sub-LSP in an outgoing Path message.
Note that if one or more SEROs contains loose hops, expansion of such Note that if one or more SEROs contain loose hops, expansion of such
loose hops may result in overflowing the Path message size. Section loose hops MAY result in overflowing the Path message size. Section
4.2.3 describes how signaling of the set of S2L sub-LSPs can be split 5.2.3 describes how signaling of the set of S2L sub-LSPs can be split
in more than one Path message. in more than one Path message.
The Record Route Object (RRO) contains the hops traversed by the Path The Record Route Object (RRO) contains the hops traversed by the Path
message and applies to all the S2L sub-LSPs signaled in the Path message and applies to all the S2L sub-LSPs signaled in the path mes-
message. A transit LSR appends its address in an incoming RRO and sage. A transit LSR MUST append its address in an incoming RRO and
propagates it downstream. A branch LSR forms a new RRO for each of propagate it downstream. A branch LSR MUST form a new RRO for each of
the outgoing Path messages. Each such updated RRO is formed using the the outgoing Path messages. Each such updated RRO MUST be formed
rules in [RFC3209]. using the rules in [RFC3209].
If a LSR is unable to support a S2L sub-LSP setup, a PathErr message If a LSR is unable to support a S2L sub-LSP in a Path message, a
MUST be sent for the impacted S2L sub-LSP, and normal processing of PathErr message MUST be sent for the impacted S2L sub-LSP, and normal
the rest of the P2MP LSP Tunnel SHOULD continue. The default behavior processing of the rest of the P2MP LSP SHOULD continue. The default
is that the remainder of the LSP is not impacted (that is, all other behavior is that the remainder of the LSP is not impacted (that is,
branches are allowed to set up) and the failed branches are reported all other branches are allowed to set up) and the failed branches are
in PathErr messages in which the Path_State_Reomved flag MUST NOT be reported in PathErr messages in which the Path_State_Removed flag
set. However, the ingress LSR may set a LSP Integrity flag (see MUST NOT be set. However, the ingress LSR may set a LSP Integrity
section 21.3) to request that if there is a setup failure on any flag to request that if there is a setup failure on any branch the
branch the entire LSP should fail to set up. entire LSP should fail to set up. This is described further in sec-
tion 12.
4.2.3. Transit Fragmentation 5.2.3. Transit Fragmentation
In certain cases a transit LSR may need to generate multiple Path In certain cases a transit LSR may need to generate multiple Path
messages to signal state corresponding to a single received Path messages to signal state corresponding to a single received Path mes-
message. For instance ERO expansion may result in an overflow of the sage. For instance ERO expansion may result in an overflow of the
resultant Path message. It is desirable not to rely on IP resultant Path message. It is desirable not to rely on IP fragmenta-
fragmentation in this case. In order to achieve this, the multiple tion in this case. In order to achieve this, the multiple Path mes-
Path messages generated by the transit LSR, MUST be signaled with the sages generated by the transit LSR, are signaled with the Sub-Group
Sub-Group Originator ID set to the TE Router ID of the transit LSR Originator ID set to the TE Router ID of the transit LSR and a dis-
and a distinct sub-Group ID. Thus each distinct Path message that is tinct sub-Group ID. Thus each distinct Path message that is generated
generated by the transit LSR for the P2MP LSP Tunnel carries a by the transit LSR for the P2MP LSP carries a distinct <Sub-Group
distinct <Sub-Group Originator ID, Sub-Group ID> tuple. Originator ID, Sub-Group ID> tuple.
When multiple Path messages are used by an ingress or transit node, When multiple Path messages are used by an ingress or transit node,
each Path message SHOULD be identical with the exception of the S2L each Path message SHOULD be identical with the exception of the S2L
sub-LSP related information (e.g., SERO), message and hop information sub-LSP related information (e.g., SERO), message and hop information
(e.g., INTEGRITY, MESSAGE_ID and RSVP_HOP), and the SENDER_TEMPLATE (e.g., INTEGRITY, MESSAGE_ID and RSVP_HOP), and the sub-group fields
objects. Except when performing a make-before-break operation, the of the SENDER_TEMPLATE objects. Except when performing a make-
tunnel sender address and LSP ID fields MUST be the same in each before-break operation, the tunnel sender address and LSP ID fields
message, and for transit nodes, the same as the values in the Path MUST be the same in each message, and for transit nodes, the same as
message. the values in the received Path message.
As described above one case in which the Sub-Group Originator ID of a As described above one case in which the Sub-Group Originator ID of a
received Path message is changed is that of transit fragmentation. received Path message is changed is that of transit fragmentation.
The Sub-Group Originator ID of a received Path message may also be The Sub-Group Originator ID of a received Path message may also be
changed in the outgoing Path message and set to that of the LSR changed in the outgoing Path message and set to that of the LSR orig-
originating the Path message based on a local policy. For instance a inating the Path message based on a local policy. For instance a LSR
LSR may decide to always change the Sub-Group Originator ID while may decide to always change the Sub-Group Originator ID while per-
performing ERO expansion. The Sub-Group ID MUST not be changed if the forming ERO expansion. The Sub-Group ID MUST not be changed if the
Sub-Group Originator ID is not being changed. Sub-Group Originator ID is not being changed.
4.3. Grafting 5.2.4. Control of Branch Fate Sharing
The operation of adding egress LSR(s) to an existing P2MP LSP Tunnel An ingress LSR can control the behavior of an LSP if there is a fail-
is termed grafting. This operation allows egress nodes to join a P2MP ure during LSP setup or after an LSP has been established. The
LSP Tunnel at different points in time. default behavior is that only the branches downstream of the failure
are not established, but the ingress may request 'LSP integrity' such
that any failure anywhere within the LSP tree causes the entire P2MP
LSP to fail.
4.3.1. Addition of S2L Sub-LSPs The ingress LSP may request 'LSP integrity' by setting bit [TBA] of
the Attributes Flags TLV. The bit is set if LSP integrity is
required.
There are two methods to add S2L sub-LSPs to a P2MP LSP Tunnel. The It is RECOMMENDED to use the LSP_ATTRIBUTES Object for this flag and
first is to add new S2L sub-LSPs to the P2MP LSP Tunnel by adding not the LSP_REQUIRED_ATTRIBUTES Object.
them to an existing Path message and refreshing the entire Path
message. Path message processing described in section 4 results in
adding these S2L sub-LSPs to the P2MP LSP Tunnel. Note that as a
result of adding one or more S2L sub-LSPs to a Path message the ERO
compression encoding may have to be recomputed.
The second is to use incremental updates described in section 11.1. A branch LSR that supports the Attributes Flags TLV and recognizes
The egress LSRs can be added/removed by signaling only the impacted this bit MUST support LSP integrity or reject the LSP setup with a
S2L sub-LSPs in a new Path message. Hence other S2L sub-LSPs do not PathErr carrying the error "Routing Error"/"Unsupported LSP
have to be re-signaled. Integrity"
5. Resv Message 5.3. Grafting
5.1. Resv Message Format The operation of adding egress LSR(s) to an existing P2MP LSP is
termed as grafting. This operation allows egress nodes to join a P2MP
LSP at different points in time.
There are two methods to add S2L sub-LSPs to a P2MP LSP. The first
is to add new S2L sub-LSPs to the P2MP LSP by adding them to an
existing Path message and refreshing the entire Path message. Path
message processing described in section 4 results in adding these S2L
sub-LSPs to the P2MP LSP. Note that as a result of adding one or more
S2L sub-LSPs to a Path message the ERO compression encoding may have
to be recomputed.
The second is to use incremental updates described in section 10.1.
The egress LSRs can be added by signaling only the impacted S2L sub-
LSPs in a new Path message. Hence other S2L sub-LSPs do not have to
be re-signaled.
6. Resv Message
6.1. Resv Message Format
The Resv message follows the [RFC3209] and [RFC3473] format: The Resv message follows the [RFC3209] and [RFC3473] format:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ] [ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ] [ <NOTIFY_REQUEST> ]
skipping to change at page 15, line 4 skipping to change at page 16, line 28
[ <ADMIN_STATUS> ] [ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list> <flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor> | <SE flow descriptor>
<FF flow descriptor list> ::= <FF flow descriptor> <FF flow descriptor list> ::= <FF flow descriptor>
| <FF flow descriptor list> | <FF flow descriptor list>
<FF flow descriptor> <FF flow descriptor>
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list> <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec> <SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec> | <SE filter spec list> <SE filter spec>
The FF flow descriptor and SE filter spec are modified as follows to The FF flow descriptor and SE filter spec are modified as follows to
identify the S2L sub-LSPs that they correspond to: identify the S2L sub-LSPs that they correspond to:
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL> <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ] [ <RECORD_ROUTE> ] [ <S2L sub-LSP descriptor
[ <S2L sub-LSP descriptor list> ] list> ]
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ] <SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <S2L sub-LSP descriptor list> ] [ <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 SEC-
ONDARY_EXPLICIT_ROUTE> ]
FILTER_SPEC is defined in section 20.4. FILTER_SPEC is defined in section 20.4.
The S2L sub-LSP descriptor has the same format as in section 4.1 with The S2L sub-LSP descriptor has the same format as in section 4.1 with
the difference that a SUB_RECORD_ROUTE object is used in place of a the difference that a P2MP_SECONDARY_RECORD_ROUTE object is used in
SUB_EXPLICIT_ROUTE object. place of a P2MP SECONDARY_EXPLICIT_ROUTE object. The P2MP_SEC-
ONDARY_RECORD_ROUTE objects follow the same compression mechanism as
<S2L sub-LSP filte descriptor list> ::= <S2L sub-LSP filter the P2MP SECONDARY_EXPLICIT_ROUTE objects. Note that that a Resv mes-
descriptor> sage can signal multiple S2L sub-LSPs that may belong to the same
[ <S2L sub-LSP filter descriptor FILTER_SPEC object or different FILTER_SPEC objects. The same label
list> ] SHOULD be allocated if the <Source Address, LSP-ID> fields of the
FILTER_SPEC object are the same.
<S2L sub-LSP filte descriptor> ::= <S2L_SUB_LSP> [ <SUB_RECORD_ROUTE>
]
The SUB_RECORD_ROUTE objects follow the same compression mechanism as
the SUB_EXPLICIT_ROUTE objects. Note that a Resv message can signal
multiple S2L sub-LSPs that may belong to the same FILTER_SPEC object
or different FILTER_SPEC objects. The same label is allocated if the
FILTER_SPEC object is the same.
However different upstream labels are allocated if the <Source However different upstream labels are allocated if the <Source
Address, LSP-ID> of the FILTER_SPEC object is different as that Address, LSP-ID> of the FILTER_SPEC object is different as that
implies different P2MP LSP Tunnels. implies different P2MP LSP.
5.2. Resv Message Processing 6.2. Resv Message Processing
The egress LSR follows normal RSVP procedures while originating a The egress LSR MUST follow normal RSVP procedures while originating a
Resv message. The Resv message carries the label allocated by the Resv message. The Resv message carries the label allocated by the
egress LSR. egress LSR.
A subsequent node allocates its own label and passes it upstream in A subsequent node MUST allocates its own label and pass it in the
the Resv message. The node may combine multiple flow descriptors, Resv message upstream. The node MAY combine multiple flow descrip-
from different Resv messages received from downstream, in one Resv tors, from different Resv messages received from downstream, in one
message sent upstream. A Resv message is not sent upstream by a Resv message sent upstream. A Resv message MUST NOT be sent upstream
transit LSR until at least one Resv message has been received from a until at least one Resv message has been received from a downstream
downstream neighbor except when the integrity bit is set in the neighbor. When the integrity bit is set in the LSP_ATTRIBUTE object,
LSP_ATTRIBUTE object. no Resv message MUST be sent upstream until all Resv messages have
been received from the downstream neighbors.
Each FF flow descriptor or SE filter spec sent upstream in a Resv Each FF flow descriptor or SE filter spec sent upstream in a Resv
message includes a S2L sub-LSP descriptor list. Each such FF flow message includes a S2L sub-LSP descriptor list. Each such FF flow
descriptor or SE filter spec for the same P2MP LSP Tunnel (whether on descriptor or SE filter spec for the same P2MP LSP (whether on one or
one or multiple Resv messages) is allocated the same label. multiple Resv messages) MUST be allocated the same label.
This label is associated by that node with all the labels received This label is associated by that node with all the labels received
from downstream Resv messages for that P2MP LSP Tunnel. Note that a from downstream Resv messages for that P2MP LSP. Note that a transit
transit node may become a replication point in the future when a node may become a replication point in the future when a branch is
branch is attached to it. Hence this results in the setup of a P2MP attached to it. Hence this results in the setup of a P2MP LSP from
LSP Tunnel from the ingress-LSR to the egress LSRs. the ingress-LSR to the egress LSRs.
The ingress LSR may need to understand when all desired egresses have The ingress LSR may need to understand when all desired egresses have
been reached. This is achieved using <S2L_SUB_LSP> objects. been reached. This is achieved using <S2L_SUB_LSP> objects.
Each branch node can potentially send one Resv message upstream for Each branch node can potentially send one Resv message upstream for
each of the downstream receivers. This may result in overflowing the each of the downstream receivers. This MAY result in overflowing the
Resv message, particularly when considering that the number of Resv message, particularly when considering that the number of mes-
messages increases the closer the branch node is to the ingress. sages increases the closer the branch node is to the ingress.
Transit nodes MUST replace the Sub-Group ID fields received in the Transit nodes MUST replace the Sub-Group ID fields received in the
FILTER_SPEC objects with the value that was received in the Sub-Group FILTER_SPEC objects with the value that was received in the Sub-Group
ID field of the Path message from the upstream neighbor, when the ID field of the Path message from the upstream neighbor, when the
node set the Sub-Group Originator field in the associated Path node set the Sub-Group Originator field in the associated Path mes-
message. ResvErr message generation is unmodified. Nodes sage. ResvErr messages generation is unmodified. Nodes propagating
propagating a received ResvErr message MUST use the Sub-Group field a received ResvErr message MUST use the Sub-Group field values car-
values carried in the corresponding Resv message. ried in the corresponding Resv message.
The solution for this issue is for further discussion.
5.2.1. Resv Message Throttling 6.2.1. Resv Message Throttling
A branch node needs to send the Resv message being sent upstream A branch node may have to send the Resv message being sent upstream
whenever there is a change in a Resv message for a S2L sub-LSP whenever there is a change in a Resv message for a S2L sub-LSP
received from downstream. This can result in excessive Resv messages received from downstream. This can result in excessive Resv messages
sent upstream, particularly when the S2L sub-LSPs are established for sent upstream, particularly when the S2L sub-LSPs are established for
the first time. In order to mitigate this situation, branch nodes the first time. In order to mitigate this situation, branch nodes
MAY limit their transmission of Resv messages. Specifically, in the can limit their transmission of Resv messages. Specifically, in the
case where the only change being sent in a Resv message is in one or case where the only change being sent in a Resv message is in one or
more SRRO objects, the branch node SHOULD transmit the Resv message more SRRO objects, the branch node SHOULD transmit the Resv message
only after a delay time has passed since the transmission of the only after a delay time has passed since the transmission of the pre-
previous Resv message for the same session. This delayed Resv message vious Resv message for the same session. This delayed Resv message
SHOULD include SRROs for all branches. Specific mechanisms for Resv SHOULD include SRROs for all branches. Specific mechanisms for Resv
message throttling are implementation dependent and are outside the message throttling are implementation dependent and are outside the
scope of this document. scope of this document.
5.3. Record Routing 6.3. Record Routing
5.3.1. RRO Processing 6.3.1. RRO Processing
A Resv message contains a recorded route per S2L sub-LSP that is A Resv message contains a record route per S2L sub-LSP that is being
being signaled by the Resv message if the sender node requests route signaled by the Resv message if the sender node requests route
recording by including a RRO in the Path message. The same rule is recording by including a RRO in the Path message. The same rule is
used during signaling of P2MP LSP Tunnels. Thus insertion of the RRO used during signaling of P2MP LSP i.e. insertion of the RRO in the
in the Path message used to signal one or more S2L sub-LSPs triggers Path message used to signal one or more S2L sub-LSP triggers the
the inclusion of an RRO for each sub-LSP signaled in that Path inclusion of an RRO for each sub-LSP.
message or any derivative Path message.
The record route of the first S2L sub-LSP is encoded in the RRO. The record route of the first S2L sub-LSP is encoded in the RRO.
Additional RROs for the subsequent S2L sub-LSPs are referred to as Additional RROs for the subsequent S2L sub-LSPs are referred to as
SUB_RECORD_ROUTE objects (SRROs). Their format is specified in P2MP_SECONDARY_RECORD_ROUTE objects (SRROs). Their format is speci-
section 20.6. The ingress node then receives the RRO and possibly fied in section 20.5. The ingress node then receives the RRO and
the SRRO corresponding to each subsequent S2L sub-LSP. Each possibly the SRRO corresponding to each subsequent S2L sub-LSP. Each
S2L_SUB_LSP object is followed by the RRO/SRRO. The ingress node can S2L_SUB_LSP object is followed by the RRO/SRRO. The ingress node can
then determine the recorded route corresponding to a particular S2L then determine the record route corresponding to a particular S2L
sub-LSP. The RRO and SRROs can be used to construct the end-to-end sub-LSP. The RRO and SRROs can be used to construct the end to end
Path for each S2L sub-LSP. Path for each S2L sub-LSP.
6. Reservation Style 6.4. Reservation Style
TBD Considerations about the reservation style in a Resv message apply as
described in [RFC3209]. The reservation style in the Resv messages
can either be FF or SE. All P2MP LSP that belong to the same P2MP
Tunnel MUST be signaled with the same reservation style. Irrespective
of whether the reservation 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. The S2L sub-LSPs that belong
to different P2MP LSP MUST NOT share labels. If the reservation style
is FF than S2L Sub-LSPs that belong to different P2MP LSP MUST NOT
share resources. If the reservation style is SE than S2L sub-LSPs
that belong to different P2MP LSP and the same P2MP Tunnel SHOULD
share resources where they share hops, but MUST not share labels.
7. PathTear Message 7. PathTear Message
7.1. PathTear message Format 7.1. PathTear Message Format
The format of the PathTear message is as follows: The format of the PathTear message is as follows:
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ] <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
[ [ <MESSAGE_ID_ACK> | [ [ <MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK> ... ] <MESSAGE_ID_NACK> ... ]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
[ <sender descriptor> ] [ <sender descriptor> ]
[ <S2L sub-LSP descriptor list> ] [ <S2L sub-LSP descriptor list> ]
<sender descriptor> ::= (see earlier definition) <sender descriptor> ::= (see earlier definition)
Note: it is assumed that the S2L sub-LSP descriptor will not include Note: it is assumed that the S2L sub-LSP descriptor will not include
the SUB_EXPLICIT_ROUTE object associated with each S2L_SUB_LSP being the P2MP SECONDARY_EXPLICIT_ROUTE object associated with each
deleted S2L_SUB_LSP being deleted
7.2. Pruning 7.2. Pruning
The operation of removing egress LSR(s) from an existing P2MP LSP The operation of removing egress LSR(s) from an existing P2MP LSP is
Tunnel is termed pruning. This operation allows egress nodes to termed as pruning. This operation allows egress nodes to be removed
leave a P2MP LSP Tunnel at different points in time. This section from a P2MP LSP at different points in time. This section describes
describes various mechanisms to perform pruning. Further discussion the mechanisms to perform pruning.
and feedback is needed to finesse these mechanisms.
7.2.1. Explicit S2L Sub-LSP Teardown 7.2.1. Implicit S2L Sub-LSP Teardown
The S2L sub-LSP(s) being removed from the P2MP LSP Tunnel are Implicit teardown uses standard RSVP message processing. Per standard
signaled in a PathTear message. The PathTear message includes the S2L RSVP processing, a S2L sub-LSP may be removed from a P2MP TE LSP by
sub-LSP descriptor list which is included before the sender sending a modified message for the Path or Resv message that previ-
descriptor. Note that the PathTear message contains only the S2L sub- ously advertised the S2L sub-LSP. This message MUST list all S2L sub-
LSP(s) being removed and rest of the P2MP LSP Tunnel does not have to LSPs that are not being removed. When using this approach, a node
be re-signaled. This results in removal of the state corresponding to processing a message that removes a S2L sub-LSP from a P2MP TE LSP
these S2L sub-LSPs. State for rest of the S2L sub-LSPs is not MUST ensure that the S2L sub-LSP is not included in any other Path
modified. state associated with session before interrupting the data path to
that egress. All other message processing remains unchanged.
In the first mechanism in order to delete one or more S2L Sub-LSPs, a When implicit teardown is used to delete one or more S2L sub-LSPs, by
PathTear message is sent with the list of S2L sub-LSPs being deleted. modifying a Path message, a transit LSR may have to generate a
This is a form of explicit tear down. A single PathTear message can PathTear message downstream to delete one or more of these S2L sub-
only contain S2L sub-LSPs that were signaled by the ingress using the LSPs. This can happen if as a result of the implicit deletion of S2L
same <Sub-Group Originator ID, Sub-Group ID> tuple. The PathTear sub-LSP(s) there are no remaining S2L sub-LSPs to send in the corre-
message is signaled with the SESSION and SENDER_TEMPLATE objects sponding Path message downstream.
corresponding to the P2MP LSP Tunnel and the <Sub-Group Originator
ID, Sub-Group ID> tuple corresponding to the S2L sub-LSPs that are
being deleted. A transit LSR that propagates the PathTear message
downstream MUST ensure that it sets the <Sub-Group Originator ID,
Sub-Group ID> tuple in the PathTear message to the values used to
generate the last Path message that corresponds to the S2L sub-LSPs
signaled in the PathTear message that it generates. The transit LSR
may need to generate multiple PathTear messages for an incoming
PathTear message if it had performed transit fragmentation for the
corresponding incoming Path message.
The Path messages from which the S2L sub-LSPs were deleted need to be 7.2.2. Explicit S2L Sub-LSP Teardown
refreshed with the remaining S2L sub-LSPs. Note that as a result of
deleting one or more S2L sub-LSPs from a Path message the ERO
compression encoding may have to be recomputed.
When the last S2L sub-LSP is to be removed from a Path state, i.e., Explicit S2L Sub-LSP teardown relies on generating a PathTear message
there are no remaining S2L sub-LSPs to send in a Path message, a for the corresponding Path message. The PathTear message is signaled
PathTear message SHOULD be sent carrying the Sub-Group ID of the Path with the SESSION and SENDER_TEMPLATE objects corresponding to the
message that no longer has any S2L sub-LSPs. P2MP LSP and the <Sub-Group Originator ID, Sub-Group ID> tuple corre-
sponding to the 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.
The second mechanism is an explicit teardown mechanism that defines A transit LSR that propagates the PathTear message downstream MUST
new syntax and semantics for a PathTear message. This new mechanism ensure that it sets the <Sub-Group Originator ID, Sub-Group ID> tuple
minimizes signaling required to remove a subset of S2L sub-LSPs set in the PathTear message to the values used to generate the previous
signaled in a Path message, and thereby reduces associated Path message that corresponds to the S2L sub-LSPs being deleted by it
processing. When using this mechanism each identified S2L sub-LSP is in the PathTear message. The transit LSR may need to generate multi-
removed from the P2MP LSP Tunnel state, even if the S2L sub-LSP is ple PathTear messages for an incoming PathTear message if it had per-
advertised in multiple Path message. formed transit fragmentation for the corresponding incoming Path mes-
sage.
When using this approach, a PathTear message is generated. The When a P2MP LSP is removed by the ingress, a PathTear message MUST be
PathTear message MUST identify each S2L sub-LSP to be removed, via a generated for each Path message used to signal the P2MP LSP.
S2L_SUB_LSP object per S2L Sub-LSP, and include a SENDER_TEMPLATE
object corresponding to the Path state being modified. The Sub-Group
ID valued contained in the SENDER_TEMPLATE object message MUST be set
to zero (0). Subsequent Path messages associated with the P2MP LSP
Tunnel MUST NOT contain the removed S2L sub-LSPs, unless that S2L
sub-LSP is being re-added to the P2MP LSP.
To support the second mechanism, the receiver of PathTear message 8. Notify and ResvConf Messages
that is associated with a P2MP LSP Tunnel MUST check the value of a
received Sub-Group ID fields. When there is no SENDER_TEMPLATE
object present or the value of the Sub-Group ID fields is non-zero,
then PathTear processing as defined in the above explicit tear down
mechanism must be followed. When the Sub-Group ID field is zero (0),
then the processing node MUST remove the identified egresses from all
control plane state associated with the P2MP LSP Tunnel and adjust
the data path appropriately.
7.2.2. Implicit S2L Sub-LSP Teardown This section is currently under discussion between the authors and
will be updated in the next revision.
The third mechanism to delete S2L sub-LSPs is implicit teardown which Notify Request and Notify messages are described in [RFC3473]. If a
uses standard RSVP message processing. Per standard RSVP processing, transit router sets the sub-group originator ID in the SENDER_TEM-
a S2L sub-LSP may be removed from a P2MP TE LSP by sending a modified PLATE object of a Path message to its own address and the Path mes-
message for the Path or Resv message that previously advertised the sage carries a Notify Request object then the router MUST set the
S2L sub-LSP. This message MUST list all S2L sub-LSPs that are not notify node address in the Notify Request object to its own address.
being removed. When using this approach, a node processing a message If this router receives a corresponding Notify message from down-
that removes a S2L sub-LSP from a P2MP TE LSP MUST ensure that the stream than it MUST generate a Notify message upstream towards the
S2L sub-LSP is not included in any other Path state associated with Notify node address that the router had received in the incoming Path
session before interrupting the data path to that egress. All other message. The receiver of a Notify message MUST identify the sender
message processing remains unchanged. state referenced in the message based on the SESSION and SENDER_TEM-
PLATE objects.
7.2.3. P2MP TE LSP Teardown ResvConf messages are described in [RFC2205]. An egress LSR may
include a RESV_CONFIRM object that contains the egress LSR's address.
If a transit LSR is merging Resv messages received from more than
egress LSR and one or more of these Resv messages contain a RESV_CON-
FIRM object than the transit LSR MUST set its own address in the
RESV_CONFIRM object in the Resv message that it generates. Also if
the transit LSR changes the sub-group originator ID in the generated
Resv message and it includes a RESV_CONFIRM object in the Resv mes-
sage, it MUST set its own address in the RESV_CONFIRM object. Upon
receiving a ResvConf message from upstream the transit LSR MUST gen-
erate a ResvConf message towards each of the downstream LSRs that had
included RESV_CONFIRM objects in the corresponding Resv messages. As
with Notify messages, the receiver of a ResvConf message MUST iden-
tify the state referenced in the message based on the SESSION and
FILTER_SPEC objects.
This operation is accomplished by listing all the S2L sub-LSPs in a 9. Refresh Reduction
PathTear message.
A PathTear message must be generated for each Path message used to The refresh reduction procedures described in [RFC2961] are equally
signal the P2MP LSP Tunnel. applicable to P2MP LSP described in this document. Refresh reduction
applies to individual messages and the state they install/maintain,
and that continues to be the case for P2MP LSP.
8. Notify and ResvConf Messages 10. State Management
Notify messages, see [RFC3473], may contain either SENDER_TEMPLATE or State signaled by a P2MP Path message is managed by a local implemen-
FILTER_SPEC objects, but are sent in a targeted fashion. This means tation using the <P2MP ID, Tunnel ID, Extended Tunnel ID> as part of
that the Sub-Group fields cannot be updated in transit and is the SESSION object and <Tunnel Sender Address, LSP ID, Sub-Group
unlikely to provide any value to the Notify message recipient. Originator ID, Sub-Group ID> as part of the SENDER_TEMPLATE object.
Therefore, the receiver of a Notify message MUST identify the sender
state referenced in the message based on the Source address and LSP
ID contained in the received SENDER_TEMPLATE or FILTER_SPEC objects
rather than, as is normally done, based on the whole objects.
ResvConf messages may contain FILTER_SPEC objects and may also be Additional information signaled in the Path message is part of the
sent in a targeted fashion. As with Notify messages, the receiver of state created by a local implementation. This mandatorily includes
a ResvConf message MUST identify the state referenced in the message PHOP and SENDER_TSPEC object.
based on the address and LSP ID contained in the received FILTER_SPEC
object rather than, as is normally done, based on the whole objects.
9. Error Processing 10.1. Incremental State Update
Note that a LSR on receiving a PathErr/ResvErr message for a RSVP as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and
particular S2L sub-LSP changes the state only for that S2L sub-LSP. GMPLS [RFC3473] uses the same basic approach to state communication
Hence other S2L sub-LSPs are not impacted. In case the ingress node and synchronization, namely full state is sent in each state adver-
requests the maintenance of the 'LSP Integrity', any error reported tisement message. Per [RFC2205] Path and Resv messages are idempo-
tent. Also, [RFC2961] categorizes RSVP messages into two types: trig-
ger and refresh messages and improves RSVP message handling and scal-
ing of state refreshes but does not modify the full state advertise-
ment nature of Path and Resv messages. The full state advertisement
nature of Path and Resv messages has many benefits, but also has some
drawbacks. One notable drawback is when an incremental modification
is being made to a previously advertised state. In this case, there
is the message overhead of sending the full state and the cost of
processing it. It is desirable to overcome this drawback and
add/delete S2L sub-LSPs to a P2MP LSP by incrementally updating the
existing state.
It is possible to use the procedures described in this document to
allow S2L sub-LSPs to be incrementally added or deleted from the P2MP
LSP by allowing a Path or a PathTear message to incrementally change
the existing P2MP LSP Path state.
As described in section 4.2, multiple Path messages can be used to
signal a P2MP LSP. The Path messages are distinguished by different
<Sub-Group Originator ID, sub-Group ID> tuples in the SENDER_TEMPLATE
object. In order to perform incremental S2L sub-LSP state addition a
separate Path message with a new sub-Group ID is used to add the new
S2L sub-LSPs, by the ingress LSR. The Sub-Group Originator ID MUST be
set to the TE Router ID [RFC3477] of the node that sets the Sub-Group
ID.
This maintains the idempotent nature of RSVP Path messages; avoids
keeping track of individual S2L sub-LSP state expiration and provides
the ability to perform incremental P2MP LSP state updates.
10.2. Combining Multiple Path Messages
There is a tradeoff between the number of Path messages used by the
ingress to maintain the P2MP LSP and the processing imposed by full
state messages when adding S2L sub-LSPs to an existing Path message.
It is possible to combine S2L sub-LSPs previously advertised in dif-
ferent Path messages in a single Path message in order to reduce the
number of Path messages needed to maintain the P2MP LSP. This can
also be done by a transit node that performed fragmentation and at a
later point is able to combine multiple Path messages that it gener-
ated into a single Path message. This may happen when one or more S2L
sub-LSPs are pruned from the existing Path states.
The new Path message is signaled by the node that is combining multi-
ple Path messages with all the S2L sub-LSPs that are being combined
in a single Path message. This Path message MAY contain a new Sub-
Group ID field value. When a new Path and Resv message that is sig-
naled for an existing S2L sub-LSP is received by a transit LSR, state
including the new instance of the S2L sub-LSP is created.
The S2L sub-LSP SHOULD continue to be advertised in both the old and
new Path messages until a Resv message listing the S2L sub-LSP and
corresponding to the new Path message is received by the combining
node. Hence until this point state for the S2L sub-LSP SHOULD be
maintained as part of the Path state for both the old and the new
Path message [Section 3.1.3, 2205]. At that point the S2L sub-LSP
SHOULD be deleted from the old Path state using the procedures of
section 7.
A Path message with a 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), the SESSION object and <Sender Tunnel Address, LSP-ID,
Sub-Group Originator ID> being the same. Or it may signal a strictly
non-overlapping new set of S2L sub-LSPs with a strictly higher sub-
Group_ID value.
1) If sub-Group_ID(i) = sub-Group_ID(n), then either a full refresh
is indicated by the Path message or a S2L Sub-LSP is added to/deleted
from the group signaled by sub-Group_ID(n)
2) If sub-Group_ID(i) != sub-Group_ID(n), then the Path message is
signaling a set of S2L sub-LSPs that belong partially or entirely to
an already existing Sub-Group_ID(i) or a strictly non-overlapping set
of S2L sub-LSPs.
11. Error Processing
PathErr and ResvErr messages are processed as per RSVP-TE procedures.
Note that a LSR on receiving a PathErr/ResvErr message for a particu-
lar S2L sub-LSP changes the state only for that S2L sub-LSP. Hence
other S2L sub-LSPs are not impacted. In case the ingress node
requests the maintenance of the 'LSP integrity', any error reported
within the P2MP TE LSP must be reported at (least at) any other within the P2MP TE LSP must be reported at (least at) any other
branching nodes belonging to this LSP. Therefore, reception of an branching nodes belonging to this LSP. Therefore, reception of an
error message for a particular S2L sub-LSP MAY change the state of error message for a particular S2L sub-LSP MAY change the state of
any other S2L sub-LSP of the same P2MP TE LSP. any other S2L sub-LSP of the same P2MP TE LSP.
9.1. PathErr Message Format 11.1. PathErr Messages
A PathErr message will include one or more S2L_SUB_LSP objects. The The PathErr message will include one or more S2L_SUB_LSP objects. The
resulting modified format of a PathErr Message is: resulting modified format for a PathErr Message is:
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ] <PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | [ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ] <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC> <SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ] [ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<sender descriptor> <sender descriptor>
[ <S2L sub-LSP descriptor list> ] [ <S2L sub-LSP descriptor list> ]
PathErr messages generation is unmodified, but nodes that set the PathErr messages generation is unmodified, but nodes that set the
Sub-Group Originator field and propagate a received PathErr message Sub-Group Originator field and propagate a received PathErr message
upstream MUST replace the Sub-Group fields received in the PathErr upstream MUST replace the Sub-Group fields received in the PathErr
message with the value that was received in the Sub-Group fields of message with the value that was received in the Sub-Group fields of
the Path message from the upstream neighbor. Note the receiver of a the Path message from the upstream neighbor. Note the receiver of a
PathErr message is able to identify the errored outgoing Path PathErr message is able to identify the errored outgoing Path mes-
message, and outgoing interface, based on the Sub-Group fields sage, and outgoing interface, based on the Sub-Group fields received
received in the error message. in the PathErr message.
9.2. Handling of Failures at Branch LSRs 11.2. ResvErr Messages
The ResvErr message will include one or more S2L_SUB_LSP objects. The
resulting modified format for a ResvErr Message 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 messages generation is unmodified, but nodes that set the
Sub-Group Originator field and propagate a received ResvErr message
downstream MUST replace the Sub-Group fields received in the ResvErr
message with the value that was set in the Sub-Group fields of the
Path message sent to the downstream neighbor. Note the receiver of a
ResvErr message is able to identify the errored outgoing Path mes-
sage, and outgoing interface, based on the Sub-Group fields received
in the ResvErr message.
11.3. Branch Failure Handling
During setup and during normal operation, PathErr messages may be During setup and during normal operation, PathErr messages may be
received at a branch node. In all cases, a received PathErr message received at a branch node. In all cases, a received PathErr message
is first processed per standard processing rules. That is, the is first processed per standard processing rules. That is: the
PathErr message is sent hop-by-hop to the ingress/branch LSR for that PathErr message is sent hop-by-hop to the ingress/branch LSR for that
Path message. Intermediate nodes until this ingress/branch LSR MAY Path message. Intermediate nodes until this ingress/branch LSR MAY
inspect this message but take no action upon it. The behavior of a inspect this message but take no action upon it. The behavior of a
branch LSR that generates a PathErr message is under the control of branch LSR that generates a PathErr message is under the control of
the ingress LSR. the ingress LSR.
The default behavior is that the PathErr does not have the The default behavior is that the PathErr does not have the
Path_State_Removed flag set. However, if the ingress LSR has set the Path_State_Removed flag set. However, if the ingress LSR has set the
'LSP Integrity' flag on the Path message (see LSP_ATTRIBUTE object in 'LSP integrity' flag on the Path message (see LSP_ATTRIBUTE object in
section 21.3) and if the Path_State_Removed flag is supported, the section 20) and if the Path_State_Removed flag is supported, the LSR
LSR generating a PathErr to report the failure of a branch of the generating a PathErr to report the failure of a branch of the P2MP
P2MP LSP Tunnel SHOULD set the Path_State_Removed flag. LSP SHOULD set the Path_State_Removed flag.
A branch LSR that receives a PathErr message with the
Path_State_Removed flag set MUST act according to the wishes of the
ingress LSR. The default behavior is that the branch LSR clears the
Path_State_Removed flag on the PathErr and sends it further upstream.
It does not tear 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 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 A branch LSR that receives a PathErr message with the
Path_State_Removed flag clear MUST act according to the wishes of the Path_State_Removed flag clear MUST act according to the wishes of the
ingress LSR. The default behavior is that the branch LSR forwards the ingress LSR. The default behavior is that the branch LSR forwards the
PathErr upstream and takes no further action. However, if the LSP PathErr upstream and takes no further action. However, if the LSP
integrity flag is set on the Path message, the branch LSR MUST send integrity flag is set on the Path message, the branch LSR MUST send
PathTear on all downstream branches and send the PathErr upstream PathTear on all downstream branches and send the PathErr upstream
with the Path_State_Removed flag set (per [RFC3473]). with the Path_State_Removed flag set (per [RFC3473]).
In all cases, the PathErr message forwarded by a branch LSR MUST In all cases, the PathErr message forwarded by a branch LSR MUST con-
contain the S2L sub-LSP identification and explicit routes of all tain the S2L sub-LSP identification and explicit routes of all
branches that are errored (reported by received PathErr messages) and branches that are reported by received PathErr messages and all
all branches that are explicitly torn by the branch LSR. branches that are explicitly torn by the branch LSR.
10. Refresh Reduction
The refresh reduction procedures described in [RFC2961] are equally
applicable to P2MP LSP Tunnels described in this document. Refresh
reduction applies to individual messages and the state they
install/maintain, and that continues to be the case for P2MP LSP
Tunnels.
11. State Management
State signaled by a P2MP Path message is managed by an implementation
using the <P2MP ID, Tunnel ID, Extended Tunnel ID> as part of the
SESSION object and <Tunnel Sender Address, LSP ID, Sub-Group
Originator ID, Sub-Group ID> as part of the SENDER_TEMPLATE object.
Additional information signaled in the Path message is part of the
state created by an implementation. This mandatorily includes PHOP
and SENDER_TSPEC objects.
11.1. Incremental State Update
RSVP as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and
GMPLS [RFC3473] uses the same basic approach to state communication
and synchronization, namely full state is sent in each state
advertisement message. Per [RFC2205] Path and Resv messages are
idempotent. Also, [RFC2961] categorizes RSVP messages into two types:
trigger and refresh messages and improves RSVP message handling and
scaling of state refreshes but does not modify the full state
advertisement nature of Path and Resv messages. The full state
advertisement nature of Path and Resv messages has many benefits, but
also has some drawbacks. One notable drawback is when an incremental
modification is being made to a previously advertised state. In this
case, there is the message overhead of sending the full state and the
cost of processing it. It is desirable to overcome this drawback and
add/delete S2L sub-LSPs to a P2MP LSP Tunnel by incrementally
updating the existing state.
It is possible to use the procedures described in this document to
allow S2L sub-LSPs to be incrementally added or deleted from the P2MP
LSP by allowing a Path or a PathTear message to incrementally change
the existing P2MP LSP Tunnel Path state.
As described in section 4.2, multiple Path messages can be used to
signal a P2MP LSP Tunnel. The Path messages are distinguished by
different <Sub-Group Originator ID, Sub-Group ID> tuples in the
SENDER_TEMPLATE object. In order to perform incremental S2L sub-LSP
state addition a separate Path message with a new sub-Group ID is
used to add the new S2L sub-LSPs, by the ingress LSR. The Sub-Group
Originator ID MUST be set to the TE Router ID [RFC3477] of the node
that sets the Sub-Group ID.
This maintains the idempotent nature of RSVP Path messages; avoids
keeping track of individual S2L sub-LSP state expiration and provides
the ability to perform incremental P2MP LSP Tunnel state updates.
11.2. Combining Multiple Path Messages
There is a tradeoff between the number of Path messages used by the
ingress to maintain the P2MP LSP Tunnel and using full state refresh
to add S2L sub-LSPs. It is possible to combine S2L sub-LSPs
previously advertised in different Path messages into a single Path
message in order to reduce the number of Path messages needed to
maintain the P2MP LSP. This can also be done by a transit node that
performed fragmentation and at a later point is able to combine
multiple Path messages that it generated into a single Path message.
This may happen when one or more S2L sub-LSPs are pruned from the
existing Path states.
The new Path message is signaled by the node that is combining
multiple Path messages with all the S2L sub-LSPs that are being
combined in a single Path message. This Path message contains a new
Sub-Group ID field value. When a new Path and Resv message that is
signaled for an existing S2L sub-LSP is received by a transit LSR,
state including the new instance of the S2L sub-LSP is created.
The S2L sub-LSP SHOULD continue to be advertised in both the old and
new Path messages until a Resv message listing the S2L sub-LSP and
corresponding to the new Path message is received by the combining
node. Hence until this point state for the S2L sub-LSP SHOULD be
maintained as part of the Path state for both the old and the new
Path message [Section 3.1.3, 2205]. At that point the S2L sub-LSP
SHOULD be deleted from the old Path state using a PathTear message.
The S2L sub-LSP should also be removed from the old Path message and
the old Path message should be signaled again, if there are other
remaining S2L sub-LSPs in the old Path message.
A Path message with a Sub-Group_ID(n+1) may signal a set of S2L sub-
LSPs that belong partially or entirely to an already existing Sub-
Group_ID(i), i <= n, the SESSION object and <Sender Tunnel Address,
LSP-ID, Sub-Group Originator ID> being the same. Or it may signal a
strictly non-overlapping new set of S2L sub-LSPs with a strictly
higher Sub-Group_ID value.
1) If Sub-Group_ID(i) = Sub-Group_ID(n+1), i =< n then either a full
refresh is indicated by the Path message or a S2L Sub-LSP is added
to/deleted from the group signaled by Sub-Group_ID(n+1)
2) If Sub-Group_ID(i) != Sub-Group_ID(n+1), i =< n then the Path
message is signaling a set of S2L sub-LSPs that belong partially or
entirely to an already existing Sub-Group_ID(i) or a strictly non-
overlapping set of S2L sub-LSPs.
12. Control of Branch Fate Sharing
An ingress LSR can control the behavior of an LSP if there is 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' such
that any failure anywhere within the LSP tree causes the entire P2MP
LSP Tunnel to fail.
The ingress LSP may request 'LSP integrity' by setting bit [section
21.3] of the Attributes Flags TLV. The bit is set if LSP integrity is
required.
It is RECOMMENDED to use the LSP_ATTRIBUTES Object for this flag and
not the LSP_REQUIRED_ATTRIBUTES Object.
A branch LSR that supports the Attributes Flags TLV and recognizes
this bit MUST support LSP integrity or reject the LSP setup with a
PathErr carrying the error "Routing Error"/"Unsupported LSP
Integrity"
13. Admin Status Change 12. Admin Status Change
A branch node that receives an ADMIN_STATUS object processes it A branch node that receives an ADMIN_STATUS object processes it nor-
normally and also relays the ADMIN_STATUS object in a Path on every mally and also relays the ADMIN_STATUS object in a Path on every
branch. All Path messages may be concurrently sent to the downstream branch. All Path messages may be concurrently sent to the downstream
neighbors. neighbors.
Downstream nodes process the change in the ADMIN_STATUS object per Downstream nodes process the change in the status object per
[RFC3473], including generation of Resv messages. When the last [RFC3473], including generation of Resv messages. When the last
received upstream ADMIN_STATUS object had the R bit set, branch nodes received upstream ADMIN_STATUS object had the R bit set, branch nodes
wait for a Resv message with a matching ADMIN_STATUS object to be wait for a Resv message with a matching ADMIN_STATUS object to be
received (or a corresponding PathErr or ResvTear messsage) on all received (or a corresponding PathErr or ResvTear messsage) on all
branches before relaying a corresponding Resv message upstream. branches before relaying a corresponding Resv message upstream.
14. Label Allocation on LANs with Multiple Downstream Nodes 13. Label Allocation on LANs with Multiple Downstream Nodes
A sender on a LAN uses a different label for sending traffic to each A sender on a LAN uses a different label for sending traffic to each
node on the LAN that belongs to the P2MP LSP Tunnel. Thus the sender node on the LAN that belongs to the P2MP LSP. Thus the sender per-
performs replication. It may be considered desirable on a LAN to use forms replication. It may be considered desirable on a LAN to use the
the same label for sending traffic to multiple nodes belonging to the same label for sending traffic to multiple nodes belonging to the
same P2MP LSP Tunnel, to avoid replication. Procedures for doing this same P2MP LSP, to avoid replication. Procedures for doing this are
are for further study. Given the relatively small number of receivers for further study.
on LANs typically deployed in MPLS networks, this is not currently
seen as a practical problem. Furthermore avoiding replication at the
sender on a LAN requires significant complexity in the control plane.
Given the tradeoff we propose the use of replication by the sender on
a LAN.
15. Make-before-break 14. P2MP LSP and Sub-LSP Re-optimization
Let's consider the following cases where make-before-break is needed: It is possible to change the path used by P2MP LSPs to reach the des-
tinations of the P2MP Tunnel. There are two methods that can be used
to accomplish this. The first is make-before-break, defined in
[RFC3209], and the second uses the sub-groups defined above.
15.1. P2MP Tree Re-optimization 14.1. Make-before-break
In this case all the S2L sub-LSPs are signaled with a different LSP In this case all the S2L sub-LSPs are signaled with a different LSP
ID by the ingress-LSR and follow make-before-break procedure ID by the ingress-LSR and follow make-before-break procedure defined
[RFC3209]. Thus a new P2MP LSP Tunnel instance is established. Each in [RFC3209]. Thus a new P2MP LSP is established. Each S2L sub-LSP is
S2L sub-LSP is signaled with a different LSP ID, corresponding to the signaled with a different LSP ID, corresponding to the new P2MP LSP.
new P2MP TE LSP. The ingress can, after moving traffic to the new After moving traffic to the new P2MP LSP, the ingress can tear down
instance, tear down the previous P2MP LSP Tunnel instance. the old P2MP LSP. This procedure can be used to re-optimize the path
of the entire P2MP LSP or paths to a subset of the destinations of
the P2MP LSP. When modifying just a portion of the P2MP LSP this
approach requires the entire P2MP LSP to be resignaled.
15.2. Re-optimization of a subset of S2L sub-LSPs 14.2. Sub-Group Based Re-optimization
One way to accomplish re-optimization of a subset of S2L sub-LSPs Any node may initiate re-optimization of a set of S2L sub-LSPs by
that belong to a P2MP LSP Tunnel is to resignal the entire tree with using the incremental state update and then, optionally, combining
a new LSP-ID as described in the previous subsection. multiple path messages.
(There is NO-CONSENSUS between the authors on rest of the text in To alter the path taken by a particular set of S2L sub-LSPs the node
this subsection and it needs further discussion.) initiating the path change initiates one or more separate Path mes-
sages, for the same P2MP LSP, each with a new sub-Group ID. The gen-
eration of these Path messages, each with one or more S2L sub-LSPs,
follows procedures in section 5.2. As is the case in Section 10.2, a
particular egress continues to be advertised in both the old and new
Path messages until a Resv message listing the egress and correspond-
ing to the new Path message is 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. Sub-tree re-optimization is then com-
pleted.
It is possible to accomplish re-optimization of one or more S2L sub- As is always the case, a node may choose to combine multiple path
LSPs without re-signaling rest of the P2MP LSP. To achieve this a messages as described in section 10.2.
sub-LSP ID is used to identify each S2L sub-LSP. This is encoded in
the S2L sub-LSP object. Each re-optimized S2L sub-LSP is signaled
with a different sub-LSP ID and hence a new S2L sub-LSP is
established. Once the new setup is complete, the old S2L sub-LSP can
be torn down. In some cases this may result in transient data
duplication.
16. Fast Reroute 15. Fast Reroute
[RSVP-FR] extensions can be used to perform fast reroute for the [RSVP-FR] extensions can be used to perform fast reroute for the
mechanism described in this document. mechanism described in this document.
16.1. Facility Backup 15.1. Facility Backup
Facility backup as described in [RSVP-FR] can be used to protect P2MP Facility backup as described in [RSVP-FR] can be used to protect P2MP
LSP Tunnels. LSPs.
If link protection is desired, a bypass tunnel is used to protect the If link protection is desired, a bypass tunnel is used to protect the
link between the PLR and next-hop. Thus all S2L sub-LSPs that use the link between the PLR and next-hop. Thus all S2L sub-LSPs that use the
link can be protected in the event of link failure. Note that all link can be protected in the event of link failure. Note that all
such S2L sub-LSPs belonging to a particular instance of a P2MP tunnel such S2L sub-LSPs belonging to a particular instance of a P2MP tunnel
will share the same outgoing label on the link between the PLR and will share the same outgoing label on the link between the PLR and
the next-hop. This is the P2MP LSP label on the link. Label stacking the next-hop. This is the P2MP LSP label on the link. Label stacking
is used to send data for each P2MP LSP in the bypass tunnel. The is used to send data for each P2MP LSP in the bypass tunnel. The
inner label is the P2MP LSP Tunnel label allocated by the nhop. inner label is the P2MP LSP label allocated by the nhop. During fail-
During failure Path messages for each S2L sub-LSP, that is effected, ure Path messages for each S2L sub-LSP, that is effected, will be
will be sent to the MP, by the PLR. It is recommended that the PLR sent to the MP, by the PLR. It is recommended that the PLR use the
use the sender template specific method to identify these Path sender template specific method to identify these Path messages.
messages. Hence the PLR will set the source address in the sender Hence the PLR will set the source address in the sender template to a
template to a local PLR address. The MP will use the LSP-ID to local PLR address. The MP will use the LSP-ID to identify the corre-
identify the corresponding S2L sub-LSPs. sponding S2L sub-LSPs.
The MP MUST not use the <sub-group originator ID, sub-group ID> while The MP MUST not use the <sub-group originator ID, sub-group ID> while
identifying the corresponding S2L sub-LSPs. identifying the corresponding S2L sub-LSPs.
In order to further process a S2L sub-LSP it will determine the In order to further process a S2L sub-LSP it will determine the pro-
protected S2L sub-LSP using the LSP-id and the S2L sub-LSP object. tected S2L sub-LSP using the LSP-id and the S2L sub-LSP object.
If node protection is desired, the bypass tunnel must intersect the If node protection is desired, the bypass P2P tunnel must intersect
path of the protected S2L sub-LSPs somewhere downstream of the PLR. the path of the protected S2L sub-LSPs on a LSR that is downstream
This constrains the set of S2L sub-LSPs being backed-up via that from the PLR. This constrains the set of S2L sub-LSPs being backed-up
bypass tunnel to those that pass through a common downstream MP. The via that bypass tunnel to those S2L sub-LSPs that pass through a com-
MP will allocate the same label to all such S2L sub-LSPs belonging to mon downstream MP. This MP is the destination of the bypass tunnel.
a particular instance of a P2MP tunnel. This will be the inner label The MP will allocate the same label to all such S2L sub-LSPs belong-
used during label stacking. This may require the PLR to be branch ing to a particular instance of a P2MP tunnel. This will be the inner
capable as multiple bypass tunnels may be required to backup the set label used during label stacking by the PLR when it sends data for
of S2L sub-LSPs passing through the protected node. Else all the S2L each P2MP LSP in the bypass tunnel. The outer label is the bypass
sub-LSPs being backed up must pass through the same MP. tunnel label. During failure of the protected node the PLR will send
Path messages for the protected S2L Sub-LSPs to the MP using proce-
dures that are same as the link protection procedures described
above. Node protection may require the PLR to be branch capable as
multiple bypass tunnels may be required to backup the set of S2L sub-
LSPs passing through the protected node. Else all the S2L sub-LSPs
passing through the protected node must also pass through a MP that
is downstream from the protected node.
16.2. One to One Backup 15.2. One to One Backup
One to one backup as described in [RSVP-FR] can be used to protect a One to one backup as described in [RSVP-FR] can be used to protect a
particular S2L sub-LSP against link and next-hop failure. Protection 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 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 next-hop. All the S2L sub-LSPs corresponding to the same instance of
the P2MP tunnel, between the PLR and the next-hop share the same P2MP the P2MP tunnel, between the PLR and the next-hop share the same P2MP
LSP Tunnel label. LSP label.
All or some of these S2L sub-LSPs may be protected. All or some of these S2L sub-LSPs may be protected.
The detour S2L sub-LSPs may or may not share labels, depending on the The detour S2L sub-LSPs may or may not share labels, depending on the
detour path. Thus the set of outgoing labels and next-hops for a P2MP detour path. Thus the set of outgoing labels and next-hops for a P2MP
LSP Tunnel that was using a single next-hop and label between the PLR LSP that was using a single next-hop and label between the PLR and
and next-hop before protection, may change once protection is next-hop before protection, may change once protection is triggerred.
triggerred.
Its is recommended that the path specific method be used to identify Its is recommended that the path specific method be used to identify
a backup S2L sub-LSP. Hence the DETOUR object will be inserted in the a backup S2L sub-LSP. Hence the DETOUR object will be inserted in the
backup Path message. A backup S2L sub-LSP MUST be treated as backup Path message. A backup S2L sub-LSP MUST be treated as belong-
belonging to a different P2MP tunnel instance than the one specified ing to a different P2MP tunnel instance than the one specified by the
by the LSP-id. Furthermore multiple backup S2L sub-LSPs MUST be LSP-id. Furthermore multiple backup S2L sub-LSPs MUST be treated as
treated as part of the same P2MP tunnel instance if they have the part of the same P2MP tunnel instance if they have the same LSP-id
same LSP-id and the same DETOUR objects. Note that as specified in and the same DETOUR objects. Note that as specified in section 4 S2L
section 3 S2L sub-LSPs between different P2MP tunnel instances use sub-LSPs between different P2MP tunnel instances use different
different labels. labels.
If there is only S2L sub-LSP in the Path message, the DETOUR object If there is only one S2L sub-LSP in the Path message, the DETOUR
applies to that sub-LSP. If there are multiple S2L sub-LSPs in the object applies to that sub-LSP. If there are multiple S2L sub-LSPs in
Path message the DETOUR applies to all the S2L sub-LSPs. the Path message the DETOUR applies to all the S2L sub-LSPs.
17. Support for LSRs that are not P2MP Capable 16. Support for LSRs that are not P2MP Capable
It may be that some LSRs in a network are capable of processing the 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 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 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 branch LSR by a received Path message, it MUST respond with a PathErr
message carrying the Error Value "Routing Error" and Error Code message carrying the Error Value "Routing Error" and Error Code
"Unable to Branch". "Unable to Branch".
Its also conceivable that some LSRs, in a network deploying P2MP Its also conceivable that some LSRs, in a network deploying P2MP
capability, may not support the extensions described in this capability, may not support the extensions described in this docu-
document. If a Path message for the establishment of a P2MP LSP ment. If a Path message for the establishment of a P2MP LSP reaches
Tunnel reaches such an LSR it will reject it with a PathErr because such an LSR it will reject it with a PathErr because it will not rec-
it will not recognize the C-Type of the P2MP SESSION object. ognize the C-Type of the P2MP SESSION object.
LSRs that do not support the P2MP extensions in this document may be LSRs that do not support the P2MP extensions in this document may be
included as transit LSRs by the use of LSP-stitching and LSP- included as transit LSRs by the use of LSP-stitching [LSP-STITCH] and
hierarchy [LSP-HIER]. Note that LSRs that are required to play any LSP-hierarchy [LSP-HIER]. Note that LSRs that are required to play
other role in the network (ingress, branch or egress) MUST support any other role in the network (ingress, branch or egress) MUST sup-
the extensions defined in this document. port the extensions defined in this document.
The use of LSP-stitching and LSP-hierarchy [LSP-HIER] allows P2MP LSP The use of LSP-stitching and LSP-hierarchy [LSP-HIER] allows to build
Tunnels to be built in such an environment. A P2P LSP segment is P2MP LSPs in such an environment. A P2P LSP segment is signaled from
signaled from the previous P2MP capable hop of a legacy LSR to the the previous P2MP capable hop of a legacy LSR to the next P2MP capa-
next P2MP capable hop. Of course this assumes that intermediate ble hop. Of course this assumes that intermediate legacy LSRs are
legacy LSRs are transit LSRs and cannot act as P2MP branch points. transit LSRs and cannot act as P2MP branch points. Transit LSRs along
Transit LSRs along this LSP segment do not process control plane this LSP segment do not process control plane messages associated
messages associated with a P2MP LSP Tunnel. Furthermore these LSRs with a P2MP LSP. Furthermore these LSRs also do not need to have P2MP
also do not need to have P2MP data plane capability as they only need data plane capability as they only need to process data belonging to
to process data belonging to the P2P LSP segment. Hence these LSRs do the P2P LSP segment. Hence these LSRs do not need to support P2MP
not need to support P2MP MPLS. This P2P LSP segment is stitched to MPLS. This P2P LSP segment is stitched to the incoming P2MP LSP.
the incoming P2MP LSP Tunnel. After the P2P LSP segment is After the P2P LSP segment is established the P2MP Path message is
established the P2MP Path message is sent to the next P2MP capable sent to the next P2MP capable LSR as a directed Path message. The
LSR as a directed Path message. The next P2MP capable LSR stitches next P2MP capable LSR stitches the P2P LSP segment to the outgoing
the P2P LSP segment to the outgoing P2MP LSP Tunnel. P2MP LSP.
In packet networks, the S2L sub-LSPs may be nested inside the outer In packet networks, the S2L sub-LSPs may be nested inside the outer
P2P LSP Tunnel. Hence label stacking can be used to enable use of the P2P LSP. Hence label stacking can be used to enable use of the same
same LSP Tunnel segment for multiple P2MP LSP Tunnels. Stitching and LSP segment for multiple P2MP LSP. Stitching and nesting considera-
nesting considerations and procedures are described further in [INT- tions and procedures are described further in [INT-REG].
REG].
It may be an overhead for an operator to configure the P2P LSP It may be an overhead for an operator to configure the P2P LSP seg-
segments in advance, when it is desired to support legacy LSRs. It ments in advance, when it is desired to support legacy LSRs. It may
may be desirable to do this dynamically. The ingress can use IGP be desirable to do this dynamically. The ingress can use IGP exten-
extensions to determine non P2MP capable LSRs. It can use this sions to determine non P2MP capable LSRs [TE-NODE-CAP]. It can use
information to compute S2L sub-LSP paths such that they avoid these this information to compute S2L sub-LSP paths such that they avoid
legacy LSRs. The explicit route object of a S2L sub-LSP path may these legacy LSRs. The explicit route object of a S2L sub-LSP path
contain loose hops if there are legacy LSRs along the path. The may contain loose hops if there are legacy LSRs along the path. The
corresponding explicit route contains a list of objects upto the P2MP corresponding explicit route contains a list of objects upto the P2MP
capable LSR that is adjacent to a legacy LSR followed by a loose 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 object with the address of the next P2MP capable LSR. The P2MP capa-
capable LSR expands the loose hop using its TED. When doing this it ble LSR expands the loose hop using its TED. When doing this it
determines that the loose hop expansion requires a P2P LSP to tunnel 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 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 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 to the next P2MP capable LSR using non-adjacent signaling. The P2MP
capable LSR that initiates the non-adjacent signaling message to the capable LSR that initiates the non-adjacent signaling message to the
next P2MP capable LSR may have to employ a fast detection mechanism next P2MP capable LSR may have to employ a fast detection mechanism
such as [BFD] to the next P2MP capable LSR. such as [BFD] to the next P2MP capable LSR.
This may be needed for the directed Path message Head-End to use node This may be needed for the directed Path message Head-End to use node
protection FRR when the protected node is the directed Path message protection FRR when the protected node is the directed Path message
tail. tail.
Note that legacy LSRs along a P2P LSP segment cannot perform node Note that legacy LSRs along a P2P LSP segment cannot perform node
protection of the tail of the P2P LSP segment. protection of the tail of the P2P LSP segment.
18. Reduction in Control Plane Processing with LSP Hierarchy 17. Reduction in Control Plane Processing with LSP Hierarchy
It is possible to take advantage of LSP hierarchy [LSP-HIER] while It is possible to take advantage of LSP hierarchy [LSP-HIER] while
setting up P2MP LSP Tunnels, as described in the previous section, to setting up P2MP LSP, as described in the previous section, to reduce
reduce control plane processing along transit LSRs that are P2MP control plane processing along transit LSRs that are P2MP capable.
capable. This is applicable only in environments where LSP hierarchy This is applicable only in environments where LSP hierarchy can be
can be used. Transit LSRs along a P2P LSP segment, being used by a used. Transit LSRs along a P2P LSP segment, being used by a P2MP LSP,
P2MP LSP Tunnel, do not process control plane messages associated do not process control plane messages associated with the P2MP LSP.
with the P2MP LSP Tunnel. Infact they are not aware of these messages Infact they are not aware of these messages as they are tunneled over
as they are tunneled over the P2P LSP segment. This reduces the the P2P LSP segment. This reduces the amount of control plane pro-
amount of control plane processing required on these transit LSRs. cessing required on these transit LSRs.
Note that the P2P LSP segments can be dynamically set up as described Note that the P2P LSP segments can be dynamically set up as described
in the previous section or preconfigured. For example in Figure 2, in the previous section or preconfigured. For example in Figure 2,
PE1 can setup a P2P LSP to P1 and use that as a LSP segment. The Path PE1 can setup a P2P LSP to P1 and use that as a LSP segment. The Path
messages for PE3 and PE4 can now be tunneled over the LSP segment. messages for PE3 and PE4 can now be tunneled over the LSP segment.
Thus P3 is not aware of the P2MP LSP Tunnel and does not process the Thus P3 is not aware of the P2MP LSP and does not process the P2MP
P2MP control messages. control messages.
19. P2MP LSP Tunnel Remerging and Cross-Over 18. P2MP LSP Remerging and Cross-Over
This section is currently under discussion between the authors and
will be updated in the next revision.
The functional description described so far assumes that multiple The functional description described so far assumes that multiple
Path messages received by a LSR for the same P2MP LSP Tunnel arrive Path messages received by a LSR for the same P2MP LSP arrive on the
on the same incoming interface. However this may not always be the same incoming interface. However this may not always be the case.
case. Further discussion is needed for this section.
P2MP tree remerging or cross-over occurs when a transit or egress P2MP tree remerging or cross-over occurs when a transit or egress
node receives the signaling state i.e. Path message for the same P2MP node receives the signaling state i.e. Path message for the same P2MP
TE LSP from more than one previous hop. If the re-merged S2L sub-LSPs TE LSP from more than one previous hop. If the remerged S2L sub-LSPs
are sent out on different interfaces there is no data plane issue. are sent out on different interfaces there is no data plane issue.
However if the re-merged S2L sub-LSPs are sent out on the same However if the remerged S2L sub-LSPs are sent out on the same inter-
interface it can result in data duplication downstream. In order to face it can result in data duplication downstream. In order to
describe identification of cross over and remerging by a LSR let us describe identification of cross over and remerging by a LSR let us
list the various cases when state for a S2L sub-LSP is received by a list the various cases when state for a S2L sub-LSP is received by a
LSR. LSR.
Case1: S2L sub-LSP already exist as part of an existing Path state. Case1: S2L sub-LSP already exist as part of an existing Path state.
The following are the various sub-cases. The following are the various sub-cases.
a) The new S2L sub-LSP uses the same PHOP and outgoing interface
a) The new S2L sub-LSP uses the same PHOP and outgoing interface as as the existing S2L sub-LSP. This is either a refresh or can occur
the existing S2L sub-LSP. This is either a refresh or can occur when when multiple existing Path messages are combined in a new Path mes-
multiple existing Path messages are combined in a new Path message. sage.
b) The new S2L sub-LSP uses the same PHOP but different outgoing b) The new S2L sub-LSP uses the same PHOP but different outgoing
interface as the existing S2L sub-LSP. This is a case of re-routing. interface as the existing S2L sub-LSP. This is a case of re-routing.
c) The new S2L sub-LSP uses a different PHOP and same outgoing c) The new S2L sub-LSP uses a different PHOP and same outgoing
interface as the existing S2L sub-LSP. This is a case of re-merging. interface as the existing S2L sub-LSP. This is a case of re-routing.
d) The new S2L sub-LSP uses a different PHOP and a different out-
d) The new S2L sub-LSP uses a different PHOP and a different outgoing going interface as compared to the existing S2L sub-LSP. This is a
interface as compared to the existing S2L sub-LSP. This is a case of case of re-routing.
cross-over.
Case2: S2L sub-LSP does not exist as part of an existing Path state. Case2: S2L sub-LSP does not exist as part of an existing Path state.
The following are the sub-cases. The following are the sub-cases.
a) The new S2L sub-LSP uses a PHOP and outgoing interface that is a) The new S2L sub-LSP uses a PHOP and outgoing interface that is
same as the PHOP and outgoing interface used by an existing S2L sub- same as the PHOP and outgoing interface used by an existing S2L sub-
LSP. This is a legal case of signaling a new S2L sub-LSP. LSP that belongs to the same P2MP LSP. This is a legal case of sig-
naling a new S2L sub-LSP.
b) The new S2L sub-LSP uses a PHOP that is same as that used by an b) The new S2L sub-LSP uses a PHOP that is same as that used by an
existing S2L sub-LSP. However the outgoing interface is different existing S2L sub-LSP. However the outgoing interface is different
from the outgoing interfaces used by existing S2L sub-LSPs. This is a from the outgoing interfaces used by existing S2L sub-LSPs belonging
legal case of signaling a new S2L sub-LSP. to the same P2MP LSP. This is a legal case of signaling a new S2L
sub-LSP.
c) The new S2L sub-LSP uses a different PHOP than that used by any of c) The new S2L sub-LSP uses a different PHOP than that used by any
the existing S2L sub-LSP. However the outgoing interface is same as of the existing S2L sub-LSP that belong to the same P2MP LSP . How-
the outgoing interface used by an existing S2L sub-LSPs. This is a ever the outgoing interface is same as the outgoing interface used by
case of remerging. an existing S2L sub-LSPs. This is a case of remerging.
d) The new S2L sub-LSP uses a different PHOP than that used by any
d) The new S2L sub-LSP uses a different PHOP than that used by any of of the existing S2L sub-LSP that belong to the same P2MP LSP. Also
the existing S2L sub-LSP. Also the outgoing interface is different the outgoing interface is different from the outgoing interfaces used
from the outgoing interfaces used by existing S2L sub-LSPs. This is a by existing S2L sub-LSPs. This is a case of cross-over.
case of cross-over.
Cases 1(d) and 2(d) above identify cross-over and this is considered Case 2(d) above identifies cross-over and this is considered legal.
legal. Cases 1(c) and 2(c) above identify remerging in the data Case 2(c) above identifies remerging in the data plane. If the LSR is
plane. If the LSR is capable of remerging in the data plane this is capable of remerging in the data plane this is considered legal.
considered legal.
The below procedure applies for remerging. The below procedure applies for remerging.
The remerge error case is detected by checking incoming Path messages The remerge error case is detected by checking incoming Path messages
that represent new P2MP TE LSP state and seeing if they represent that represent new P2MP TE LSP state and seeing if they represent
both known LSP state and a different S2L sub-LSP list. Specifically, both known LSP state and a different S2L sub-LSP list. Specifically,
the remerge check MUST be performed when processing Path messages the remerge check MUST be performed when processing Path messages
that contain SESSION, SENDER_TEMPLATE and RSVP_HOP objects that have that contain SESSION, SENDER_TEMPLATE and RSVP_HOP objects that have
not previously been seen on a particular interface. The remerge check not previously been seen on a particular interface. The remerge check
consists of attempting to locate state that has the same values in consists of attempting to locate state that has the same values in
the SESSION object and in the tunnel sender address and LSP ID fields the SESSION object and in the tunnel sender address and LSP ID fields
of the SENDER_TEMPLATE object. of the SENDER_TEMPLATE object.
If no matching state is located, then there is no remerge condition. If no matching state is located, then there is no remerge condition.
If matching state is found, then the list of S2L Sub-LSPs associated If matching state is found, then the list of S2L Sub-LSPs associated
with the new Path message is compared against the list present in the with the new Path message is compared against the list present in the
located state. If any addresses in the lists of S2L sub-LSPs match, located state. If any addresses in the lists of S2L sub-LSPs match,
then it is the legal LSP rerouting case mentioned here above. then it is the legal LSP rerouting case mentioned here above.
If there are no overlap in the lists, and the LSR is capable of If there are no overlap in the lists, the node checks whether any of
remerging in the data plane, this is considered legal. Else the new the outgoing interfaces, as identified by the ERO/SUB_EROs, are an
Path message MUST be handled according to remerge error processing as outgoing interface already associated with the existing P2MP LSP. If
described below. not, then legal LSP crossing is being performed. Else re-merging has
occurred and if the LSR is capable of remerging in the data plane,
this is considered legal. In that case the LSR will return the label
already associated with the existing S2L sub-LSP with the matching
egress interface, in the Resv message it sends upstream. If the LSR
is not capable of remerging in the data plane the new Path message
MUST be handled according to remerge error processing as described
below.
The LSR generates a PathErr message with Error Code "Routing The LSR generates a PathErr message with Error Code "Routing Prob-
Problem/P2MP Remerge Detected" towards the upstream node (i.e. the lem/P2MP Remerge Detected" towards the upstream node (i.e. the node
node that sent the Path message) until it reaches the node that that sent the Path message) until it reaches the node that caused the
caused the remerge condition. Identification of the offending node remerge condition. Identification of the offending node requires
requires special processing by the nodes upstream of the error. A special processing by the nodes upstream of the error. A node that
node that receives a PathErr message that contains a the error receives a PathErr message that contains the error "Routing Prob-
"Routing Problem/P2MP Remerge Detected" MUST check to see if it is lem/P2MP Remerge Detected" MUST check to see if it is the offending
the offending node. This check is done by comparing the S2L sub-LSPs node. This check is done by comparing the S2L sub-LSPs listed in the
listed in the PathErr message with existing LSP state. If any of the PathErr message with existing LSP state. If any of the egresses are
egresses are already present in any Path state associated with the already present in any Path state associated with the P2MP TE LSP
P2MP TE LSP other than the one associated with the <SESSION, other than the one associated with the <SESSION, SENDER_TEMPLATE>
SENDER_TEMPLATE> objects signaled in the PathErr message, then the objects signaled in the PathErr message, then the node is the signal-
node is the signaling branch node that caused the remerge condition. ing branch node that caused the remerge condition. This node SHOULD
This node SHOULD then correct the remerge condition by adding all S2L then correct the remerge condition by adding all S2L sub-LSPs listed
sub-LSPs listed in the offending Path state to the Path state (and in the offending Path state to the Path state (and Path message)
Path message) associated to these S2L sub-LSPs. Note that the new associated to these S2L sub-LSPs. Note that the new Path state may be
Path state may be sent out the same outgoing interface in different sent out the same outgoing interface in different Path messages in
Path messages in order to meet IP packet size limitations. If use of order to meet IP packet size limitations. If use of a new outgoing
a new outgoing interface violates one or more SERO constraint, then a interface violates one or more SERO constraint, then a PathErr mes-
PathErr message containing the associated egresses and any identified sage containing the associated egresses and any identified valid
valid egresses SHOULD be generated with the error code "Routing egresses SHOULD be generated with the error code "Routing Problem"
Problem" and error value of "ERO Resulted in Remerge". and error value of "ERO Resulted in Remerge".
This process may continue hop-by-hop until the ingress is reached. This process may continue hop-by-hop until the ingress is reached.
The only case where this process will fail is when all the listed S2L The only case where this process will fail is when all the listed S2L
sub-LSPs are deleted prior to the PathErr message propagating to the sub-LSPs are deleted prior to the PathErr message propagating to the
ingress. In this case, the whole process will be corrected on the ingress. In this case, the whole process will be corrected on the
next (refresh or trigger) transmission of the offending Path message. next (refresh or trigger) transmission of the offending Path message.
In all cases where a remerge error is not detected, normal processing In all cases where a remerge error is not detected, normal processing
continues. continues.
20. New and Updated Message Objects 19. New and Updated Message Objects
This section presents the new and updated RSVP message objects used This section presents the RSVP object formats as modified by this
by this document. document.
20.1. P2MP LSP Tunnel SESSION Object 19.1. SESSION Object
A P2MP LSP Tunnel SESSION object is used. This object uses the A P2MP LSP SESSION object is used. This object uses the existing SES-
existing SESSION C-Num. New C-Types are defined to accommodate a SION C-Num. New C-Types are defined to accommodate a logical P2MP
logical P2MP destination identifier of the P2MP Tunnel. This SESSION destination identifier of the P2MP Tunnel. This SESSION object has a
object has a similar structure as the existing point to point RSVP-TE similar structure as the existing point to point RSVP-TE SESSION
SESSION object. However the destination address is set to the P2MP ID object. However the destination address is set to the P2MP ID instead
instead of the unicast Tunnel Endpoint address. All S2L sub-LSPs part of the unicast Tunnel Endpoint address. All S2L sub-LSPs part of the
of the same P2MP LSP Tunnel share the same SESSION object. This same P2MP LSP share the same SESSION object. This SESSION object
SESSION object identifies the P2MP Tunnel. identifies the P2MP Tunnel.
The combination of the SESSION object, the SENDER_TEMPLATE object and The combination of the SESSION object, the SENDER_TEMPLATE object and
the S2L SUB-LSP object, identifies each S2L sub-LSP. This follows the the S2L SUB-LSP object, identifies each S2L sub-LSP. This follows the
existing P2P RSVP-TE notion of using the SESSION object for existing P2P RSVP-TE notion of using the SESSION object for identify-
identifying a P2P Tunnel which in turn can contain multiple LSP ing a P2P Tunnel which in turn can contain multiple LSPs, each dis-
Tunnels, each distinguished by a unique SENDER_TEMPLATE object. tinguished by a unique SENDER_TEMPLATE object.
20.1.1. P2MP IPv4 LSP SESSION Object 19.1.1. P2MP LSP Tunnel IPv4 SESSION Object
Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = TBD Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = TBA
0 1 2 3 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 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 | | P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID | | MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P2MP ID P2MP ID
A 32-bit identifier used in the SESSION object that remains A 32-bit identifier used in the SESSION object that remains
constant over the life of the P2MP tunnel. It encodes the constant over the life of the P2MP tunnel. It encodes the
P2MP ID and identifies the set of destinations of the P2MP P2MP ID and identifies the set of destinations of the P2MP
LSP Tunnel. Tunnel.
Tunnel ID Tunnel ID
A 16-bit identifier used in the SESSION object that remains A 16-bit identifier used in the SESSION object that remains
constant over the life of the P2MP tunnel. constant over the life of the P2MP tunnel.
Extended Tunnel ID Extended Tunnel ID
A 32-bit identifier used in the SESSION object that remains A 32-bit identifier used in the SESSION object that remains
constant over the life of the P2MP tunnel. Normally set to constant over the life of the P2MP tunnel. Normally set to
all zeros. Ingress nodes that wish to narrow the scope of a all zeros. Ingress nodes that wish to narrow the scope of a
SESSION to the ingress-PID pair may place their IPv4 address SESSION to the ingress-PID pair may place their IPv4 address
here as a globally unique identifier [RFC3209]. here as a globally unique identifier [RFC3209].
skipping to change at page 33, line 13 skipping to change at page 35, line 15
constant over the life of the P2MP tunnel. constant over the life of the P2MP tunnel.
Extended Tunnel ID Extended Tunnel ID
A 32-bit identifier used in the SESSION object that remains A 32-bit identifier used in the SESSION object that remains
constant over the life of the P2MP tunnel. Normally set to constant over the life of the P2MP tunnel. Normally set to
all zeros. Ingress nodes that wish to narrow the scope of a all zeros. Ingress nodes that wish to narrow the scope of a
SESSION to the ingress-PID pair may place their IPv4 address SESSION to the ingress-PID pair may place their IPv4 address
here as a globally unique identifier [RFC3209]. here as a globally unique identifier [RFC3209].
20.1.2. P2MP IPv6 LSP SESSION Object 19.1.2. P2MP LSP Tunnel IPv6 SESSION Object
This is same as the P2MP IPv4 LSP SESSION Object with the difference This is same as the P2MP IPv4 LSP SESSION Object with the difference
that the extended tunnel ID may be set to a 16 byte identifier that the extended tunnel ID may be set to a 16 byte identifier
[RFC3209]. [RFC3209].
20.2. SENDER_TEMPLATE object 19.2. SENDER_TEMPLATE object
The sender template contains the ingress-LSR source address. LSP ID The sender template contains the ingress-LSR source address. LSP ID
can be changed to allow a sender to share resources with itself. Thus can be can be changed to allow a sender to share resources with
multiple instances of the P2MP tunnel can be created, each with a itself. Thus multiple instances of the P2MP tunnel can be created,
different LSP ID. The instances can share resources with each other, each with a different LSP ID. The instances can share resources with
but use different labels. The S2L sub-LSPs corresponding to a each other, but use different labels. The S2L sub-LSPs corresponding
particular instance use the same LSP ID. to a particular instance use the same LSP ID.
As described in section 4.2 it is necessary to distinguish different As described in section 4.2 it is necessary to distinguish different
Path messages that are used to signal state for the same P2MP LSP Path messages that are used to signal state for the same P2MP LSP by
Tunnel by using a <Sub-Group ID Originator ID, Sub-Group ID> tuple. using a <Sub-Group ID Originator ID, Sub-Group ID> tuple. The
There are various methods to encode this information. This document SENDER_TEMPLATE object is modified to carry this information as shown
proposes the use of the SENDER_TEMPLATE object and modifies it to below.
carry this information as shown below. This encoding is subject to
review by the MPLS WG.
20.2.1. P2MP IPv4 LSP Tunnel SENDER_TEMPLATE Object 19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object
Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = TBD Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = TBA
0 1 2 3 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 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 | | IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID | | Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Group Originator ID | | Sub-Group Originator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 34, line 17 skipping to change at page 36, line 20
Sub-Group Originator ID Sub-Group Originator ID
The Sub-Group Originator ID is set to the TE Router ID of The Sub-Group Originator ID is set to the TE Router ID of
the LSR that originates the Path message. This is either the the LSR that originates the Path message. This is either the
ingress LSR or a LSR which re-originates the Path message ingress LSR or a LSR which re-originates the Path message
with its own Sub-Group Originator ID. with its own Sub-Group Originator ID.
Sub-Group ID Sub-Group ID
An identifier of a Path message used to differentiate An identifier of a Path message used to differentiate
multiple Path messages that signal state for the same P2MP multiple Path messages that signal state for the same P2MP
LSP. This may be seen as identifying a group of one or more LSP. This may be seen as identifying a group of one or more
egress nodes targeted by this Path message. If the third egress nodes targeted by this Path message.
mechanism for pruning is used as described in section 7.2,
the Sub-Group ID value of zero (0) has special meaning and
MUST NOT be used with P2MP LSP Tunnels in messages other
than PathTear messages. Use of a Sub-Group ID value of zero
(0) in PathTear messages is defined below.
LSP ID LSP ID
See [RFC3209] See [RFC3209]
20.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object 19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object
Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = TBD Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = TBA
0 1 2 3 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 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 | | IPv6 tunnel sender address |
+ + + +
| (16 bytes) | | (16 bytes) |
+ + + +
skipping to change at page 35, line 23 skipping to change at page 37, line 23
of the LSR that originates the Path message. This is either of the LSR that originates the Path message. This is either
the ingress LSR or a LSR which re-originates the Path the ingress LSR or a LSR which re-originates the Path
message with its own Sub-Group Originator ID. message with its own Sub-Group Originator ID.
Sub-Group ID Sub-Group ID
As above. As above.
LSP ID LSP ID
See [RFC3209] See [RFC3209]
20.3. S2L SUB-LSP IPv4 Object 19.3. S2L SUB-LSP Object
A new S2L Sub-LSP object identifies a particular S2L sub-LSP A new S2L Sub-LSP object identifies a particular S2L sub-LSP belong-
belonging to the P2MP LSP Tunnel. ing to the P2MP LSP.
20.3.1. S2L SUB-LSP IPv4 Object 19.3.1. S2L SUB-LSP IPv4 Object
SUB_LSP Class = TBD, S2L_SUB_LSP_IPv4 C-Type = TBD SUB_LSP Class = 50, S2L_SUB_LSP_IPv4 C-Type = TBA
0 1 2 3 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 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 S2L Sub-LSP destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Sub-LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Sub-LSP destination address IPv4 Sub-LSP destination address
IPv4 address of the S2L sub-LSP destination. IPv4 address of the S2L sub-LSP destination.
(There is NO-CONSENSUS amongst the authors on the sub-LSP ID 19.3.2. S2L SUB-LSP IPv6 Object
described below and it needs more discussion)
Sub-LSP ID
A 16-bit identifier that identifies a particular instance
of a S2L sub-LSP. It can be varied for S2L sub-LSP
make-before-break. Different S2L sub-LSPs, with the same SESSION
object and LSP ID, follow the label merge semantics described in
section 3 to form a particular instance of the P2MP tunnel.
20.3.2. S2L SUB-LSP IPv6 Object
SUB_LSP Class = TBD, S2L_SUB_LSP_IPv6 C-Type = TBD SUB_LSP Class = 50, S2L_SUB_LSP_IPv6 C-Type = TBA
This is same as the S2L IPv4 Sub-LSP object, with the difference that This is same as the S2L IPv4 Sub-LSP object, with the difference that
the destination address is a 16 byte IPv6 address. the destination address is a 16 byte IPv6 address.
20.4. FILTER_SPEC Object 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 |
| .... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
19.4. FILTER_SPEC Object
The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
object. object.
20.4.1. P2MP LSP_TUNNEL_IPv4 FILTER_SPEC Object 19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object
Class = FILTER SPEC, P2MP LSP_TUNNEL_IPv4 C-Type = TBD Class = FILTER SPEC, P2MP LSP_IPv4 C-Type = TBA
The format of the P2MP LSP_TUNNEL_IPv4 FILTER_SPEC object is The format of the P2MP LSP_IPv4 FILTER_SPEC object is identical to
identical to the P2MP LSP_TUNNEL_IPv4 SENDER_TEMPLATE object. the P2MP LSP_IPv4 SENDER_TEMPLATE object.
20.4.2. P2MP LSP_TUNNEL_IPv4 FILTER_SPEC Object 19.4.2. P2MP LSP_IPv4 FILTER_SPEC Object
Class = FILTER SPEC, P2MP LSP_TUNNEL_IPv6 C_Type = TBD Class = FILTER SPEC, P2MP LSP_IPv6 C-Type = TBA
The format of the P2MP LSP_TUNNEL_IPv6 FILTER_SPEC object is The format of the P2MP LSP_IPv6 FILTER_SPEC object is identical to
identical to the P2MP LSP_TUNNEL_IPv6 SENDER_TEMPLATE object. the P2MP LSP_IPv6 SENDER_TEMPLATE object.
20.5. SUB_EXPLICIT_ROUTE Object (SERO) 19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO)
The SERO is defined as identical to the ERO. The CNums are TBD and The P2MP Secondary Explicit Route Object (SERO) is defined as identi-
TBD of the form 11bbbbbb. cal to the ERO. The class of the P2MP SERO is the same as the SERO
defined in [RECOVERY] (TBA). The P2MP SERO C-Type = TBA The sub-
objects are identical to those defined for the ERO.
20.6. SUB_RECORD_ROUTE Object (SRRO) 19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO)
The SRRO is defined as identical to the RRO. The CNums are TBD and The P2MP Secondary Record Route Object (SRRO) is defined as identical
TBD of the form 11bbbbbb. to the ERO. The class of the P2MP SRRO is the same as the SRRO
defined in [RECOVERY] (TBA). The P2MP SRRO C-Type = TBA. The sub-
objects are identical to those defined for the RRO.
21. IANA Considerations 20. IANA Considerations
21.1. New Message Objects 20.1. New Class Numbers
IANA considerations for new message objects will be specified after IANA is requested to assign the following Class Numbers for the new
the objects used are decided upon. object classes introduced. The Class Types for each of them are to be
assigned via standards action. The sub-object types for the P2MP SEC-
ONDARY_EXPLICIT_ROUTE and P2MP_SECONDARY_RECORD_ROUTE follow the same
IANA considerations as those of the ERO and RRO [RFC3209].
21.2. New Error Codes 50 Class Name = SUB_LSP
Two new Error Codes are defined for use with the Error Value "Routing C-Type
Error". IANA is requested to assign values. 1 S2L_SUB_LSP_IPv4 C-Type
2 S2L_SUB_LSP_IPv6 C-Type
20.2. New Class Types
IANA is requested to assign the following C-Type values:
Class Name = SESSION
C-Type
13 P2MP_LSP_IPv4 C-Type
14 P2MP_LSP_IPv6 C-Type
Class Name = SENDER_TEMPLATE
C-Type
12 P2MP_LSP_IPv4 C-Type
13 P2MP_LSP_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
C-Type
2 P2MP SECONDARY_EXPLICIT_ROUTE C-Type
Class Name = SECONDARY_RECORD_ROUTE
C-Type
2 P2MP_SECONDARY_RECORD_ROUTE C-Type
20.3. New Error Codes
Four new Error Codes are defined for use with the Error Value "Rout-
ing Problem". IANA is requested to assign values.
The Error Code "Unable to Branch" indicates that a P2MP branch cannot The Error Code "Unable to Branch" indicates that a P2MP branch cannot
be formed by the reporting LSR. be formed by the reporting LSR. IANA is requested to assign value 20
to this Error Code.
The Error Code "Unsupported LSP Integrity" indicates that a P2MP The Error Code "Unsupported LSP Integrity" indicates that a P2MP
branch does not support the requested LSP integrity function. branch does not support the requested LSP integrity function. IANA is
requested to assign value 21 to this Error Code.
21.3. LSP Attributes Flags The Error Code "P2MP Remerge Detected" indicates that a node has
detected remerge. IANA is requested to assign value 22 to this Error
Code.
20.4. LSP Attributes Flags
IANA has been asked to manage the space of flags in the Attibutes IANA has been asked to manage the space of flags in the Attibutes
Flags TLV carried in the LSP_ATTRIBUTES Object [LSP-ATTRIB]. This Flags TLV carried in the LSP_ATTRIBUTES Object [LSP-ATTRIB]. This
document defines two new flags as follows: document defines two new flags as follows:
Suggested Bit Number: 3 Suggested Bit Number: 3
Meaning: LSP Integrity Required Meaning: LSP Integrity Required
Used in Attributes Flags on Path: Yes Used in Attributes Flags on Path: Yes
Used in Attributes Flags on Resv: No Used in Attributes Flags on Resv: No
Used in Attributes Flags on RRO: No Used in Attributes Flags on RRO: No
Referenced Section of this Document: 12 Referenced Section of this Doc: 10
Suggested Bit Number: 4
Meaning: Branch Reoptimization Allowed
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 Document: TBD
22. Security Considerations 21. Security Considerations
This document does not introduce any new security issues. The This document does not introduce any new security issues. The secu-
security issues identified in [RFC3209] and [RFC3473] are still rity issues identified in [RFC3209] and [RFC3473] are still relevant.
relevant.
23. Acknowledgements 22. Acknowledgements
This document is the product of many people. The contributors are This document is the product of many people. The contributors are
listed in Section 25. listed in Section 27.2.
Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger and Nischal Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger and Nischal
Sheth for their suggestions and comments. Thanks also to Dino Sheth for their suggestions and comments. Thanks also to Dino Farni-
Farninacci for his comments. nacci for his comments.
24. Example P2MP LSP Establishment 23. Appendix
Following is one example of setting up a P2MP LSP Tunnel using the 23.1. Example
procedures described in this document.
Following is one example of setting up a P2MP LSP using the proce-
dures described in this document.
Source 1 (S1) Source 1 (S1)
| |
PE1 PE1
| | | |
|L5 | |L5 |
P3 | P3 |
| | | |
L3 |L1 |L2 L3 |L1 |L2
R2----PE3--P1 P2---PE2--Receiver 1 (R1) R2----PE3--P1 P2---PE2--Receiver 1 (R1)
skipping to change at page 39, line 22 skipping to change at page 42, line 22
e) PE1 establishes the S2L sub-LSP to PE3 along <PE1, P3, P1, PE3> e) PE1 establishes the S2L sub-LSP to PE3 along <PE1, P3, P1, PE3>
f) PE1 computes the P2P path to reach PE4 when it discovers PE4. This 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- path is computed to share the same links where possible with the sub-
LSPs to PE2 and PE3 as they belong to the same P2MP session. LSPs to PE2 and PE3 as they belong to the same P2MP session.
g) PE1 signals the Path message for PE4 sub-LSP along <PE1, P3, P1, g) PE1 signals the Path message for PE4 sub-LSP along <PE1, P3, P1,
PE4> PE4>
e) P1 receives a Resv message from PE4 with label L4. It had e) P1 receives a Resv message from PE4 with label L4. It had previ-
previously received a Resv message from PE3 with label L3. It had ously received a Resv message from PE3 with label L3. It had allo-
allocated a label L1 for the sub-LSP to PE3. It uses the same label cated a label L1 for the sub-LSP to PE3. It uses the same label and
and sends the Resv messages to P3. Note that it may send only one sends the Resv messages to P3. Note that it may send only one Resv
Resv message with multiple flow descriptors in the flow descriptor message with multiple flow descriptors in the flow descriptor list.
list. If this is the case and FF style is used, the FF flow If this is the case and FF style is used, the FF flow descriptor will
descriptor will contain the S2L sub-LSP descriptor list with two contain the S2L sub-LSP descriptor list with two entries: one for PE4
entries: one for PE4 and the other for PE3. For SE style, the SE and the other for PE3. For SE style, the SE filter spec will contain
filter spec will contain this S2L sub-LSP descriptor list. P1 also this S2L sub-LSP descriptor list. P1 also creates a label mapping of
creates a label mapping of (L1 -> {L3, L4}). P3 uses the existing (L1 -> {L3, L4}). P3 uses the existing label L5 and sends the Resv
label L5 and sends the Resv message to PE1, with label L5. It reuses message to PE1, with label L5. It reuses the label mapping of {L5 ->
the label mapping of {L5 -> L1}. L1}.
25. References 24. References
25.1. Normative References 24.1. Normative References
[LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized [LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt. MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, work in
progress.
[LSP-ATTR] A. Farrel, et. al. , "Encoding of [LSP-ATTR] A. Farrel, et. al. , "Encoding of
Attributes for Multiprotocol Label Switching (MPLS) Attributes for Multiprotocol Label Switching (MPLS)
Label Switched Path (LSP) Establishment Using RSVP-TE", Label Switched Path (LSP) Establishment Using RSVP-TE",
draft-ietf-mpls-rsvpte-attributes-03.txt, March 2004, draft-ietf-mpls-rsvpte-attributes-05.txt, March 2004,
work in progress. work in progress.
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan,
G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC3209, December 2001 RFC3209, December 2001, work in progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997, work in
progress.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1, "Resource ReSerVation Protocol (RSVP) -- Version 1,
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997, work in
progress.
[RFC3471] Lou Berger, et al., "Generalized MPLS - Signaling Functional [RFC3471] Lou Berger, et al., "Generalized MPLS - Signaling Functional
Description", RFC 3471, January 2003 Description", RFC 3471, January 2003, work in progress.
[RFC3473] L. Berger et.al., "Generalized MPLS Signaling - RSVP-TE [RFC3473] L. Berger et.al., "Generalized MPLS Signaling - RSVP-TE
Extensions", RFC 3473, January 2003. Extensions", RFC 3473, January 2003, work in progress.
[RFC2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, [RFC2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi,
S. Molendini, "RSVP Refresh Overhead Reduction Extensions", S. Molendini, "RSVP Refresh Overhead Reduction Extensions",
RFC 2961, April 2001. RFC 2961, April 2001, work in progress.
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001, work in
progress.
[RSVP-FRR] P. Pan, G. Swallow, A. Atlas (Editors), "Fast Reroute Extensions [RFC4090] P. Pan, G. Swallow, A. Atlas (Editors), "Fast Reroute Extensions
to RSVP-TE for LSP Tunnels", to RSVP-TE for LSP Tunnels", work in progress.
draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt.
[P2MP-REQ] S. Yasukawa, et. al., "Requirements for Point-to-Multipoint [RFC3477] K. Kompella, Y. Rekther, "Signalling Unnumbered Links in
capability extension to MPLS", Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)",
draft-ietf-mpls-p2mp-sig-requirement-00.txt. work in progress .
25.2. Informative References [P2MP-REQ] S. Yasukawa, Editor "Signaling Requirements for
Point-to-Multipoint Traffic Engineered MPLS LSPs",
draft-ietf-mpls-p2mp-sig-requirement-02.txt, work in progress.
[RECOVERY] "GMPLS Based Segment Recovery",
draft-ietf-ccamp-gmpls-segment-recovery-02.txt
24.2. Informative References
[BFD] D. Katz, D. Ward, "Bidirectional Forwarding Detection", [BFD] D. Katz, D. Ward, "Bidirectional Forwarding Detection",
draft-katz-ward-bfd-01.txt. draft-katz-ward-bfd-01.txt, work in progress.
[BFD-MPLS] R. Aggarwal, K. Kompella, "BFD for MPLS LSPs", [BFD-MPLS] R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow, "BFD for MPLS
draft-raggarwa-mpls-bfd-00.txt LSPs", draft-ietf-bfd-mpls-00.txt, work in progress.
[IPR-1] Bradner, S., "IETF Rights in Contributions", BCP 78, [IPR-1] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004. RFC 3667, February 2004, work in progress.
[IPR-2] Bradner, S., Ed., "Intellectual Property Rights in IETF [IPR-2] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. Technology", BCP 79, RFC 3668, February 2004, work in progress.
[INT-REG] JP Vasseur, A. Ayyangar, "Inter-area and Inter-AS MPLS Traffic [INT-REG] JP Vasseur, A. Ayyangar, "Inter-area and Inter-AS MPLS Traffic
Engineering", draft-vasseur-ccamp-inter-area-as-te-00.txt. Engineering", draft-vasseur-ccamp-inter-area-as-te-00.txt,
work in progress.
[RFC2209] R. Braden, L. Zhang, "Resource Reservation Protocol (RSVP) [RFC2209] R. Braden, L. Zhang, "Resource Reservation Protocol (RSVP)
Version 1 Message Processing Rules", RFC 2209. Version 1 Message Processing Rules", RFC 2209, work in progress.
[RFC3477] K. Kompella, Y. Rekther, "Signalling Unnumbered Links in [LSP-STITCH] A. Ayyanger, J.P. Vasseur, "Label Switched Path Stitching
Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)". with Generalized MPLS Traffic Engineering",
draft-ietf-ccamp-lsp-stitching-00.txt, April 2005
work in progress
26. Author Information [TE-NODE-CAP] JP Vasseur, JL Le Roux, et al. "Routing extensions for
discovery of Traffic Engineering Node Capabilities",
draft-vasseur-ccamp-te-node-cap-00.txt, February 2005,
work in progress
26.1. Editor Information 25. Author Information
25.1. Editor Information
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: rahul@juniper.net Email: rahul@juniper.net
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
9-11, Midori-Cho 3-Chome 9-11, Midori-Cho 3-Chome
skipping to change at page 41, line 35 skipping to change at page 45, line 5
Phone: +81 422 59 4769 Phone: +81 422 59 4769
EMail: yasukawa.seisho@lab.ntt.co.jp EMail: yasukawa.seisho@lab.ntt.co.jp
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel Alcatel
Francis Wellesplein 1, Francis Wellesplein 1,
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be Email: Dimitri.Papadimitriou@alcatel.be
26.2. Contributor Information 25.2. Contributor Information
John Drake John Drake
Calient Networks Calient Networks
Email: jdrake@calient.net Email: jdrake@calient.net
Alan Kullberg Alan Kullberg
Motorola Computer Group Motorola Computer Group
120 Turnpike Road 1st Floor 120 Turnpike Road 1st Floor
Southborough, MA 01772 Southborough, MA 01772
EMail: alan.kullberg@motorola.com EMail: alan.kullberg@motorola.com
skipping to change at page 44, line 7 skipping to change at page 47, line 21
Phone: +44 0 1978 860944 Phone: +44 0 1978 860944
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
E-mail: jeanlouis.leroux@francetelecom.com E-mail: jeanlouis.leroux@francetelecom.com
27. Intellectual Property 26. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any assur-
assurances of licenses to be made available, or the result of an ances of licenses to be made available, or the result of an attempt
attempt made to obtain a general license or permission for the use of made to obtain a general license or permission for the use of such
such proprietary rights by implementers or users of this proprietary rights by implementers or users of this specification can
specification can be obtained from the IETF on-line IPR repository at be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
28. Full Copyright Statement 27. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUNG BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
29. Acknowledgement 28. Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/