wdiff draft-ietf-mpls-rsvp-te-p2mp-02.txt draft-ietf-mpls-rsvp-te-p2mp-03.txt

Network Working Group R. Aggarwal (Editor)
Internet Draft Juniper Networks
Expiration Date: January April 2006
D. Papadimitriou (Editor)
Alcatel

S. Yasukawa (Editor)
NTT

July

October 2005

Extensions to RSVP-TE for Point to Multipoint TE LSPs

draft-ietf-mpls-rsvp-te-p2mp-02.txt

draft-ietf-mpls-rsvp-te-p2mp-03.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document describes extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for the setup of Traffic Engineered
(TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-
Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
networks. The solution relies on RSVP-TE without requiring a
multicast routing protocol in the Service Provider core. Protocol
elements and procedures for this solution are described. There can be
various applications for P2MP TE LSPs such as IP multicast.
Specification of how such applications will use a P2MP TE LSP is
outside the scope of this document.

Table of Contents

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
8.1 Notify Messages ....................................... 21
8.2 ResvConf Messages ..................................... 22
9 Refresh Reduction ..................................... 21 23
10 State Management ...................................... 22 23
10.1 Incremental State Update .............................. 22 23
10.2 Combining Multiple Path Messages ...................... 23 24
11 Error Processing ...................................... 24 25
11.1 PathErr Messages ...................................... 24 25
11.2 ResvErr Messages ...................................... 24 26
11.3 Branch Failure Handling ............................... 25 26
12 Admin Status Change ................................... 26 27

13 Label Allocation on LANs with Multiple Downstream Nodes ...26 Nodes. 28
14 P2MP LSP and Sub-LSP Re-optimization .................. 26 28
14.1 Make-before-break ..................................... 27 28
14.2 Sub-Group Based Re-optimization ....................... 27 28
15 Fast Reroute .......................................... 27 29
15.1 Facility Backup ....................................... 28 29
15.2 One to One Backup ..................................... 29 30
16 Support for LSRs that are not P2MP Capable ............ 29 30
17 Reduction in Control Plane Processing with LSP Hierarchy ..31 Hierarchy. 32
18 P2MP LSP Remerging and Cross-Over ..................... 31 32
18.1 Procedures ............................................ 33
18.1.1 Re-Merge Procedures ................................... 34
19 New and Updated Message Objects ....................... 34 36
19.1 SESSION Object ........................................ 34 36
19.1.1 P2MP LSP Tunnel IPv4 SESSION Object ................... 34 36
19.1.2 P2MP LSP Tunnel IPv6 SESSION Object ................... 35 37
19.2 SENDER_TEMPLATE object ................................ 35 37
19.2.1 P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object ........... 35 38
19.2.2 P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object ........... 36 39
19.3 S2L SUB-LSP <S2L_SUB_LSP> Object .................................... 37 .................................. 40
19.3.1 S2L SUB-LSP <S2L_SUB_LSP> IPv4 Object ............................... 37 ............................. 40
19.3.2 S2L SUB-LSP <S2L_SUB_LSP> IPv6 Object ............................... 38 ............................. 40
19.4 FILTER_SPEC Object .................................... 38 40
19.4.1 P2MP LSP_IPv4 FILTER_SPEC Object ...................... 38 41
19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object ...................... 38 41
19.5 P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) ........... 38 41
19.6 P2MP_SECONDARY_RECORD_ROUTE P2MP SECONDARY_RECORD_ROUTE Object (SRRO) ............. 39 41
20 IANA Considerations ................................... 39 41
20.1 New Class Numbers ..................................... 39 41
20.2 New Class Types ....................................... 39 42
20.3 New Error Codes ....................................... 40 42
20.4 LSP Attributes Flags .................................. 40 43
21 Security Considerations ............................... 41 43
22 Acknowledgements ...................................... 41 43
23 Appendix .............................................. 41 43
23.1 Example ............................................... 41 43
24 References ............................................ 42 45
24.1 Normative References .................................. 42 45
24.2 Informative References ................................ 43 46
25 Author Information .................................... 44 47
25.1 Editor Information .................................... 44 47
25.2 Contributor Information ............................... 45 47
26 Intellectual Property ................................. 47 50
27 Full Copyright Statement .............................. 48 50
28 Acknowledgement ....................................... 48 51

1. Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS].

2. Terminology

This document uses terminologies defined in [RFC3031], [RFC2205],
[RFC3209], [RFC3473] and [P2MP-REQ].

3. Introduction

[RFC3209] defines a mechanism for setting up P2P TE LSPs in MPLS net-
works.
networks. [RFC3473] defines extensions to [RFC3209] for setting up P2P
TE LSPs in GMPLS networks. However these specifications do not pro-
vide
provide a mechanism for building P2MP TE LSPs.

This document defines extensions to RSVP-TE protocol [RFC3209,
RFC3473] to support P2MP TE LSPs satisfying the set of requirements
described in [P2MP-REQ].

This document relies on the semantics of RSVP that RSVP-TE inherits
for building P2MP LSPs. A P2MP LSP is comprised of multiple S2L sub-
LSPs.
sub-LSPs. These S2L sub-LSPs are set up between the ingress and egress
LSRs and are appropriately combined by the branch LSRs using RSVP
semantics to result in a P2MP TE LSP. One Path message may signal one
or multiple S2L sub-LSPs. Hence the S2L sub-LSPs belonging to a P2MP
LSP can be signaled using one Path message or split across multiple
Path messages.

Path computation and P2MP application specific aspects are outside of
the scope of this document.

4. Mechanism

This document describes a solution that optimizes data replication by
allowing non-ingress nodes in the network to be replication/branch
nodes. A branch node is a LSR that is capable of replicating the
incoming data on two or more outgoing interfaces. The solution uses relies
on RSVP-TE in the core of the network for setting up a P2MP TE LSP.

The P2MP TE LSP is set up by associating multiple S2L TE sub-LSPs and
relying on data replication at branch nodes. This is described fur-
ther
further in the following sub-sections by describing P2MP Tunnels and
how they relate to S2L sub-LSPs.

4.1. P2MP Tunnels

The specific aspect related to P2MP TE LSP is the action required at
a branch node, where data replication occurs. For instance, in the Incoming MPLS case, incoming labeled
data is appropriately replicated to sev-
eral several outgoing interfaces which
may have different labels.

A P2MP TE Tunnel comprises of one or more P2MP LSPs. A P2MP TE Tunnel
is identified by a P2MP SESSION object. This object contains the
identifier of the P2MP Session which includes the P2MP ID, a tunnel
ID and an extended tunnel ID.

The fields of a P2MP SESSION object are identical to those of the
SESSION object defined in [RFC3209] except that the Tunnel Endpoint
Address field is replaced by the P2MP Identifier (P2MP ID) field.

The P2MP ID provides an identifier for the set of destinations of the
P2MP TE Tunnel.

4.2. P2MP LSP

A P2MP LSP is identified by the combination of the P2MP ID, Tunnel
ID, and Extended Tunnel ID that are part of the P2MP SESSION object,
and the tunnel sender address and LSP ID fields of the P2MP
SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is
defined in section 20.2.

4.3. Sub-Groups

As with all other RSVP controlled LSPs, P2MP LSP state is managed
using RSVP messages. While use of RSVP messages is the same, P2MP LSP
state differs from P2P LSP state in a number of ways. The two most
notable differences are that a P2MP LSP comprises multiple S2L Sub-
LSPs
Sub-LSPs and that, as a result of this, it may not be possible to repre-
sent
represent full state in a single IP datagram packet and even more likely that it
can't fit into a single IP packet. It must also be possible to effi-
ciently
efficiently add and remove endpoints to and from P2MP TE LSPs. An addi-
tional
additional issue is that P2MP LSP must also handle the state "remerge"
problem, see [P2MP-REQ].

These differences in P2MP state are addressed through the addition of
a sub-group identifier (Sub-Group ID) and sub-group originator (Sub-
Group
(Sub-Group Originator ID) to the SENDER_TEMPLATE and FILTER_SPEC
objects. Taken together the Sub-Group ID and Sub-Group Originator ID
are referred to as the Sub-Group fields.

The Sub-Group fields, together with rest of the SENDER_TEMPLATE and
SESSION objects, are used to represent a portion of a P2MP LSP's
state. This portion of a P2MP LSP's state refers only to signaling
state and not data plane replication or branching. For example, it is
possible for a node to "branch" signaling state for a P2MP LSP, but
to not branch the data associated with the P2MP LSP. Typical applica-
tions
applications for generation and use of multiple subgroups are adding
an egress and semantic fragmentation to ensure that a Path message
remains within a single IP packet.

4.4. S2L Sub-LSPs

A P2MP LSP is constituted of one or more S2L sub-LSPs.

4.4.1. Representation of a S2L Sub-LSP

A S2L sub-LSP exists within the context of a P2MP LSP. Thus it is
identified by the P2MP ID, Tunnel ID, and Extended Tunnel ID that are
part of the P2MP SESSION, the tunnel sender address and LSP ID fields
of the P2MP SENDER_TEMPLATE object, and the S2L sub-LSP destination
address that is part of the S2L_SUB_LSP <S2L_SUB_LSP> object. The S2L_SUB_LSP <S2L_SUB_LSP>
object is defined in section 20.3.

An EXPLICIT_ROUTE Object (ERO) or P2MP SECONDARY_EXPLICIT_ROUTE
Object (SERO) is used to optionally specify the explicit route of a
S2L sub-LSP. Each ERO or a SERO that is signaled corresponds to a
particular S2L_SUB_LSP <S2L_SUB_LSP> object. Details of explicit route encoding
are specified in section 4.5. The SECONDARY_EXPLICIT_ROUTE Object is
defined in [RECOVERY], a new P2MP SECONDARY_EXPLICIT_ROUTE Object C-
type
C-type is defined in Section 20.5 and a matching P2MP SEC-
ONDARY_RECORD_ROUTE
SECONDARY_RECORD_ROUTE Object C-type is defined in Section 20.6.

4.4.2. S2L Sub-LSPs and Path Messages

The mechanism in this document allows a P2MP LSP to be signaled using
one or more Path messages. Each Path message may signal one or more
S2L sub-LSPs. Support for multiple Path messages is desirable as one
Path message may not be large enough to fit all the S2L sub-LSPs; and
they also allow separate manipulation of sub-trees of the P2MP LSP.
The reason for allowing a single Path message, to signal multiple S2L
sub-LSPs, is to optimize the number of control messages needed to
setup a P2MP LSP.

4.5. Explicit Routing

When a Path message signals a single S2L sub-LSP (that is, the Path
message is only targeting a single leaf in the P2MP tree), the
EXPLICIT_ROUTE object encodes the path from the ingress LSR to the
egress LSR. The Path message also includes the S2L_SUB_LSP <S2L_SUB_LSP> object
for the S2L sub-LSP being signaled. The < [<EXPLICIT_ROUTE>],
<S2L_SUB_LSP> > tuple represents the S2L sub-LSP and is referred to
as the sub-LSP descriptor. The absence of the ERO should be inter-
preted
interpreted as requiring hop-by-hop routing for the sub-LSP based on
the S2L sub-LSP destination address field of the S2L_SUB_LSP <S2L_SUB_LSP> object.

When a Path message signals multiple S2L sub-LSPs the path of the
first S2L sub-LSP, from the ingress LSR to the egress LSR, is encoded
in the ERO. The first S2L sub-LSP is the one that corresponds to the
first S2L_SUB_LSP <S2L_SUB_LSP> object in the Path message. The S2L sub-LSPs corre-
sponding
coresponding to the S2L_SUB_LSP <S2L_SUB_LSP> objects that follow are termed as subse-
quent
subsequent S2L sub-LSPs. One approach In order to encode avoid the explicit route potential repetition
of a
subsequent S2L sub-LSP is to include all the hops from the ingress to path information for the egress parts of the S2L sub-LSP. However this implies potential repeti-
tion of hops sub-LSPs that can be learned share hops,
this information is deduced from the ERO or explicit routes of other S2L sub-LSPs. Explicit
sub-LSPs using explicit route compression using SEROs attempts
to minimize such repetition. in SEROs.

The path of each subsequent S2L sub-LSP is encoded in a P2MP SEC-
ONDARY_EXPLICIT_ROUTE
SECONDARY_EXPLICIT_ROUTE object (SERO). The format of the SERO is the
same as an ERO (as defined in [RFC3209]). Each subsequent S2L sub-LSP
is represented by tuples of the form < [<P2MP SEC-
ONDARY_EXPLICIT_ROUTE>] <S2L_SUB_LSP> >. There is a one to one corre-
spondence
correspondence between a S2L_SUB_LSP <S2L_SUB_LSP> object and a SERO. A SERO for a par-
ticular
particular S2L sub-LSP includes only the path from a certain branch
LSR to the egress LSR if the path to that branch LSR can be derived
from the ERO or other SEROs. The absence of a SERO should be
interpreted as requiring hop-by-hop routing for that S2L sub-LSP. Note
that the destination address is carried in the S2L sub-LSP object.
The encod-
ing encoding of the SERO and S2L sub-LSP <S2L_SUB_LSP> object are described in
detail in section 20.

Explicit route compression is illustrated using the following figure.

A
|
|
B
|
|
C----D----E
| | |
| | |
F G H-------I
| |\ |
| | \ |
J K L M
| | | |
| | | |
N O P Q--R

Figure 1. Explicit Route Compression

Figure 1. shows a P2MP LSP with LSR A as the ingress LSR and six
egress LSRs: (F, N, O, P, Q and R). When all the six S2L sub-LSPs are
signaled in one Path message let us assume that the S2L sub-LSP to
LSR F is the first S2L sub-LSP and the rest are subsequent S2L sub-
LSPs.
sub-LSPs. Following is one way for the ingress LSR A to encode the S2L
sub-LSP explicit routes using compression:

S2L sub-LSP-F: ERO = {B, E, D, C, F}, S2L_SUB_LSP Object-F <S2L_SUB_LSP> object-F
S2L sub-LSP-N: SERO = {D, G, J, N}, S2L_SUB_LSP Object-N <S2L_SUB_LSP> object-N
S2L sub-LSP-O: SERO = {E, H, K, O}, S2L_SUB_LSP Object-O <S2L_SUB_LSP> object-O
S2L sub-LSP-P: SERO = {H, L, P}, S2L_SUB_LSP Object-P, <S2L_SUB_LSP> object-P,
S2L sub-LSP-Q: SERO = {H, I, M, Q}, S2L_SUB_LSP Object-Q, <S2L_SUB_LSP> object-Q,
S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP Object-R, <S2L_SUB_LSP> object-R,

After LSR E processes the incoming Path message from LSR B it sends a
Path message to LSR D with the S2L sub-LSP explicit routes encoded as
follows:

S2L sub-LSP-F: ERO = {D, C, F}, S2L_SUB_LSP Object-F <S2L_SUB_LSP> object-F
S2L sub-LSP-N: SERO = {D, G, J, N}, S2L_SUB_LSP Object-N <S2L_SUB_LSP> object-N

LSR E also sends a Path message to LSR H and following is one way to
encode the S2L sub-LSP explicit routes using compression:

S2L sub-LSP-O: ERO = {H, K, O}, S2L_SUB_LSP Object-O <S2L_SUB_LSP> object-O
S2L sub-LSP-P: SERO = {H, L, P}, S2L_SUB_LSP Object-P, object-P,
S2L sub-LSP-Q: SERO = {H, I, M, Q}, S2L_SUB_LSP Object-Q, <S2L_SUB_LSP> object-Q,
S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP Object-R, <S2L_SUB_LSP> object-R,

After LSR H processes the incoming Path message from E it sends a
Path message to LSR K, LSR L and LSR I. The encoding for the Path
message to LSR K is as follows:

S2L sub-LSP-O: ERO = {K, O}, S2L_SUB_LSP Object-O <S2L_SUB_LSP> object-O

The encoding of the Path message sent by LSR H to LSR L is as fol-
lows:
follows:

S2L sub-LSP-P: ERO = {L, P}, S2L_SUB_LSP Object-P, <S2L_SUB_LSP> object-P,

Following is one way for LSR H to encode the S2L sub-LSP explicit
routes in the Path message sent to LSR I:

S2L sub-LSP-Q: ERO = {I, M, Q}, S2L_SUB_LSP Object-Q, <S2L_SUB_LSP> object-Q,
S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP Object-R, <S2L_SUB_LSP> object-R,

The explicit route encodings in the Path messages sent by LSRs D and
Q are left as an exercise to the reader.

This compression mechanism reduces the Path message size. It also
reduces extra processing that can result if explicit routes are
encoded from ingress to egress for each S2L sub-LSP. No assumptions
are placed on the ordering of the subsequent S2L sub-LSPs and hence
on the ordering of the SEROs in the Path message. All LSRs need to
process the ERO corresponding to the first S2L sub-LSP. A LSR needs
to process a S2L sub-LSP descriptor for a subsequent S2L sub-LSP only
if the first hop in the corresponding SERO is a local address of that
LSR. The branch LSR that is the first hop of a SERO propagates the
corresponding S2L sub-LSP downstream.

5. Path Message

5.1. Path Message Format

This section describes modifications made to the Path message format
as specified in [RFC3209] and [RFC3473]. The Path message is enhanced
to signal one or more S2L sub-LSPs. This is done by including the S2L
sub-LSP descriptor list in the Path message as shown below.

<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[<S2L sub-LSP descriptor list>]
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> [ <P2MP SEC-
ONDARY_EXPLICIT_ROUTE> ]

Each LSR MUST use the common objects in the Path message and the S2L
sub-LSP descriptors to process each S2L sub-LSP represented by the
S2L sub-LSP
<S2L_SUB_LSP> object and the SUB-/EXPLICIT_ROUTE SECONDARY-/EXPLICIT_ROUTE object
combination.

The first S2L_SUB_LSP <S2L_SUB_LSP> object's explicit route is specified by the
ERO. Explicit routes of subsequent S2L sub-LSPs are specified by the
corresponding SERO. A SERO corresponds to the following S2L_SUB_LSP <S2L_SUB_LSP>
object.

The RRO in the sender descriptor contains the hops traversed by the
Path message and applies to all the S2L sub-LSPs signaled in the Path
message.

Path message processing is described in the next section.

5.2. Path Message Processing

The ingress-LSR initiates the set up of a S2L sub-LSP to each egress- egress
LSR that is the destination of the P2MP LSP. Each S2L sub-LSP is
associated with the same P2MP LSP using common P2MP SESSION object
and <Source <Sender Address, LSP-ID> fields in the P2MP SENDER_TEMPLATE
object. Hence it can be combined with other S2L sub-LSPs to form a
P2MP LSP. Another S2L sub-LSP belonging to the same instance of this
S2L sub-LSP (i.e. the same P2MP LSP) shares resources with this S2L
sub-LSP. The session corresponding to the P2MP TE tunnel is deter-
mined
determined based on the P2MP SESSION object. Each S2L sub-LSP is identi-
fied
identified using the S2L_SUB_LSP <S2L_SUB_LSP> object. Explicit routing for the S2L sub-
LSPs
sub-LSPs is achieved using the ERO and SEROs.

As mentioned earlier, it is possible to signal S2L sub-LSPs for a
given P2MP LSP in one or more Path messages. And a given Path message
can contain one or more S2L sub-LSPs. 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.

5.2.1. Multiple Path Messages

As described in section 3, either the <EXPLICIT_ROUTE> <S2L SUB-LSP> <S2L_SUB_LSP>
or the <P2MP SECONDARY_EXPLICIT_ROUTE> <S2L_SUB_LSP> tuple is used to
specify a S2L sub-LSP. Multiple Path messages can be used to signal a
P2MP LSP. Each Path message can signal one or more S2L sub-LSPs. If a
Path message contains only one S2L sub-LSP, each LSR along the S2L
sub-LSP follows [RFC3209] procedures for processing the Path message
besides the S2L SUB-LSP <S2L_SUB_LSP> object processing described in this document. docu-
ment.

Processing of Path messages containing more than one S2L sub-LSP is
described in Section 5.2.2.

An ingress LSR may use multiple Path messages for signaling a P2MP
LSP. This may be because a single Path message may not be large
enough to signal the P2MP LSP. Or it may be while adding leaves to
the P2MP LSP the new leaves are signaled in a new Path message. Or an
ingress LSR MAY choose to break the P2MP tree into separate manage-
able
manageable P2MP trees. These trees share the same root and may share the
trunk and certain branches. The scope of this management decomposi-
tion
decomposition of P2MP trees is bounded by a single tree (the P2MP Tree)
and multiple trees with a single leaf each (S2L sub-LSPs). Per [P2MP-
REQ],
[P2MP-REQ], a P2MP LSP MUST have consistent attributes across all
portions of a tree. This implies that each Path message that is used
to signal a P2MP LSP is signaled using the same signaling attributes
with the exception of the S2L sub-LSP information.

The resulting sub-LSPs from the different Path messages belonging to
the same P2MP LSP SHOULD share labels and resources where they share
hops to prevent multiple copies of the data being sent.

In certain cases a transit LSR may need to generate multiple Path
messages to signal state corresponding to a single received Path mes-
sage.
message. For instance ERO expansion may result in an overflow of the
resultant Path message. In this case the message can be decomposed
into multiple Path messages such that each of the messages carry a
subset of the X2L sub-tree carried by the incoming message.

Multiple Path messages generated by a LSR that signal state for the
same P2MP LSP are signaled with the same SESSION object and have the
same <Source address, LSP-ID> in the SENDER_TEMPLATE object. In order
to disambiguate these Path messages a <Sub-Group Originator ID, sub-
Group
sub-Group ID> tuple is introduced (also referred to as the Sub-Group
field) and encoded in the SENDER_TEMPLATE object. Multiple Path mes-
sages
messages generated by a LSR to signal state for the same P2MP LSP
have the same Sub-Group Originator ID and have a different sub-Group
ID. The Sub-Group Originator ID SHOULD be set to the TE Router ID of
the LSR that originates the Path message. This is either the ingress
LSR or a LSR which re-originates the Path message with its own Sub-Group
Originator ID. Cases when a transit LSR may change the Sub-Group
Originator ID of an incoming Path message are described below. The
<Sub-Group Originator ID, sub-Group ID> tuple is globally unique. The
sub-Group ID space is specific to the Sub-Group Originator ID. There-
fore
Therefore the combination <Sub-Group Originator ID, sub-Group ID> is net-
work-wide
network-wide unique. Also, a router that changes the Sub-Group origina-
tor
originator ID of an incoming Path message MUST use the same value of
the Sub-Group Originator ID for all outgoing Path messages, for a partic-
ular
particular P2MP LSP, and SHOULD not vary it during the life of the
P2MP LSP.

5.2.2. Multiple S2L Sub-LSPs in one Path message

The S2L sub-LSP descriptor list allows the signaling of one or more
S2L sub-LSPs in one Path message. It is possible to signal multiple
S2L sub-LSP
<S2L_SUB_LSP> object and ERO/SERO combinations in a single Path mes-
sage. Note that these two objects are the ones that differentiate a
S2L sub-LSP.

All LSRs MUST process the ERO corresponding to the first S2L sub-LSP
when the ERO is present. If one or more SEROs are present an ERO MUST
be present. The first S2L sub-LSP MUST be propagated in a Path mes-
sage
message by each LSR along the explicit route specified by the ERO. A
LSR MUST process a S2L sub-LSP descriptor for a subsequent S2L sub-LSP
only if the first hop in the corresponding SERO is a local address of
that LSR. If this is not the case the S2L sub-LSP descriptor MUST be
included in the Path message sent to LSR that is the next hop to
reach the first hop in the SERO. This next hop is determined by using
the ERO or other SEROs that encode the path to the SERO's first hop.
If this is the case and the LSR is also the egress, the S2L sub-LSP
descriptor MUST NOT be propagated downstream. If this is the case and
the LSR is not the egress the S2L sub-LSP descriptor MUST be included
in a Path message sent to the next-hop determined from the SERO.
Hence a branch LSR MUST only propagate the relevant S2L sub-LSP
descriptors on each downstream link. A S2L sub-LSP descriptor list
that is propagated on a downstream link MUST only contain those S2L
sub-LSPs that are routed using that link. This processing MAY result
in a subsequent S2L sub-LSP in an incoming Path message to become the
first S2L sub-LSP in an outgoing Path message.

Note that if one or more SEROs contain loose hops, expansion of such
loose hops MAY result in overflowing the Path message size. Section
5.2.3 describes how signaling of the set of S2L sub-LSPs can be split
in more than one Path message.

The Record Route RECORD_ROUTE Object (RRO) contains the hops traversed by the Path
message and applies to all the S2L sub-LSPs signaled in the path mes-
sage.
message. A transit LSR MUST append its address in an incoming RRO and
propagate it downstream. A branch LSR MUST form a new RRO for each of
the outgoing Path messages. Each such updated RRO MUST be formed
using the rules in [RFC3209].

If a LSR is unable to support a S2L sub-LSP in a Path message, a
PathErr message MUST be sent for the impacted S2L sub-LSP, and normal
processing of the rest of the P2MP LSP SHOULD continue. The default
behavior is that the remainder of the LSP is not impacted (that is,
all other branches are allowed to set up) and the failed branches are
reported in PathErr messages in which the Path_State_Removed flag
MUST NOT be set. However, the ingress LSR may set a LSP Integrity
flag to request that if there is a setup failure on any branch the
entire LSP should fail to set up. This is described further in sec-
tion
section 12.

5.2.3. Transit Fragmentation

In certain cases a transit LSR may need to generate multiple Path
messages to signal state corresponding to a single received Path mes-
sage.
message. For instance ERO expansion may result in an overflow of the
resultant Path message. It is desirable not to rely on IP fragmenta-
tion
fragmentation in this case. In order to achieve this, the multiple Path mes-
sages
messages generated by the transit LSR, are signaled with the Sub-Group
Originator ID set to the TE Router ID of the transit LSR and a dis-
tinct sub-Group ID. Thus each distinct Path message that is generated
by the transit LSR for the P2MP LSP carries a distinct <Sub-Group
Originator ID, Sub-Group ID> tuple.

When multiple Path messages are used by an ingress or transit node,
each Path message SHOULD be identical with the exception of the S2L
sub-LSP related information (e.g., SERO), message and hop information
(e.g., INTEGRITY, MESSAGE_ID and RSVP_HOP), and the sub-group fields
of the SENDER_TEMPLATE objects. Except when performing a make-
before-break operation, operation as specified in section 14.1, the tunnel
sender address and LSP ID fields MUST be the same in each message,
and for transit nodes, the same as the values in the received Path
message.

As described above one case in which the Sub-Group Originator ID of a
received Path message is changed is that of transit fragmentation.
The
Another case is when 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 orig-
inating originating the Path message based on a local policy. For
instance a LSR may decide to always change the Sub-Group Originator
ID while per-
forming performing ERO expansion. The Sub-Group ID MUST not be
changed if the Sub-Group Originator ID is not being changed.

5.2.4. Control of Branch Fate Sharing

An ingress LSR can control the behavior of an LSP if there is a fail-
ure
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 to fail.

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.

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 message carrying the error "Routing Error"/"Unsupported LSP
Integrity"

5.3. Grafting

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
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 FF flow descriptor and SE filter spec are modified as follows to
identify the S2L sub-LSPs that they correspond to:

<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ] [ <S2L sub-LSP descriptor
list> ]

<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <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>
SECONDARY_EXPLICIT_ROUTE> ]
FILTER_SPEC is defined in section 20.4.

The S2L sub-LSP descriptor has the same format as in section 4.1 with
the difference that a P2MP_SECONDARY_RECORD_ROUTE object is used in
place of a P2MP SECONDARY_EXPLICIT_ROUTE object. The P2MP_SEC-
ONDARY_RECORD_ROUTE objects follow the same compression mechanism as
the P2MP SECONDARY_EXPLICIT_ROUTE objects. Note that that a Resv mes-
sage
message can signal multiple S2L sub-LSPs that may belong to the same
FILTER_SPEC object or different FILTER_SPEC objects. The same label
SHOULD be allocated if the <Source <Sender Address, LSP-ID> fields of the
FILTER_SPEC object are the same.

However different upstream labels are allocated if the <Source <Sender
Address, LSP-ID> of the FILTER_SPEC object is different as that
implies different P2MP LSP.

6.2. Resv Message Processing

The egress LSR MUST follow normal RSVP procedures while originating a
Resv message. The Resv message carries the label allocated by the
egress LSR.

A subsequent node MUST allocates its own label and pass it in the
Resv message upstream. The node MAY combine multiple flow descrip-
tors, from different Resv messages received from downstream, in one
Resv message sent upstream. A Resv message MUST NOT be sent upstream
until at least one Resv message has been received from a downstream
neighbor. When the integrity bit is set in the 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
message includes a S2L sub-LSP descriptor list. Each such FF flow
descriptor or SE filter spec for the same P2MP LSP (whether on one or
multiple Resv messages) MUST be allocated the same label.

This label is associated by that node with all the labels received
from downstream Resv messages for that P2MP LSP. Note that a transit
node may become a replication point in the future when a branch is
attached to it. Hence this results in the setup of a P2MP LSP from
the ingress-LSR to the egress LSRs.

The ingress LSR may need to understand when all desired egresses have
been reached. This is achieved using <S2L_SUB_LSP> objects.

Each branch node can potentially send one Resv message upstream for
each of the downstream receivers. This MAY result in overflowing the
Resv message, particularly when considering that the number of mes-
sages
messages increases the closer the branch node is to the ingress. ingress of
the P2MP LSP.

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
ID field of the Path message from the upstream neighbor, when the
node set the Sub-Group Originator field in the associated Path mes-
sage. ResvErr messages generation is unmodified. Nodes propagating
a received ResvErr message MUST use the Sub-Group field values car-
ried
carried in the corresponding Resv message.

6.2.1. Resv Message Throttling

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
received from downstream. one of the downstream neighbors. This can result in
excessive Resv messages sent upstream, particularly upstream,particularly when the S2L
sub-LSPs are established for the first time. In order to mitigate
this situation, branch nodes can limit their transmission of Resv messages. mes-
sages. Specifically, in the 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 only after a delay time has passed since
the transmission of the pre-
vious previous Resv message for the same session.
This delayed Resv message SHOULD include SRROs for all branches.
Specific mechanisms for Resv message throttling are implementation
dependent and are outside the scope of this document.

6.3. Record Routing

6.3.1. RRO Processing

A Resv message contains a record route per S2L sub-LSP that is being
signaled by the Resv message if the sender node requests route
recording by including a RRO in the Path message. The same rule is
used during signaling of P2MP LSP i.e. insertion of the RRO in the
Path message used to signal one or more S2L sub-LSP triggers the
inclusion of an RRO for each sub-LSP.

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
P2MP_SECONDARY_RECORD_ROUTE objects (SRROs). Their format is speci-
fied in section 20.5. The ingress node then receives the RRO and
possibly the SRRO corresponding to each subsequent S2L sub-LSP. Each
S2L_SUB_LSP
<S2L_SUB_LSP> object is followed by the RRO/SRRO. The ingress node
can 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
Path for each S2L sub-LSP.

6.4. Reservation Style

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 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.1. PathTear Message Format

The format of the PathTear message is as follows:

<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
[ [ <MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK> ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
[ <sender descriptor> ]
[ <S2L sub-LSP descriptor list> ]

<S2L sub-LSP list> ::= <S2L_SUB_LSP> [ <S2L sub-LSP list> ]

The definition of <sender descriptor> ::= (see earlier definition) is not changed by this docu-
ment.

Note: it is assumed that the S2L sub-LSP descriptor will not include
the P2MP SECONDARY_EXPLICIT_ROUTE object associated with each
S2L_SUB_LSP S2L
sub-LSP being deleted deleted.

7.2. Pruning

The operation of removing egress LSR(s) from an existing P2MP LSP is
termed as pruning. This operation allows egress nodes to be removed
from a P2MP LSP at different points in time. This section describes
the mechanisms to perform pruning.

7.2.1. Implicit S2L Sub-LSP Teardown

Implicit teardown uses standard RSVP message processing. Per standard
RSVP processing, a S2L sub-LSP may be removed from a P2MP TE LSP by
sending a modified message for the Path or Resv message that previ-
ously advertised the S2L sub-LSP. This message MUST list all S2L sub-
LSPs
sub-LSPs that are not being removed. When using this approach, a node
processing a message that removes a S2L sub-LSP from a P2MP TE LSP
MUST ensure that the S2L sub-LSP is not included in any other Path
state associated with session before interrupting the data path to
that egress. All other message processing remains unchanged.

When implicit teardown is used to delete one or more S2L sub-LSPs, by
modifying a Path message, a transit LSR may have to generate a
PathTear message downstream to delete one or more of these S2L sub-
LSPs. This can happen if as a result of the implicit deletion of S2L
sub-LSP(s) there are no remaining S2L sub-LSPs to send in the corre-
sponding Path message downstream.

7.2.2. Explicit S2L Sub-LSP Teardown

Explicit S2L Sub-LSP teardown relies on generating a PathTear message
for the corresponding Path message. The PathTear message is signaled
with the SESSION and SENDER_TEMPLATE objects corresponding to the
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.

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 previous
Path message that corresponds to the S2L sub-LSPs being deleted by it
in the PathTear message. The transit LSR may need to generate multi-
ple PathTear messages for an incoming PathTear message if it had per-
formed transit fragmentation for the corresponding incoming Path mes-
sage.

When a P2MP LSP is removed by the ingress, a PathTear message MUST be
generated for each Path message used to signal the P2MP LSP.

8. Notify and ResvConf Messages

This section is currently under discussion between the authors and
will be updated in the next revision.

8.1. Notify Messages

The Notify Request object and Notify messages are described in
[RFC3473]. Both object and messages SHALL be supported for delivery
of upstream and downstream notification. Processing not detailed in
this section MUST comply to [RFC3473].

1. Upstream Notification

If a transit router LSR sets the sub-group originator Sub-Group Originator ID in the SENDER_TEM-
PLATE
SENDER_TEMPLATE object of a Path message to its own address and the
incoming Path mes-
sage message carries a Notify Request object then the router this LSR
MUST set change the
notify Notify node address in the Notify Request object to
its own address. address in the Path message that it sends.

If this router subsequently receives a corresponding Notify message
from down-
stream a downstream LSR than it MUST generate MUST:

- send a Notify message upstream towards toward the Notify
node address that the router had LSR received in the incoming Path message. The receiver
- process the sub-group fields of a Notify message MUST identify the sender
state referenced SENDER_TEMPLATE
object on the received Notify message, and modify their values
in the Notify message that is forwarded to match the sub-group
field values in the original Path message received from upstream.

The receiver of an (upstream) Notify message MUST identify the state
referenced in this message based on the SESSION and SENDER_TEM-
PLATE objects.

ResvConf messages are described in [RFC2205]. An egress SENDER_TEMPLATE.

2. Downstream Notification

A transit LSR may
include a RESV_CONFIRM object that contains sets the egress LSR's address.
If Sub-Group Originator ID in the FILTER_SPEC
object(s) of a transit LSR is merging Resv messages message to the value, that was received from more than
egress LSR and one or more of these in the
corresponding Path message. If the incoming Resv messages contain message carries a RESV_CON-
FIRM
Notify Request object than then the transit LSR MUST set its own the Notify node address
in the
RESV_CONFIRM Notify Request object in to the Resv message value, that it generates. Also if
the transit LSR changes the sub-group originator ID was received in the generated
Resv message and it includes a RESV_CONFIRM object
corresponding Path message, in the Resv mes-
sage, message that it MUST set its own address in the RESV_CONFIRM object. Upon
receiving sends
upstream.

If this router subsequently receives a ResvConf corresponding Notify message
from upstream the transit LSR MUST gen-
erate than it MUST:
- send a ResvConf Notify message towards each of the downstream LSRs toward the Notify
node address that had
included RESV_CONFIRM objects the LSR received in the corresponding Resv messages. As
with message.

- process the sub-group fields of the FILTER_SPEC object in the
received Notify messages, message, and modify their values in the Notify
message that is forwarded to match the sub-group field values
in the original Path message sent downstream by this LSR.

The receiver of a ResvConf (downstream) Notify message MUST iden-
tify identify the state
referenced in the this message based on the SESSION and FILTER_SPEC
objects.

9. Refresh Reduction

The refresh reduction procedures described in [RFC2961] are equally
applicable to consequence of these rules for a P2MP LSP described is that an upstream
Notify message generated on a branch will result in this document. Refresh reduction
applies a Notify being
delivered to individual messages and the state they install/maintain,
and upstream Notify node address. The receiver of the
Notify message MUST NOT assume that continues the Notify message applies to be all
downstream egresses, but MUST examine the information in the message
to determine to which egresses the case for P2MP LSP.

10. State Management

State signaled by a P2MP Path message applies.

Downstream Notify messages MUST be replicated at branch LSRs accord-
ing to the Notify Request objects received on Resv messages. Some
downstream branches might not request Notify messages, but all that
have requested Notify messages MUST receive them

8.2. ResvConf Messages

ResvConf messages are described in [RFC2205]. ResvConf processing in
[RFC3473] and [RFC3209] is managed by taken directly from [RFC2205]. An egress
LSR may include a local implemen-
tation using the <P2MP ID, Tunnel ID, Extended Tunnel ID> as part of RESV_CONFIRM object that contains the SESSION egress LSR's
address. The object and <Tunnel Sender Address, LSP ID, message SHALL be supported for the confirma-
tion of receipt of the Resv message in P2MP TE LSPs. Processing not
detailed in this section MUST comply to [RFC2205].

A transit LSR sets the Sub-Group Originator ID, Sub-Group ID> as part ID in the FILTER_SPEC
object(s) of a Resv message to the SENDER_TEMPLATE object.

Additional information signaled value, that was received in the
corresponding Path message. If the incoming Resv message is part of carries a
RESV_CONFIRM object then the
state created by LSR MUST include a local implementation. This mandatorily includes
PHOP and SENDER_TSPEC object.

10.1. Incremental State Update

RSVP as defined RESV_CONFIRM object
in [RFC2205] and as extended by RSVP-TE [RFC3209] the corresponding Resv message that it sends upstream and
GMPLS [RFC3473] uses MUST set
the same basic approach receiver address in the RESV_CONFIRM object to state communication
and synchronization, namely full state is sent the value that was
received in each state adver-
tisement message. Per [RFC2205] the corresponding Path and Resv messages are idempo-
tent. Also, [RFC2961] categorizes RSVP messages into two types: trig-
ger and refresh messages and improves RSVP message.

If this router subsequently receives a corresponding ResvConf message handling and scal-
ing of state refreshes but does not modify
from an upstream LSR than it MUST:
- send a ResvConf message downstream toward the receiver address that
the LSR received in the RESV_CONFIRM object in the full state advertise-
ment nature of Path and Resv messages. The full state advertisement
nature message.
- process the sub-group fields of Path the FILTER_SPEC object in the
received ResvConf message, and Resv messages has many benefits, but also has some
drawbacks. One notable drawback is when an incremental modification modify their values in the ResvConf
message that is being made forwarded to a previously advertised state. In this case, there
is match the sub-group field values
in the original Path message overhead sent downstream by this LSR.

The receiver of sending a ResvConf message MUST identify the full state and the cost of
processing it. It is desirable to overcome referenced
in this drawback message based on the SESSION and
add/delete S2L sub-LSPs to FILTER_SPEC objects.

The consequence of these rules for a P2MP LSP by incrementally updating the
existing state.

It is possible to use that a ResvConf mes-
sage generated at the procedures described ingress will result in this document a ResvConf message being
delivered to
allow S2L sub-LSPs the branch and then to be incrementally added or deleted from the P2MP
LSP by allowing a Path or receiver address in the orig-
inal RESV_CONFIRM object. The receiver of a PathTear ResvConf message MUST NOT
assume that the ResvConf message should be sent to incrementally change all downstream
egresses, but MUST replicate the existing P2MP LSP Path state.

As described message according to the
RESV_CONFIRM objects received in section 4.2, multiple Path Resv messages. Some downstream branches
branches might not request ResvConf messages, and ResvConf messages can
SHOULD NOT be used to
signal on these branches. All downstream branches that do
requested ResvConf messages MUST be sent such a P2MP LSP. message.

9. Refresh Reduction

The Path messages refresh reduction procedures described in [RFC2961] are distinguished by different
<Sub-Group Originator ID, sub-Group ID> tuples equally
applicable to P2MP LSP described in the SENDER_TEMPLATE
object. In order this document. Refresh reduction
applies to perform incremental S2L sub-LSP individual messages and the state addition they install/maintain,
and that continues to be the case for P2MP LSP.

10. State Management

State signaled by a
separate P2MP Path message with a new sub-Group ID is used to add the new
S2L sub-LSPs, managed by a local implemen-
tation using the ingress LSR. The <P2MP ID, Tunnel ID, Extended Tunnel ID> as part of
the SESSION object and <Tunnel Sender Address, LSP ID, Sub-Group
Originator ID MUST be
set to the TE Router ID [RFC3477] ID, Sub-Group ID> as part of the node that sets the Sub-Group
ID.

This maintains SENDER_TEMPLATE object.

Additional information signaled in the idempotent nature of RSVP Path messages; avoids
keeping track Path/Resv message is part of individual S2L sub-LSP
the state expiration created by a local implementation. This mandatorily
includes PHOP/NHOP and provides SENDER_TSPEC/FILTER_SPEC object.

10.1. Incremental State Update

RSVP as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and
GMPLS [RFC3473] uses the ability same basic approach to perform incremental P2MP LSP state updates.

10.2. Combining Multiple Path Messages

There communication
and synchronization, namely full state is a tradeoff between sent in each state adver-
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 number full state advertise-
ment nature of Path and Resv messages. The full state advertisement
nature of Path and Resv messages used by the
ingress has many benefits, but also has some
drawbacks. One notable drawback is when an incremental modification
is being made to maintain a previously advertised state. In this case, there
is the P2MP LSP and message overhead of sending the processing imposed by full state messages when adding and the cost of
processing it. It is desirable to overcome this drawback and
add/delete S2L sub-LSPs to an a P2MP LSP by incrementally updating the
existing Path message. state.

It is possible to combine use the procedures described in this document to
allow S2L sub-LSPs previously advertised in dif-
ferent Path messages in to be incrementally added or deleted from the P2MP
LSP by allowing a single Path or a PathTear message in order to reduce incrementally change
the
number of existing P2MP LSP Path state.

As described in section 4.2, multiple Path messages needed to maintain the P2MP LSP. This can
also be done by used to
signal a transit node 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
Sub-Group ID field value. When a new Path and Resv message that is sig-
naled
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]. RFC2205]. 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
sub-LSPs that belong partially or entirely to an already existing Sub-
Group_ID(i),
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
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
branching nodes belonging to this LSP. Therefore, reception of an
error message for a particular S2L sub-LSP MAY change the state of
any other S2L sub- LSP of the same P2MP TE LSP.

11.1. PathErr Messages

The PathErr message will include one or more S2L_SUB_LSP <S2L_SUB_LSP> objects.
The resulting modified format for a PathErr Message message is:

<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[ <S2L sub-LSP descriptor list> ]

PathErr messages generation is unmodified, but nodes that set the
Sub-Group Originator field and propagate a received PathErr message
upstream MUST replace the Sub-Group fields received in the PathErr
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
PathErr message is able to identify the errored outgoing Path mes-
sage, and outgoing interface, based on the Sub-Group fields received
in the PathErr message.

11.2. ResvErr Messages

The ResvErr message will include one or more S2L_SUB_LSP <S2L_SUB_LSP> objects.
The resulting modified format for a ResvErr Message is:

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
received at a branch node. In all cases, a received PathErr message
is first processed per standard processing rules. That is: the
PathErr message is sent hop-by-hop to the ingress/branch LSR for that
Path message. Intermediate nodes until this ingress/branch LSR MAY
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
the ingress LSR.

The default behavior is that the PathErr message does not have the
Path_State_Removed flag set. However, if the ingress LSR has set the
'LSP integrity'
LSP integrity flag on the Path message (see LSP_ATTRIBUTE object in
section 20) and if the Path_State_Removed flag is supported, the LSR
generating a PathErr to report the failure of a branch of the P2MP
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 other downstream branches and send the PathErr message mes-
sage upstream with the Path_State_Removed flag set.

A branch LSR that receives a PathErr message with the
Path_State_Removed flag clear MUST act according to the wishes of the
ingress LSR. The default behavior is that the branch LSR forwards the
PathErr upstream and takes no further action. 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 upstream
with the Path_State_Removed flag set (per [RFC3473]).

In all cases, the PathErr message forwarded by a branch LSR MUST con-
tain the S2L sub-LSP identification and explicit routes of all
branches that are reported by received PathErr messages and all
branches that are explicitly torn by the branch LSR.

12. Admin Status Change

A branch node that receives an ADMIN_STATUS object processes it nor-
mally and also relays the ADMIN_STATUS object in a Path on every
branch. All Path messages may be concurrently sent to the downstream
neighbors.

Downstream nodes process the change in the status object per
[RFC3473], including generation of Resv messages. When the last
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
received (or a corresponding PathErr or ResvTear messsage) on all
branches before relaying a corresponding Resv message upstream.

13. Label Allocation on LANs with Multiple Downstream Nodes

A sender on a LAN uses a different label for sending traffic to each
node on the LAN that belongs to the P2MP LSP. Thus the sender per-
forms replication. It may be considered desirable on a LAN to use the
same label for sending traffic to multiple nodes belonging to the
same P2MP LSP, to avoid replication. Procedures for doing this are
for further study.

14. P2MP LSP and Sub-LSP Re-optimization

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.

14.1. Make-before-break

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 defined
in [RFC3209]. Thus a new P2MP LSP is established. Each S2L sub-LSP is
signaled with a different LSP ID, corresponding to the new P2MP LSP.
After moving traffic to the new P2MP LSP, the ingress can tear down
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.

14.2. Sub-Group Based Re-optimization

Any node may initiate re-optimization of a set of S2L sub-LSPs by
using the incremental state update and then, optionally, combining
multiple path messages.

To alter the path taken by a particular set of S2L sub-LSPs the node
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.

As is always the case, a node may choose to combine multiple path
messages as described in section 10.2.

15. Fast Reroute

[RSVP-FR]

[RFC4090] extensions can be used to perform fast reroute for the
mechanism described in this document.

15.1. Facility Backup

Facility backup as described in [RSVP-FR] [RFC4090] can be used to protect P2MP
LSPs.

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 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
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
is used to send data for each P2MP LSP in the bypass tunnel. The
inner label is the P2MP LSP label allocated by the nhop. During fail-
ure Path messages for each S2L sub-LSP, that is effected, will be
sent to the MP, by the PLR. It is recommended that the PLR use the
sender template specific method to identify these Path messages.
Hence the PLR will set the source address in the sender template to a
local PLR address. The MP will use the LSP-ID to identify the corre-
sponding S2L sub-LSPs.

The MP MUST not use the <sub-group originator ID, sub-group ID> while
identifying the corresponding S2L sub-LSPs.

In order to further process a S2L sub-LSP it will determine the pro-
tected S2L sub-LSP using the LSP-id and the S2L sub-LSP <S2L_SUB_LSP> object.

If node protection is desired, the bypass P2P tunnel must intersect
the path of the protected S2L sub-LSPs on a LSR that is downstream
from the PLR. This constrains the set of S2L sub-LSPs being backed-up
via that bypass tunnel to those S2L sub-LSPs that pass through a com-
mon downstream MP. This MP is the destination of the bypass tunnel.
The MP will allocate the same label to all such S2L sub-LSPs belong-
ing to a particular instance of a P2MP tunnel. This will be the inner
label used during label stacking by the PLR when it sends data for
each P2MP LSP in the bypass tunnel. The outer label is the bypass
tunnel label. During failure of the protected node the PLR will send
Path messages for the protected S2L Sub-LSPs sub-LSPs to the MP using proce-
dures
procedures 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.

15.2. One to One Backup

One to one backup as described in [RSVP-FR] [RFC4090] can be used to protect a
particular S2L sub-LSP against link and next-hop failure. Protection
may be used for one or more S2L sub-LSPs between the PLR and the
next-hop. All the S2L sub-LSPs corresponding to the same instance of
the P2MP tunnel, between the PLR and the next-hop share the same P2MP
LSP label.

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
detour path. Thus the set of outgoing labels and next-hops for a P2MP
LSP that was using a single next-hop and label between the PLR and
next-hop before protection, may change once protection is triggerred.

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
backup Path message. A backup S2L sub-LSP MUST be treated as belong-
ing to a different P2MP tunnel instance than the one specified by the
LSP-id. Furthermore multiple backup S2L sub-LSPs MUST be treated as
part of the same P2MP tunnel instance if they have the same LSP-id
and the same DETOUR objects. Note that as specified in section 4 S2L
sub-LSPs between different P2MP tunnel instances use different
labels.

If there is only one S2L sub-LSP in the Path message, the DETOUR
object applies to that sub-LSP. If there are multiple S2L sub-LSPs in
the Path message the DETOUR applies to all the S2L sub-LSPs.

16. Support for LSRs that are not P2MP Capable

It may be that some LSRs in a network are capable of processing the
P2MP extensions described in this document, but do not support P2MP
branching in the data plane. If such an LSR is requested to become a
branch LSR by a received Path message, it MUST respond with a PathErr
message carrying the Error Value "Routing Error" and Error Code
"Unable to Branch".

Its also conceivable that some LSRs, in a network deploying P2MP
capability, may not support the extensions described in this docu-
ment. If a Path message for the establishment of a P2MP LSP reaches
such an LSR it will reject it with a PathErr because it will not rec-
ognize the C-Type of the P2MP SESSION object.

LSRs that do not support the P2MP extensions in this document may be
included as transit LSRs by the use of LSP-stitching [LSP-STITCH] and
LSP-hierarchy [LSP-HIER]. Note that LSRs that are required to play
any other role in the network (ingress, branch or egress) MUST sup-
port the extensions defined in this document.

The use of LSP-stitching and LSP-hierarchy [LSP-HIER] allows to build
P2MP LSPs in such an environment. A P2P LSP segment is signaled from
the previous P2MP capable hop of a legacy LSR to the next P2MP capa-
ble hop. Of course this assumes that intermediate legacy LSRs are
transit LSRs and cannot act as P2MP branch points. Transit LSRs along
this LSP segment do not process control plane messages associated
with a P2MP LSP. Furthermore these LSRs also do not need to have P2MP
data plane capability as they only need to process data belonging to
the P2P LSP segment. Hence these LSRs do not need to support P2MP
MPLS. This P2P LSP segment is stitched to the incoming P2MP LSP.
After the P2P LSP segment is established the P2MP Path message is
sent to the next P2MP capable LSR as a directed Path message. The
next P2MP capable LSR stitches the P2P LSP segment to the outgoing
P2MP LSP.

In packet networks, the S2L sub-LSPs may be nested inside the outer
P2P LSP. Hence label stacking can be used to enable use of the same
LSP segment for multiple P2MP LSP. Stitching and nesting considera-
tions and procedures are described further in [INT-REG].

It may be an overhead for an operator to configure the P2P LSP seg-
ments in advance, when it is desired to support legacy LSRs. It may
be desirable to do this dynamically. The ingress can use IGP exten-
sions to determine non P2MP capable LSRs [TE-NODE-CAP]. It can use
this information to compute S2L sub-LSP paths such that they avoid
these legacy LSRs. The explicit route object of a S2L sub-LSP path
may contain loose hops if there are legacy LSRs along the path. The
corresponding explicit route contains a list of objects upto the P2MP
capable LSR that is adjacent to a legacy LSR followed by a loose
object with the address of the next P2MP capable LSR. The P2MP capa-
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
through the legacy LSR. If such a P2P LSP exists, it uses that P2P
LSP. Else it establishes the P2P LSP. The P2MP Path message is sent
to the next P2MP capable LSR using non-adjacent signaling. The P2MP
capable LSR that initiates the non-adjacent signaling message to the
next P2MP capable LSR may have to employ a fast detection mechanism
such as [BFD] to the next P2MP capable LSR.

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
tail.

Note that legacy LSRs along a P2P LSP segment cannot perform node
protection of the tail of the P2P LSP segment.

17. Reduction in Control Plane Processing with LSP Hierarchy

It is possible to take advantage of LSP hierarchy [LSP-HIER] while
setting up P2MP LSP, as described in the previous section, to reduce
control plane processing along transit LSRs that are P2MP capable.
This is applicable only in environments where LSP hierarchy can be
used. Transit LSRs along a P2P LSP segment, being used by a P2MP LSP,
do not process control plane messages associated with the P2MP LSP.
Infact they are not aware of these messages as they are tunneled over
the P2P LSP segment. This reduces the amount of control plane pro-
cessing required on these transit LSRs.

Note that the P2P LSP segments can be dynamically setup as described
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
messages for PE3 and PE4 can now be tunneled over the LSP segment.
Thus P3 is not aware of the P2MP LSP and does not process the P2MP
control messages.

18. P2MP LSP Remerging and Cross-Over

This section is currently under discussion between the authors and
will be updated in the next revision.

This section details the procedures for detecting and dealing with
re-merge and cross-over. The functional description described so far assumes term re-merge refers to the case of an
ingress or transit node that multiple
Path messages received by creates a LSR for branch of a P2MP LSP, a re-
merge branch, which intersects the same P2MP LSP arrive on the
same incoming interface. However this may not always be at another node farther
down the case.

P2MP tree remerging or cross-over occurs when a transit tree. This may occur due to such events as an error in path
calculation, an error in manual configuration, or egress
node receives network topology
changes during the signaling state i.e. Path message for establishment of the same P2MP
TE LSP from more than one previous hop. LSP. If the remerged S2L sub-LSPs
are sent out on different interfaces there is no data plane issue.
However if the remerged S2L sub-LSPs are sent out on the same inter-
face it can result procedures
detailed in this section are not followed, data duplication downstream. In order will
result.

The term cross-over refers to
describe identification the case of cross over and remerging by an ingress or transit node
that creates a LSR let us
list the various cases when state for branch of a S2L sub-LSP is received by P2MP LSP, a
LSR.

Case1: S2L sub-LSP already exist as part of an existing Path state.
The following are the various sub-cases.
a) The new S2L sub-LSP uses cross-over branch, which
intersects the same PHOP and outgoing interface
as P2MP LSP at another node farther down the existing S2L sub-LSP. This tree. It is either a refresh or can occur
when multiple existing Path messages are combined
unlike re-merge in a new Path mes-
sage.

b) The new S2L sub-LSP uses that at the same PHOP but different outgoing
interface as intersecting node the existing S2L sub-LSP. This is a case of re-routing.
c) The new S2L sub-LSP uses cross-over
branch has a different PHOP and same outgoing interface as the existing S2L sub-LSP. This is a case of re-routing.
d) The new S2L sub-LSP uses well as a different PHOP
incoming interface. This may be necessary in certain combinations of
topology and technology; e.g., in a transparent optical network in
which different out-
going interface as compared wavelengths are required to the existing S2L sub-LSP. This is reach different leaf
nodes.

Normally, a
case of re-routing.

Case2: S2L sub-LSP does not exist as part P2MP LSP has a single incoming interface on which all of an existing
the Path state.
The following messages associated with that P2MP LSP are the sub-cases.
a) received. The new S2L sub-LSP uses a PHOP and outgoing
incoming interface that is
same as identified by the PHOP IF_ID RSVP_HOP Object, if
present, and outgoing interface used by an existing S2L sub-
LSP that belongs to interface over which the same P2MP LSP. This Path message was received if
the IF_ID RSVP_HOP Object is a legal not present. However, in the 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
existing S2L sub-LSP. However
dynamic LSP re-routing, the outgoing incoming interface is different
from the outgoing interfaces used by existing S2L sub-LSPs belonging
to may change.

Similarly, in both the same P2MP LSP. This is a legal re-merge case of signaling and cross-over cases, a new S2L
sub-LSP.
c) The new S2L sub-LSP uses node
will receive a Path message for a given P2MP LSP on a different PHOP than that used by any
of
incoming interface, and the existing S2L sub-LSP that belong node needs to the same P2MP be able to distinguish
between dynamic LSP . How-
ever re-routing and the outgoing interface is same as re-merge/cross-over cases.

(Make-before-break represents yet another similar but different case,
in that the outgoing incoming interface used by
an existing S2L sub-LSPs. This is a case of remerging.
d) The new S2L sub-LSP uses a associated with the make-before-break
P2MP LSP may be different PHOP than that used by any
of associated with the existing S2L sub-LSP that belong original P2MP
LSP. However, the two P2MP LSPs will be treated as distinct, but
related, LSPs because they will have different LSP ID field values in
their SENDER_TEMPLATE objects.)

18.1. Procedures

When a node receives a Path message, it MUST check whether it has
matching state for the P2MP LSP. Matching state is identified by com-
paring the SESSION and SENDER_TEMPLATE objects in the received Path
message with the SESSION and SENDER_TEMPLATE objects of each locally
maintained P2MP LSP Path state. The P2MP ID, Tunnel ID, and Extended
Tunnel ID in the SESSION Object and the sender address and LSP ID in
the SENDER_TEMPLATE object are used for the comparison. If the node
has matching state and the incoming interface for the received Path
message is different than the incoming interface of the matching P2MP
LSP Path state, then the node MUST determine whether it is dealing
with dynamic LSP rerouting or re-merge/cross-over.

Dynamic LSP rerouting is identified by checking whether there is any
intersection between the set of SUB-LSP objects associated with the
matching P2MP LSP Path state and the set of SUB-LSP objects in the
received Path message. If there is any intersection, then dynamic
re-routing has occurred. If there is no intersection between the two
sets of SUB-LSP objects, then either re-merge or cross-over has
occurred. (Note that in the case of dynamic LSP rerouting, Path mes-
sages for the non-intersecting members of set of SUB-LSPs associated
with the matching P2MP LSP Path state will be received subsequently
on the new incoming interface.)

In order to identify the re-merge case, the node processing the
received Path message MUST identify the outgoing interfaces associ-
ated with the matching P2MP Path state. Re-merge has occurred if
there is any intersection between the set of outgoing interfaces
associated with the matching P2MP LSP Path state and the set of out-
going interfaces in the received Path message.

18.1.1. Re-Merge Procedures

There are two approaches to dealing with re-merge case. In the
first, the node detecting the re-merge case, i.e., the re-merge node,
allows the re-merge case to persist but data from all but one incom-
ing interface is dropped at the re-merge node. In the second, the
re-merge node initiates the removal of the re-merge branch(es) via
signaling. Which approach is used is a matter of local policy. A
node MUST support both approaches and MUST allow user configuration
of which approach is to be used.

When configured to allow a re-merge case to persist, the re-merge
node MUST validate consistency between the objects included the
received Path message and the matching P2MP LSP Path state. Any
inconsistencies MUST result in an appropriate PathErr message sent to
the previous hop of the received Path message. The error code is set
to "Routing Problem" and the error value is set to "P2MP Re-Merge
Parameter Mistmatch".

If there are no inconsistencies, the node logically merges, from the
downstream perspective, the control state of incoming Path message
with the matching P2MP LSP Path state. Specifically, procedures
related to processing of messages received from upstream MUST NOT be
modified from the upstream perspective; this includes refresh and
state timeout related processing. In addition to the standard
upstream related procedures, the node MUST ensure that each object
received from upstream is appropriately represented within the set of
Path messages sent downstream. For example, the received <S2L sub-LSP
descriptor list> MUST be included in the set of outgoing Path mes-
sages. If there are any NOTIFY_REQUEST request objects present, then
the procedures defined in Section 8 MUST be followed for both Path
and Resv messages. Special processing is also required for Resv pro-
cessing. Specifically, any Resv message received from downstream
MUST be mapped into an outgoing Resv message that is sent to the pre-
vious hop of the received Path message. In practice, this translates
to decomposing the same P2MP LSP. Also
the outgoing interface is different from complete <S2L sub-LSP descriptor list> into sub-
sets that match the incoming Path messages and then constructing an
outgoing interfaces used
by existing S2L sub-LSPs. This is Resv message for each incoming Path message.

When configured to allow a re-merge case of cross-over.

Case 2(d) above identifies cross-over and this is considered legal.
Case 2(c) above identifies remerging in to persist, the re-merge
node receives data plane. If the LSR is
capable of remerging in associated with the data plane this is considered legal.

The below procedure applies for remerging.

The remerge error case is detected by checking incoming Path messages
that represent new P2MP TE LSP state and seeing if they represent
both known LSP state and a different S2L sub-LSP list. Specifically, on multiple incoming
interfaces, but it may only send the remerge check data from one of these inter-
faces to its outgoing interfaces, i.e., the node MUST be performed when processing Path messages
that contain SESSION, SENDER_TEMPLATE and RSVP_HOP objects drop data from
all but one incoming interface. This ensures that have duplicate data is
not previously been seen sent on a particular any outgoing interface. The remerge check
consists of attempting mechanism used to locate state that has the same values in
the SESSION object and in the tunnel sender address and LSP ID fields
of select the SENDER_TEMPLATE object.

If no matching state is located, then there is no remerge condition.

If matching state
incoming interface to use is found, then the list of S2L Sub-LSPs associated
with the new Path message implementation specific and is compared against the list present in the
located state. If any addresses in outside
the lists scope of S2L sub-LSPs match,
then it is this document.

When configured to correct the legal LSP rerouting case mentioned here above.

If there are no overlap in re-merge branch via signaling, the lists, re-
merge node MUST send a PathErr message corresponding to the node checks whether any received
Path message. The PathErr message MUST include all of the outgoing interfaces, objects
normally included in a PathErr message, as identified by well as one or more SUB-
LSP objects from the ERO/SUB_EROs, are an
outgoing interface already set of sub-LSPs associated with the existing matching
P2MP LSP. If
not, then legal LSP crossing is being performed. Else re-merging has
occurred and if the LSR is capable Path state. A minimum of remerging in the data plane,
this three SUB-LSP objects is considered legal. In RECOM-
MENDED. This will allow the node that case caused the LSR will return re-merge to identify
the label
already outgoing Path state 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 valid portion of remerging in the data plane the new Path message
MUST be handled according to remerge error processing as described
below. P2MP
LSP. The LSR generates a PathErr message with Error Code MUST include the error code "Routing Prob-
lem/P2MP
lem" and error value of "P2MP Remerge Detected" towards the upstream node (i.e. the Detected". The node
that sent the Path message) until it reaches MAY set the node that caused
Path_State_Removed flag [RFC3473]. As is always the
remerge condition. Identification of case, the offending node requires
special processing by
PathErr message is sent to the nodes upstream previous hop of the error. received Path mes-
sage.

A node that receives a PathErr message that contains the error "Routing Prob-
lem/P2MP "Rout-
ing Problem/P2MP Remerge Detected" MUST check to see determine if it is the offending
node. node
that created the re-merge case. This check is done by comparing the S2L sub-LSPs listed in the
PathErr message with existing LSP state. If checking whether
there is any of intersection between the egresses are
already present in any Path state associated set of SUB-LSP objects associ-
ated with the matching P2MP TE LSP
other than the one associated with Path state and the <SESSION, SENDER_TEMPLATE> set of SUB-LSP
objects signaled in the received PathErr message, message. If there is, then the node is the signal-
ing branch node that caused
created the remerge condition. This re-merge case.

The node SHOULD
then correct remove the remerge condition re-merge case by adding all S2L sub-LSPs listed moving the SUB-LSP
objects included in the offending Path state message associated with the received
PathErr message to the Path state (and Path message) outgoing interface associated to these S2L sub-LSPs. Note that with the new match-
ing P2MP LSP Path state may be state. A trigger Path message for the moved SUB-
LSP objects is then sent out via that outgoing interface. If the
received PathErr message did not have the Path_State_Removed flag
set, the node SHOULD send a PathTear via the same outgoing interface in different Path messages in
order to meet IP packet size limitations. asso-
ciated with the re-merge branch.

If use of a new outgoing interface violates one or more SERO constraint, con-
straint, then a PathErr mes-
sage message containing the associated egresses
and any identified valid
egresses SUB-LSP objects SHOULD be generated with the error
code "Routing Problem" and error value of "ERO Resulted in Remerge".

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
sub-LSPs
SUB-LSP objects are deleted prior to the PathErr message propagating
to the ingress. In this case, the whole process will be corrected on
the next (refresh or trigger) transmission of the offending Path message.

In all cases where a remerge error is not detected, normal processing
continues. mes-
sage.

19. New and Updated Message Objects

This section presents the RSVP object formats as modified by this
document.

19.1. SESSION Object

A P2MP LSP SESSION object is used. This object uses the existing SES-
SION
SESSION C-Num. New C-Types are defined to accommodate a logical P2MP
destination identifier of the P2MP Tunnel. This SESSION object has a
similar structure as the existing point to point RSVP-TE SESSION
object. However the destination address is set to the P2MP ID
instead of the unicast Tunnel Endpoint address. All S2L sub-LSPs part
of the same P2MP LSP share the same SESSION object. This SESSION
object identifies the P2MP Tunnel.

The combination of the SESSION object, the SENDER_TEMPLATE object and
the S2L SUB-LSP <S2L_SUB_LSP> object, identifies each S2L sub-LSP. This follows
the existing P2P RSVP-TE notion of using the SESSION object for identify-
ing iden-
tifying a P2P Tunnel which in turn can contain multiple LSPs, each dis-
tinguished
distinguished by a unique SENDER_TEMPLATE object.

19.1.1. P2MP LSP Tunnel IPv4 SESSION Object

Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = TBA

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

P2MP ID
A 32-bit identifier used in the SESSION object that remains
constant over the life of the P2MP tunnel. It encodes the
P2MP ID and identifies the set of destinations of the P2MP
Tunnel.

Tunnel ID

A 16-bit identifier used in the SESSION object that remains
constant over the life of the P2MP tunnel.

Extended Tunnel ID

A 32-bit identifier used in the SESSION object that remains
constant over the life of the P2MP tunnel. Normally set to
all zeros. Ingress nodes that wish to narrow the scope of a
SESSION to the ingress-PID pair may place their IPv4 address
here as a globally unique identifier [RFC3209].

19.1.2. P2MP LSP Tunnel IPv6 SESSION Object

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
[RFC3209].

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (16 bytes) |
| |
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

19.2. SENDER_TEMPLATE object

The sender template SENDER_TEMPLATE object contains the ingress-LSR source address.
LSP ID can be can be changed to allow a sender to share resources
with itself. Thus multiple instances of the P2MP tunnel can be created, cre-
ated, each with a different LSP ID. The instances can share resources
with each other, but use different labels. The S2L sub-LSPs corresponding corre-
sponding to a particular instance use the same LSP ID.

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 by
using a <Sub-Group ID Originator ID, Sub-Group ID> tuple. The
SENDER_TEMPLATE object is modified to carry this information as shown
below.

19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object

Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = TBA

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Group Originator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv4 tunnel sender address
See [RFC3209]

Sub-Group Originator ID
The Sub-Group Originator ID is set to the TE Router ID of
the LSR that originates the Path message. This is either the
ingress LSR or a LSR which re-originates the Path message
with its own Sub-Group Originator ID.

Sub-Group ID
An identifier of a Path message used to differentiate
multiple Path messages that signal state for the same P2MP
LSP. This may be seen as identifying a group of one or more
egress nodes targeted by this Path message.

LSP ID
See [RFC3209]

19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object

Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = TBA

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Sub-Group Originator ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6 tunnel sender address
See [RFC3209]

Sub-Group Originator ID
The Sub-Group Originator ID is set to the IPv6 TE Router ID
of the LSR that originates the Path message. This is either
the ingress LSR or a LSR which re-originates the Path
message with its own Sub-Group Originator ID.

Sub-Group ID
As above. above in section 19.2.2.

LSP ID
See [RFC3209]

19.3. S2L SUB-LSP <S2L_SUB_LSP> Object

A new S2L Sub-LSP <S2L_SUB_LSP> object identifies a particular S2L sub-LSP belong-
ing
belonging to the P2MP LSP.

19.3.1. S2L SUB-LSP <S2L_SUB_LSP> IPv4 Object

SUB_LSP Class = 50, S2L_SUB_LSP_IPv4 C-Type = TBA

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 S2L Sub-LSP destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv4 Sub-LSP destination address

IPv4 address of the S2L sub-LSP destination.

19.3.2. S2L SUB-LSP <S2L_SUB_LSP> IPv6 Object

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
the destination address is a 16 byte IPv6 address.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 S2L Sub-LSP destination address (16 bytes) |
| .... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

19.4. FILTER_SPEC Object

The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
object.

19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object

Class = FILTER SPEC, P2MP LSP_IPv4 C-Type = TBA

The format of the P2MP LSP_IPv4 FILTER_SPEC object is identical to
the P2MP LSP_IPv4 SENDER_TEMPLATE object.

19.4.2. P2MP LSP_IPv4 FILTER_SPEC Object

Class = FILTER SPEC, P2MP LSP_IPv6 C-Type = TBA

The format of the P2MP LSP_IPv6 FILTER_SPEC object is identical to
the P2MP LSP_IPv6 SENDER_TEMPLATE object.

19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO)

The P2MP Secondary Explicit Route Object (SERO) is defined as identi-
cal to the ERO. The class of the P2MP SERO is the same as the SERO
defined in [RECOVERY] (TBA). [RECOVERY]. The P2MP SERO uses a new C-Type = TBA 2. The sub-
objects are identical to those defined for the ERO.

19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO)

The P2MP Secondary Record Route SECONDARY_RECORD_ROUTE Object (SRRO) is defined as identical
to the ERO. The class of the P2MP SRRO is the same as the SRRO
defined in [RECOVERY] (TBA). [RECOVERY]. The P2MP SRRO uses a new C-Type = TBA. 2. The sub-
objects are identical to those defined for the RRO.

20. IANA Considerations

20.1. New Class Numbers

IANA is requested to assign the following Class Numbers for the new
object classes introduced. The Class Types for each of them are to be
assigned via standards action. The sub-object types for the P2MP SEC-
ONDARY_EXPLICIT_ROUTE
SECONDARY_EXPLICIT_ROUTE and P2MP_SECONDARY_RECORD_ROUTE follow the
same IANA considerations as those of the ERO and RRO [RFC3209].

50 Class Name = SUB_LSP

C-Type
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
be formed by the reporting LSR. IANA is requested to assign value 20 23
to this Error Code.

The Error Code "Unsupported LSP Integrity" indicates that a P2MP
branch does not support the requested LSP integrity function. IANA is
requested to assign value 21 24 to this Error Code.

The Error Code "P2MP Remerge Detected" indicates that a node has
detected remerge. IANA is requested to assign value 22 25 to this Error
Code.

20.4. LSP Attributes Flags

IANA has been asked to manage the space of flags in the Attibutes
Flags TLV carried in the LSP_ATTRIBUTES Object [LSP-ATTRIB]. This
document defines two new flags as follows:

Suggested Bit Number: 3
Meaning: LSP Integrity Required
Used in Attributes Flags on Path: Yes
Used in Attributes Flags on Resv: No
Used in Attributes Flags on RRO: No
Referenced Section of this Doc: 10

21. Security Considerations

This document does not introduce any new security issues. The secu-
rity issues identified in [RFC3209] and [RFC3473] are still relevant.

22. Acknowledgements

This document is the product of many people. The contributors are
listed in Section 27.2.

Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger and Nischal
Sheth for their suggestions and comments. Thanks also to Dino Farni-
nacci for his comments.

23. Appendix

23.1. Example

Following is one example of setting up a P2MP LSP using the proce-
dures described in this document.

Source 1 (S1)
|
PE1
| |
|L5 |
P3 |
| |
L3 |L1 |L2
R2----PE3--P1 P2---PE2--Receiver 1 (R1)
| L4
PE5----PE4----R3
|
|
R4

Figure 2.

The mechanism is explained using Figure 2. PE1 is the ingress-LSR.
PE2, PE3 and PE4 are Egress-LSRs.

a) PE1 learns that PE2, PE3 and PE4 are interested in joining a P2MP
tree with a P2MP ID of P2MP ID1. We assume that PE1 learns of the
egress-LSRs at different points.

b) PE1 computes the P2P path to reach PE2.

c) PE1 establishes the S2L sub-LSP to PE2 along <PE1, P2, PE2>

d) PE1 computes the P2P path to reach PE3 when it discovers PE3. This
path is computed to share the same links where possible with the sub-
LSP to PE2 as they belong to the same P2MP session.

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
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.

g) PE1 signals the Path message for PE4 sub-LSP along <PE1, P3, P1,
PE4>

e) P1 receives a Resv message from PE4 with label L4. It had previ-
ously received a Resv message from PE3 with label L3. It had allo-
cated a label L1 for the sub-LSP to PE3. It uses the same label and
sends the Resv messages to P3. Note that it may send only one Resv
message with multiple flow descriptors in the flow descriptor list.
If this is the case and FF style is used, the FF flow descriptor will
contain the S2L sub-LSP descriptor list with two entries: one for PE4
and the other for PE3. For SE style, the SE filter spec will contain
this S2L sub-LSP descriptor list. P1 also creates a label mapping of
(L1 -> {L3, L4}). P3 uses the existing label L5 and sends the Resv
message to PE1, with label L5. It reuses the label mapping of {L5 ->
L1}.

24. References

24.1. Normative References

[LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, work in
progress.

[LSP-ATTR] A. Farrel, et. al. , "Encoding of
Attributes for Multiprotocol Label Switching (MPLS)
Label Switched Path (LSP) Establishment Using RSVP-TE",
draft-ietf-mpls-rsvpte-attributes-05.txt, March 2004,
work in progress.

[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan,
G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC3209, December 2001, work in progress.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997, work in
progress.

[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1,
Functional Specification", RFC 2205, September 1997, work in
progress.

[RFC3471] Lou Berger, et al., "Generalized MPLS - Signaling Functional
Description", RFC 3471, January 2003, work in progress.

[RFC3473] L. Berger et.al., "Generalized MPLS Signaling - RSVP-TE
Extensions", RFC 3473, January 2003, work in progress.

[RFC2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi,
S. Molendini, "RSVP Refresh Overhead Reduction Extensions",
RFC 2961, April 2001, work in progress.

[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001, work in
progress.

[RFC4090] P. Pan, G. Swallow, A. Atlas (Editors), "Fast Reroute Extensions
to RSVP-TE for LSP Tunnels", work in progress.

[RFC3477] K. Kompella, Y. Rekther, "Signalling Unnumbered Links in
Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)",
work in progress .

[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",
draft-katz-ward-bfd-01.txt, work in progress.

[BFD-MPLS] R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow, "BFD for MPLS
LSPs", draft-ietf-bfd-mpls-00.txt, work in progress.

[IPR-1] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004, work in progress.

[IPR-2] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004, work in progress.

[INT-REG] JP Vasseur, A. Ayyangar, "Inter-area and Inter-AS MPLS Traffic
Engineering", draft-vasseur-ccamp-inter-area-as-te-00.txt,
work in progress.

[RFC2209] R. Braden, L. Zhang, "Resource Reservation Protocol (RSVP)
Version 1 Message Processing Rules", RFC 2209, work in progress.

[LSP-STITCH] A. Ayyanger, J.P. Vasseur, "Label Switched Path Stitching
with Generalized MPLS Traffic Engineering",
draft-ietf-ccamp-lsp-stitching-00.txt, April 2005
work in progress

[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

25. Author Information

25.1. Editor Information

Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net

Seisho Yasukawa
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 4769
EMail: yasukawa.seisho@lab.ntt.co.jp

Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be

25.2. Contributor Information

John Drake
Calient Networks
Email: jdrake@calient.net

Alan Kullberg
Motorola Computer Group
120 Turnpike Road 1st Floor
Southborough, MA 01772
EMail: alan.kullberg@motorola.com

Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com

Liming Wei
Redback Networks
350 Holger Way
San Jose, CA 95134
Email: lwei@redback.com

George Apostolopoulos
Redback Networks
350 Holger Way
San Jose, CA 95134
Email: georgeap@redback.com

Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
Email: kireeti@juniper.net

George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: swallow@cisco.com

JP Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: jpv@cisco.com

Dean Cheng
Cisco Systems Inc.
170 W Tasman Dr.
San Jose, CA 95134
Phone 408 527 0677
Email: dcheng@cisco.com

Markus Jork
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
Phone: +1 978 964 2142
EMail: mjork@avici.com

Hisashi Kojima
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 6070
EMail: kojima.hisashi@lab.ntt.co.jp

Andrew G. Malis
Tellabs
2730 Orchard Parkway
San Jose, CA 95134
Phone: +1 408 383 7223
Email: Andy.Malis@tellabs.com

Koji Sugisono
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 2605
EMail: sugisono.koji@lab.ntt.co.jp

Masanori Uga
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 4804
EMail: uga.masanori@lab.ntt.co.jp

Igor Bryskin
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102

Adrian Farrel
Old Dog Consulting
Phone: +44 0 1978 860944
EMail: adrian@olddog.co.uk

Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
E-mail: jeanlouis.leroux@francetelecom.com

26. Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assur-
ances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.

27. Full Copyright Statement

Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

28. Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.