draft-ietf-mpls-rsvp-te-p2mp-02.txt   draft-ietf-mpls-rsvp-te-p2mp-03.txt 
Network Working Group R. Aggarwal (Editor) Network Working Group R. Aggarwal (Editor)
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: January 2006 Expiration Date: April 2006
D. Papadimitriou (Editor) D. Papadimitriou (Editor)
Alcatel Alcatel
S. Yasukawa (Editor) S. Yasukawa (Editor)
NTT NTT
July 2005 October 2005
Extensions to RSVP-TE for Point to Multipoint TE LSPs Extensions to RSVP-TE for Point to Multipoint TE LSPs
draft-ietf-mpls-rsvp-te-p2mp-02.txt draft-ietf-mpls-rsvp-te-p2mp-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 39 skipping to change at page 3, line 39
6.2.1 Resv Message Throttling ............................... 18 6.2.1 Resv Message Throttling ............................... 18
6.3 Record Routing ........................................ 18 6.3 Record Routing ........................................ 18
6.3.1 RRO Processing ........................................ 18 6.3.1 RRO Processing ........................................ 18
6.4 Reservation Style ..................................... 19 6.4 Reservation Style ..................................... 19
7 PathTear Message ...................................... 19 7 PathTear Message ...................................... 19
7.1 PathTear Message Format ............................... 19 7.1 PathTear Message Format ............................... 19
7.2 Pruning ............................................... 20 7.2 Pruning ............................................... 20
7.2.1 Implicit S2L Sub-LSP Teardown ......................... 20 7.2.1 Implicit S2L Sub-LSP Teardown ......................... 20
7.2.2 Explicit S2L Sub-LSP Teardown ........................ 20 7.2.2 Explicit S2L Sub-LSP Teardown ........................ 20
8 Notify and ResvConf Messages .......................... 21 8 Notify and ResvConf Messages .......................... 21
9 Refresh Reduction ..................................... 21 8.1 Notify Messages ....................................... 21
10 State Management ...................................... 22 8.2 ResvConf Messages ..................................... 22
10.1 Incremental State Update .............................. 22 9 Refresh Reduction ..................................... 23
10.2 Combining Multiple Path Messages ...................... 23 10 State Management ...................................... 23
11 Error Processing ...................................... 24 10.1 Incremental State Update .............................. 23
11.1 PathErr Messages ...................................... 24 10.2 Combining Multiple Path Messages ...................... 24
11.2 ResvErr Messages ...................................... 24 11 Error Processing ...................................... 25
11.3 Branch Failure Handling ............................... 25 11.1 PathErr Messages ...................................... 25
12 Admin Status Change ................................... 26 11.2 ResvErr Messages ...................................... 26
13 Label Allocation on LANs with Multiple Downstream Nodes ...26 11.3 Branch Failure Handling ............................... 26
14 P2MP LSP and Sub-LSP Re-optimization .................. 26 12 Admin Status Change ................................... 27
14.1 Make-before-break ..................................... 27 13 Label Allocation on LANs with Multiple Downstream Nodes. 28
14.2 Sub-Group Based Re-optimization ....................... 27 14 P2MP LSP and Sub-LSP Re-optimization .................. 28
15 Fast Reroute .......................................... 27 14.1 Make-before-break ..................................... 28
15.1 Facility Backup ....................................... 28 14.2 Sub-Group Based Re-optimization ....................... 28
15.2 One to One Backup ..................................... 29 15 Fast Reroute .......................................... 29
16 Support for LSRs that are not P2MP Capable ............ 29 15.1 Facility Backup ....................................... 29
17 Reduction in Control Plane Processing with LSP Hierarchy ..31 15.2 One to One Backup ..................................... 30
18 P2MP LSP Remerging and Cross-Over ..................... 31 16 Support for LSRs that are not P2MP Capable ............ 30
19 New and Updated Message Objects ....................... 34 17 Reduction in Control Plane Processing with LSP Hierarchy. 32
19.1 SESSION Object ........................................ 34 18 P2MP LSP Remerging and Cross-Over ..................... 32
19.1.1 P2MP LSP Tunnel IPv4 SESSION Object ................... 34 18.1 Procedures ............................................ 33
19.1.2 P2MP LSP Tunnel IPv6 SESSION Object ................... 35 18.1.1 Re-Merge Procedures ................................... 34
19.2 SENDER_TEMPLATE object ................................ 35 19 New and Updated Message Objects ....................... 36
19.2.1 P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object ........... 35 19.1 SESSION Object ........................................ 36
19.2.2 P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object ........... 36 19.1.1 P2MP LSP Tunnel IPv4 SESSION Object ................... 36
19.3 S2L SUB-LSP Object .................................... 37 19.1.2 P2MP LSP Tunnel IPv6 SESSION Object ................... 37
19.3.1 S2L SUB-LSP IPv4 Object ............................... 37 19.2 SENDER_TEMPLATE object ................................ 37
19.3.2 S2L SUB-LSP IPv6 Object ............................... 38 19.2.1 P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object ........... 38
19.4 FILTER_SPEC Object .................................... 38 19.2.2 P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object ........... 39
19.4.1 P2MP LSP_IPv4 FILTER_SPEC Object ...................... 38 19.3 <S2L_SUB_LSP> Object .................................. 40
19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object ...................... 38 19.3.1 <S2L_SUB_LSP> IPv4 Object ............................. 40
19.5 P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) ........... 38 19.3.2 <S2L_SUB_LSP> IPv6 Object ............................. 40
19.6 P2MP_SECONDARY_RECORD_ROUTE Object (SRRO) ............. 39 19.4 FILTER_SPEC Object .................................... 40
20 IANA Considerations ................................... 39 19.4.1 P2MP LSP_IPv4 FILTER_SPEC Object ...................... 41
20.1 New Class Numbers ..................................... 39 19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object ...................... 41
20.2 New Class Types ....................................... 39 19.5 P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) ........... 41
20.3 New Error Codes ....................................... 40 19.6 P2MP SECONDARY_RECORD_ROUTE Object (SRRO) ............. 41
20.4 LSP Attributes Flags .................................. 40 20 IANA Considerations ................................... 41
21 Security Considerations ............................... 41 20.1 New Class Numbers ..................................... 41
22 Acknowledgements ...................................... 41 20.2 New Class Types ....................................... 42
23 Appendix .............................................. 41 20.3 New Error Codes ....................................... 42
23.1 Example ............................................... 41 20.4 LSP Attributes Flags .................................. 43
24 References ............................................ 42 21 Security Considerations ............................... 43
24.1 Normative References .................................. 42 22 Acknowledgements ...................................... 43
24.2 Informative References ................................ 43 23 Appendix .............................................. 43
25 Author Information .................................... 44 23.1 Example ............................................... 43
25.1 Editor Information .................................... 44 24 References ............................................ 45
25.2 Contributor Information ............................... 45 24.1 Normative References .................................. 45
26 Intellectual Property ................................. 47 24.2 Informative References ................................ 46
27 Full Copyright Statement .............................. 48 25 Author Information .................................... 47
28 Acknowledgement ....................................... 48 25.1 Editor Information .................................... 47
25.2 Contributor Information ............................... 47
26 Intellectual Property ................................. 50
27 Full Copyright Statement .............................. 50
28 Acknowledgement ....................................... 51
1. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS]. document are to be interpreted as described in RFC-2119 [KEYWORDS].
2. Terminology 2. Terminology
This document uses terminologies defined in [RFC3031], [RFC2205], This document uses terminologies defined in [RFC3031], [RFC2205],
[RFC3209], [RFC3473] and [P2MP-REQ]. [RFC3209], [RFC3473] and [P2MP-REQ].
3. Introduction 3. Introduction
[RFC3209] defines a mechanism for setting up P2P TE LSPs in MPLS net- [RFC3209] defines a mechanism for setting up P2P TE LSPs in MPLS
works. [RFC3473] defines extensions to [RFC3209] for setting up P2P networks. [RFC3473] defines extensions to [RFC3209] for setting up P2P
TE LSPs in GMPLS networks. However these specifications do not pro- TE LSPs in GMPLS networks. However these specifications do not
vide a mechanism for building P2MP TE LSPs. provide a mechanism for building P2MP TE LSPs.
This document defines extensions to RSVP-TE protocol [RFC3209, This document defines extensions to RSVP-TE protocol [RFC3209,
RFC3473] to support P2MP TE LSPs satisfying the set of requirements RFC3473] to support P2MP TE LSPs satisfying the set of requirements
described in [P2MP-REQ]. described in [P2MP-REQ].
This document relies on the semantics of RSVP that RSVP-TE inherits This document relies on the semantics of RSVP that RSVP-TE inherits
for building P2MP LSPs. A P2MP LSP is comprised of multiple S2L sub- for building P2MP LSPs. A P2MP LSP is comprised of multiple S2L
LSPs. These S2L sub-LSPs are set up between the ingress and egress 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 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 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 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 LSP can be signaled using one Path message or split across multiple
Path messages. Path messages.
Path computation and P2MP application specific aspects are outside of Path computation and P2MP application specific aspects are outside of
the scope of this document. the scope of this document.
4. Mechanism 4. Mechanism
This document describes a solution that optimizes data replication by This document describes a solution that optimizes data replication by
allowing non-ingress nodes in the network to be replication/branch allowing non-ingress nodes in the network to be replication/branch
nodes. A branch node is a LSR that is capable of replicating the nodes. A branch node is a LSR that is capable of replicating the
incoming data on two or more outgoing interfaces. The solution uses incoming data on two or more outgoing interfaces. The solution relies
RSVP-TE in the core of the network for setting up a P2MP TE LSP. on RSVP-TE in the network for setting up a P2MP TE LSP.
The P2MP TE LSP is set up by associating multiple S2L TE sub-LSPs and The P2MP TE LSP is set up by associating multiple S2L TE sub-LSPs and
relying on data replication at branch nodes. This is described fur- relying on data replication at branch nodes. This is described
ther in the following sub-sections by describing P2MP Tunnels and how further in the following sub-sections by describing P2MP Tunnels and
they relate to S2L sub-LSPs. how they relate to S2L sub-LSPs.
4.1. P2MP Tunnels 4.1. P2MP Tunnels
The specific aspect related to P2MP TE LSP is the action required at The specific aspect related to P2MP TE LSP is the action required at
a branch node, where data replication occurs. For instance, in the a branch node, where data replication occurs. Incoming MPLS labeled
MPLS case, incoming labeled data is appropriately replicated to sev- data is appropriately replicated to several outgoing interfaces which
eral outgoing interfaces which may have different labels. may have different labels.
A P2MP TE Tunnel comprises of one or more P2MP LSPs. A P2MP TE Tunnel 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 is identified by a P2MP SESSION object. This object contains the
identifier of the P2MP Session which includes the P2MP ID, a tunnel identifier of the P2MP Session which includes the P2MP ID, a tunnel
ID and an extended tunnel ID. ID and an extended tunnel ID.
The fields of a P2MP SESSION object are identical to those of the The fields of a P2MP SESSION object are identical to those of the
SESSION object defined in [RFC3209] except that the Tunnel Endpoint SESSION object defined in [RFC3209] except that the Tunnel Endpoint
Address field is replaced by the P2MP Identifier (P2MP ID) field. Address field is replaced by the P2MP Identifier (P2MP ID) field.
skipping to change at page 6, line 38 skipping to change at page 6, line 38
ID, and Extended Tunnel ID that are part of the P2MP SESSION object, 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 and the tunnel sender address and LSP ID fields of the P2MP
SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is
defined in section 20.2. defined in section 20.2.
4.3. Sub-Groups 4.3. Sub-Groups
As with all other RSVP controlled LSPs, P2MP LSP state is managed 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 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 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- notable differences are that a P2MP LSP comprises multiple S2L
LSPs and that, as a result of this, it may not be possible to repre- Sub-LSPs and that, as a result of this, it may not be possible to
sent full state in a single IP datagram and even more likely that it represent full state in a single IP packet and even more likely that it
can't fit into a single IP packet. It must also be possible to effi- can't fit into a single IP packet. It must also be possible to
ciently add and remove endpoints to and from P2MP TE LSPs. An addi- efficiently add and remove endpoints to and from P2MP TE LSPs. An
tional issue is that P2MP LSP must also handle the state "remerge" additional issue is that P2MP LSP must also handle the state "remerge"
problem, see [P2MP-REQ]. problem, see [P2MP-REQ].
These differences in P2MP state are addressed through the addition of These differences in P2MP state are addressed through the addition of
a sub-group identifier (Sub-Group ID) and sub-group originator (Sub- a sub-group identifier (Sub-Group ID) and sub-group originator
Group Originator ID) to the SENDER_TEMPLATE and FILTER_SPEC objects. (Sub-Group Originator ID) to the SENDER_TEMPLATE and FILTER_SPEC
objects. Taken together the Sub-Group ID and Sub-Group Originator ID
Taken together the Sub-Group ID and Sub-Group Originator ID are are referred to as the Sub-Group fields.
referred to as the Sub-Group fields.
The Sub-Group fields, together with rest of the SENDER_TEMPLATE and The Sub-Group fields, together with rest of the SENDER_TEMPLATE and
SESSION objects, are used to represent a portion of a P2MP LSP's 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. This portion of a P2MP LSP's state refers only to signaling
state and not data plane replication or branching. For example, it is 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 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- to not branch the data associated with the P2MP LSP. Typical
tions for generation and use of multiple subgroups are adding an applications for generation and use of multiple subgroups are adding
egress and semantic fragmentation to ensure that a Path message an egress and semantic fragmentation to ensure that a Path message
remains within a single IP packet. remains within a single IP packet.
4.4. S2L Sub-LSPs 4.4. S2L Sub-LSPs
A P2MP LSP is constituted of one or more S2L sub-LSPs. A P2MP LSP is constituted of one or more S2L sub-LSPs.
4.4.1. Representation of a S2L Sub-LSP 4.4.1. Representation of a S2L Sub-LSP
A S2L sub-LSP exists within the context of a P2MP LSP. Thus it is 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 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 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 of the P2MP SENDER_TEMPLATE object, and the S2L sub-LSP destination
address that is part of the S2L_SUB_LSP object. The S2L_SUB_LSP address that is part of the <S2L_SUB_LSP> object. The <S2L_SUB_LSP>
object is defined in section 20.3. object is defined in section 20.3.
An EXPLICIT_ROUTE Object (ERO) or P2MP SECONDARY_EXPLICIT_ROUTE An EXPLICIT_ROUTE Object (ERO) or P2MP SECONDARY_EXPLICIT_ROUTE
Object (SERO) is used to optionally specify the explicit route of a 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 S2L sub-LSP. Each ERO or a SERO that is signaled corresponds to a
particular S2L_SUB_LSP object. Details of explicit route encoding are particular <S2L_SUB_LSP> object. Details of explicit route encoding
specified in section 4.5. The SECONDARY_EXPLICIT_ROUTE Object is are specified in section 4.5. The SECONDARY_EXPLICIT_ROUTE Object is
defined in [RECOVERY], a new P2MP SECONDARY_EXPLICIT_ROUTE Object C- defined in [RECOVERY], a new P2MP SECONDARY_EXPLICIT_ROUTE Object C-
type is defined in Section 20.5 and a matching P2MP SEC- C-type is defined in Section 20.5 and a matching P2MP
ONDARY_RECORD_ROUTE Object C-type is defined in Section 20.6. SECONDARY_RECORD_ROUTE Object C-type is defined in Section 20.6.
4.4.2. S2L Sub-LSPs and Path Messages 4.4.2. S2L Sub-LSPs and Path Messages
The mechanism in this document allows a P2MP LSP to be signaled using 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 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 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 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. they also allow separate manipulation of sub-trees of the P2MP LSP.
The reason for allowing a single Path message, to signal multiple S2L The reason for allowing a single Path message, to signal multiple S2L
sub-LSPs, is to optimize the number of control messages needed to sub-LSPs, is to optimize the number of control messages needed to
setup a P2MP LSP. setup a P2MP LSP.
4.5. Explicit Routing 4.5. Explicit Routing
When a Path message signals a single S2L sub-LSP (that is, the Path When a Path message signals a single S2L sub-LSP (that is, the Path
message is only targeting a single leaf in the P2MP tree), the message is only targeting a single leaf in the P2MP tree), the
EXPLICIT_ROUTE object encodes the path from the ingress LSR to the EXPLICIT_ROUTE object encodes the path from the ingress LSR to the
egress LSR. The Path message also includes the S2L_SUB_LSP object for egress LSR. The Path message also includes the <S2L_SUB_LSP> object
the S2L sub-LSP being signaled. The < [<EXPLICIT_ROUTE>], for the S2L sub-LSP being signaled. The < [<EXPLICIT_ROUTE>],
<S2L_SUB_LSP> > tuple represents the S2L sub-LSP and is referred to <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- as the sub-LSP descriptor. The absence of the ERO should be
preted as requiring hop-by-hop routing for the sub-LSP based on the interpreted as requiring hop-by-hop routing for the sub-LSP based on
S2L sub-LSP destination address field of the S2L_SUB_LSP object. the S2L sub-LSP destination address field of the <S2L_SUB_LSP> object.
When a Path message signals multiple S2L sub-LSPs the path of the When a Path message signals multiple S2L sub-LSPs the path of the
first S2L sub-LSP, from the ingress LSR to the egress LSR, is encoded 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 in the ERO. The first S2L sub-LSP is the one that corresponds to the
first S2L_SUB_LSP object in the Path message. The S2L sub-LSPs corre- first <S2L_SUB_LSP> object in the Path message. The S2L sub-LSPs
sponding to the S2L_SUB_LSP objects that follow are termed as subse- coresponding to the <S2L_SUB_LSP> objects that follow are termed as
quent S2L sub-LSPs. One approach to encode the explicit route of a subsequent S2L sub-LSPs. In order to avoid the potential repetition
subsequent S2L sub-LSP is to include all the hops from the ingress to of path information for the parts of S2L sub-LSPs that share hops,
the egress of the S2L sub-LSP. However this implies potential repeti- this information is deduced from the explicit routes of other S2L
tion of hops that can be learned from the ERO or explicit routes of sub-LSPs using explicit route compression in SEROs.
other S2L sub-LSPs. Explicit route compression using SEROs attempts
to minimize such repetition.
The path of each subsequent S2L sub-LSP is encoded in a P2MP SEC- The path of each subsequent S2L sub-LSP is encoded in a P2MP
ONDARY_EXPLICIT_ROUTE object (SERO). The format of the SERO is the 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 same as an ERO (as defined in [RFC3209]). Each subsequent S2L sub-LSP
is represented by tuples of the form < [<P2MP SEC- is represented by tuples of the form < [<P2MP SEC-
ONDARY_EXPLICIT_ROUTE>] <S2L_SUB_LSP> >. There is a one to one corre- ONDARY_EXPLICIT_ROUTE>] <S2L_SUB_LSP> >. There is a one to one
spondence between a S2L_SUB_LSP object and a SERO. A SERO for a par- correspondence between a <S2L_SUB_LSP> object and a SERO. A SERO for a
ticular S2L sub-LSP includes only the path from a certain branch LSR particular S2L sub-LSP includes only the path from a certain branch
to the egress LSR if the path to that branch LSR can be derived from LSR to the egress LSR if the path to that branch LSR can be derived
the ERO or other SEROs. The absence of a SERO should be interpreted from the ERO or other SEROs. The absence of a SERO should be
as requiring hop-by-hop routing for that S2L sub-LSP. Note that the interpreted as requiring hop-by-hop routing for that S2L sub-LSP. Note
destination address is carried in the S2L sub-LSP object. The encod- that the destination address is carried in the S2L sub-LSP object.
ing of the SERO and S2L sub-LSP object are described in detail in The encoding of the SERO and <S2L_SUB_LSP> object are described in
section 20. detail in section 20.
Explicit route compression is illustrated using the following figure. Explicit route compression is illustrated using the following figure.
A A
| |
| |
B B
| |
| |
C----D----E C----D----E
skipping to change at page 9, line 19 skipping to change at page 9, line 17
J K L M J K L M
| | | | | | | |
| | | | | | | |
N O P Q--R N O P Q--R
Figure 1. Explicit Route Compression Figure 1. Explicit Route Compression
Figure 1. shows a P2MP LSP with LSR A as the ingress LSR and six 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 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 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- LSR F is the first S2L sub-LSP and the rest are subsequent S2L
LSPs. Following is one way for the ingress LSR A to encode the S2L sub-LSPs. Following is one way for the ingress LSR A to encode the S2L
sub-LSP explicit routes using compression: sub-LSP explicit routes using compression:
S2L sub-LSP-F: ERO = {B, E, D, C, F}, S2L_SUB_LSP Object-F S2L sub-LSP-F: ERO = {B, E, D, C, F}, <S2L_SUB_LSP> object-F
S2L sub-LSP-N: SERO = {D, G, J, N}, S2L_SUB_LSP Object-N S2L sub-LSP-N: SERO = {D, G, J, N}, <S2L_SUB_LSP> object-N
S2L sub-LSP-O: SERO = {E, H, K, O}, S2L_SUB_LSP Object-O S2L sub-LSP-O: SERO = {E, H, K, O}, <S2L_SUB_LSP> object-O
S2L sub-LSP-P: SERO = {H, L, P}, S2L_SUB_LSP Object-P, S2L sub-LSP-P: SERO = {H, L, P}, <S2L_SUB_LSP> object-P,
S2L sub-LSP-Q: SERO = {H, I, M, Q}, S2L_SUB_LSP Object-Q, S2L sub-LSP-Q: SERO = {H, I, M, Q}, <S2L_SUB_LSP> object-Q,
S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP Object-R, S2L sub-LSP-R: SERO = {Q, R}, <S2L_SUB_LSP> object-R,
After LSR E processes the incoming Path message from LSR B it sends a After LSR E processes the incoming Path message from LSR B it sends a
Path message to LSR D with the S2L sub-LSP explicit routes encoded as Path message to LSR D with the S2L sub-LSP explicit routes encoded as
follows: follows:
S2L sub-LSP-F: ERO = {D, C, F}, S2L_SUB_LSP Object-F S2L sub-LSP-F: ERO = {D, C, F}, <S2L_SUB_LSP> object-F
S2L sub-LSP-N: SERO = {D, G, J, N}, S2L_SUB_LSP Object-N S2L sub-LSP-N: SERO = {D, G, J, N}, <S2L_SUB_LSP> object-N
LSR E also sends a Path message to LSR H and following is one way to 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: 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-O: ERO = {H, K, O}, <S2L_SUB_LSP> object-O
S2L sub-LSP-P: SERO = {H, L, P}, S2L_SUB_LSP Object-P, S2L sub-LSP-P: SERO = {H, L, P}, S2L_SUB_LSP object-P,
S2L sub-LSP-Q: SERO = {H, I, M, Q}, S2L_SUB_LSP Object-Q, S2L sub-LSP-Q: SERO = {H, I, M, Q}, <S2L_SUB_LSP> object-Q,
S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP Object-R, S2L sub-LSP-R: SERO = {Q, R}, <S2L_SUB_LSP> object-R,
After LSR H processes the incoming Path message from E it sends a After LSR H processes the incoming Path message from E it sends a
Path message to LSR K, LSR L and LSR I. The encoding for the Path Path message to LSR K, LSR L and LSR I. The encoding for the Path
message to LSR K is as follows: message to LSR K is as follows:
S2L sub-LSP-O: ERO = {K, O}, S2L_SUB_LSP Object-O S2L sub-LSP-O: ERO = {K, O}, <S2L_SUB_LSP> object-O
The encoding of the Path message sent by LSR H to LSR L is as fol-
lows:
S2L sub-LSP-P: ERO = {L, P}, S2L_SUB_LSP Object-P, The encoding of the Path message sent by LSR H to LSR L is as
follows:
S2L sub-LSP-P: ERO = {L, P}, <S2L_SUB_LSP> object-P,
Following is one way for LSR H to encode the S2L sub-LSP explicit Following is one way for LSR H to encode the S2L sub-LSP explicit
routes in the Path message sent to LSR I: routes in the Path message sent to LSR I:
S2L sub-LSP-Q: ERO = {I, M, Q}, S2L_SUB_LSP Object-Q, S2L sub-LSP-Q: ERO = {I, M, Q}, <S2L_SUB_LSP> object-Q,
S2L sub-LSP-R: SERO = {Q, R}, S2L_SUB_LSP Object-R, S2L sub-LSP-R: SERO = {Q, R}, <S2L_SUB_LSP> object-R,
The explicit route encodings in the Path messages sent by LSRs D and The explicit route encodings in the Path messages sent by LSRs D and
Q are left as an exercise to the reader. Q are left as an exercise to the reader.
This compression mechanism reduces the Path message size. It also This compression mechanism reduces the Path message size. It also
reduces extra processing that can result if explicit routes are reduces extra processing that can result if explicit routes are
encoded from ingress to egress for each S2L sub-LSP. No assumptions 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 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 on the ordering of the SEROs in the Path message. All LSRs need to
process the ERO corresponding to the first S2L sub-LSP. A LSR needs process the ERO corresponding to the first S2L sub-LSP. A LSR needs
skipping to change at page 11, line 17 skipping to change at page 11, line 14
Following is the format of the S2L sub-LSP descriptor list. Following is the format of the S2L sub-LSP descriptor list.
<S2L sub-LSP descriptor list> ::= <S2L sub-LSP descriptor> <S2L sub-LSP descriptor list> ::= <S2L sub-LSP descriptor>
[ <S2L sub-LSP descriptor list> ] [ <S2L sub-LSP descriptor list> ]
<S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <P2MP SEC- <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <P2MP SEC-
ONDARY_EXPLICIT_ROUTE> ] ONDARY_EXPLICIT_ROUTE> ]
Each LSR MUST use the common objects in the Path message and the S2L Each LSR MUST use the common objects in the Path message and the S2L
sub-LSP descriptors to process each S2L sub-LSP represented by the sub-LSP descriptors to process each S2L sub-LSP represented by the
S2L sub-LSP object and the SUB-/EXPLICIT_ROUTE object combination. <S2L_SUB_LSP> object and the SECONDARY-/EXPLICIT_ROUTE object
combination.
The first S2L_SUB_LSP object's explicit route is specified by the The first <S2L_SUB_LSP> object's explicit route is specified by the
ERO. Explicit routes of subsequent S2L sub-LSPs are specified by the ERO. Explicit routes of subsequent S2L sub-LSPs are specified by the
corresponding SERO. A SERO corresponds to the following S2L_SUB_LSP corresponding SERO. A SERO corresponds to the following <S2L_SUB_LSP>
object. object.
The RRO in the sender descriptor contains the hops traversed by the The RRO in the sender descriptor contains the hops traversed by the
Path message and applies to all the S2L sub-LSPs signaled in the Path Path message and applies to all the S2L sub-LSPs signaled in the Path
message. message.
Path message processing is described in the next section. Path message processing is described in the next section.
5.2. Path Message Processing 5.2. Path Message Processing
The ingress-LSR initiates the set up of a S2L sub-LSP to each egress- The ingress-LSR initiates the set up of a S2L sub-LSP to each egress
LSR that is the destination of the P2MP LSP. Each S2L sub-LSP is 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 associated with the same P2MP LSP using common P2MP SESSION object
and <Source Address, LSP-ID> fields in the P2MP SENDER_TEMPLATE and <Sender Address, LSP-ID> fields in the P2MP SENDER_TEMPLATE
object. Hence it can be combined with other S2L sub-LSPs to form a object. Hence it can be combined with other S2L sub-LSPs to form a
P2MP LSP. Another S2L sub-LSP belonging to the same instance of this 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 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- sub-LSP. The session corresponding to the P2MP TE tunnel is
mined based on the P2MP SESSION object. Each S2L sub-LSP is identi- determined based on the P2MP SESSION object. Each S2L sub-LSP is
fied using the S2L_SUB_LSP object. Explicit routing for the S2L sub- identified using the <S2L_SUB_LSP> object. Explicit routing for the S2L
LSPs is achieved using the ERO and SEROs. sub-LSPs is achieved using the ERO and SEROs.
As mentioned earlier, it is possible to signal S2L sub-LSPs for a As mentioned earlier, it is possible to signal S2L sub-LSPs for a
given P2MP LSP in one or more Path messages. And a given Path message 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 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 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 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 message. This implies that a LSR MUST be able to receive and process
all objects listed in section 20. all objects listed in section 20.
5.2.1. Multiple Path Messages 5.2.1. Multiple Path Messages
As described in section 3, either the <EXPLICIT_ROUTE> <S2L SUB-LSP> As described in section 3, either the <EXPLICIT_ROUTE> <S2L_SUB_LSP>
or the <P2MP SECONDARY_EXPLICIT_ROUTE> <S2L_SUB_LSP> tuple is used to 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 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 P2MP LSP. Each Path message can signal one or more S2L sub-LSPs. If a
Path message contains only one S2L sub-LSP, each LSR along the S2L Path message contains only one S2L sub-LSP, each LSR along the S2L
sub-LSP follows [RFC3209] procedures for processing the Path message sub-LSP follows [RFC3209] procedures for processing the Path message
besides the S2L SUB-LSP object processing described in this document. besides the <S2L_SUB_LSP> object processing described in this docu-
ment.
Processing of Path messages containing more than one S2L sub-LSP is Processing of Path messages containing more than one S2L sub-LSP is
described in Section 5.2.2. described in Section 5.2.2.
An ingress LSR may use multiple Path messages for signaling a P2MP An ingress LSR may use multiple Path messages for signaling a P2MP
LSP. This may be because a single Path message may not be large LSP. This may be because a single Path message may not be large
enough to signal the P2MP LSP. Or it may be while adding leaves to 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 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- ingress LSR MAY choose to break the P2MP tree into separate
able P2MP trees. These trees share the same root and may share the manageable P2MP trees. These trees share the same root and may share the
trunk and certain branches. The scope of this management decomposi- trunk and certain branches. The scope of this management
tion of P2MP trees is bounded by a single tree (the P2MP Tree) and decomposition of P2MP trees is bounded by a single tree (the P2MP Tree)
multiple trees with a single leaf each (S2L sub-LSPs). Per [P2MP- and multiple trees with a single leaf each (S2L sub-LSPs). Per
REQ], a P2MP LSP MUST have consistent attributes across all portions [P2MP-REQ], a P2MP LSP MUST have consistent attributes across all
of a tree. This implies that each Path message that is used to signal portions of a tree. This implies that each Path message that is used
a P2MP LSP is signaled using the same signaling attributes with the to signal a P2MP LSP is signaled using the same signaling attributes
exception of the S2L sub-LSP information. with the exception of the S2L sub-LSP information.
The resulting sub-LSPs from the different Path messages belonging to The resulting sub-LSPs from the different Path messages belonging to
the same P2MP LSP SHOULD share labels and resources where they share the same P2MP LSP SHOULD share labels and resources where they share
hops to prevent multiple copies of the data being sent. hops to prevent multiple copies of the data being sent.
In certain cases a transit LSR may need to generate multiple Path In certain cases a transit LSR may need to generate multiple Path
messages to signal state corresponding to a single received Path mes- messages to signal state corresponding to a single received Path
sage. For instance ERO expansion may result in an overflow of the message. For instance ERO expansion may result in an overflow of the
resultant Path message. In this case the message can be decomposed resultant Path message. In this case the message can be decomposed
into multiple Path messages such that each of the messages carry a into multiple Path messages such that each of the messages carry a
subset of the X2L sub-tree carried by the incoming message. subset of the X2L sub-tree carried by the incoming message.
Multiple Path messages generated by a LSR that signal state for the Multiple Path messages generated by a LSR that signal state for the
same P2MP LSP are signaled with the same SESSION object and have the same P2MP LSP are signaled with the same SESSION object and have the
same <Source address, LSP-ID> in the SENDER_TEMPLATE object. In order same <Source address, LSP-ID> in the SENDER_TEMPLATE object. In order
to disambiguate these Path messages a <Sub-Group Originator ID, sub- to disambiguate these Path messages a <Sub-Group Originator ID,
Group ID> tuple is introduced (also referred to as the 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- field) and encoded in the SENDER_TEMPLATE object. Multiple Path
sages generated by a LSR to signal state for the same P2MP LSP have messages generated by a LSR to signal state for the same P2MP LSP
the same Sub-Group Originator ID and have a different sub-Group ID. have the same Sub-Group Originator ID and have a different sub-Group
The Sub-Group Originator ID SHOULD be set to the TE Router ID of the ID. The Sub-Group Originator ID SHOULD be set to the TE Router ID of
LSR that originates the Path message. This is either the ingress LSR the LSR that originates the Path message. This is either the ingress
or a LSR which re-originates the Path message with its own Sub-Group 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. Cases when a transit LSR may change the Sub-Group
Originator ID of an incoming Path message are described below. The 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 Originator ID, sub-Group ID> tuple is globally unique. The
sub-Group ID space is specific to the Sub-Group Originator ID. There- sub-Group ID space is specific to the Sub-Group Originator ID.
fore the combination <Sub-Group Originator ID, sub-Group ID> is net- Therefore the combination <Sub-Group Originator ID, sub-Group ID> is
work-wide unique. Also, a router that changes the Sub-Group origina- network-wide unique. Also, a router that changes the Sub-Group
tor ID of an incoming Path message MUST use the same value of the originator ID of an incoming Path message MUST use the same value of
Sub-Group Originator ID for all outgoing Path messages, for a partic- the Sub-Group Originator ID for all outgoing Path messages, for a
ular P2MP LSP, and SHOULD not vary it during the life of the P2MP particular P2MP LSP, and SHOULD not vary it during the life of the
LSP. P2MP LSP.
5.2.2. Multiple S2L Sub-LSPs in one Path message 5.2.2. Multiple S2L Sub-LSPs in one Path message
The S2L sub-LSP descriptor list allows the signaling of one or more The S2L sub-LSP descriptor list allows the signaling of one or more
S2L sub-LSPs in one Path message. It is possible to signal multiple S2L sub-LSPs in one Path message. It is possible to signal multiple
S2L sub-LSP object and ERO/SERO combinations in a single Path mes- <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 sage. Note that these two objects are the ones that differentiate a
S2L sub-LSP. S2L sub-LSP.
All LSRs MUST process the ERO corresponding to the first 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 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- be present. The first S2L sub-LSP MUST be propagated in a Path
sage by each LSR along the explicit route specified by the ERO. A LSR message by each LSR along the explicit route specified by the ERO. A
MUST process a S2L sub-LSP descriptor for a subsequent S2L sub-LSP 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 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 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 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 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. 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 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 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 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. 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 Hence a branch LSR MUST only propagate the relevant S2L sub-LSP
skipping to change at page 14, line 6 skipping to change at page 14, line 5
that is propagated on a downstream link MUST only contain those S2L that is propagated on a downstream link MUST only contain those S2L
sub-LSPs that are routed using that link. This processing MAY result 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 in a subsequent S2L sub-LSP in an incoming Path message to become the
first S2L sub-LSP in an outgoing Path message. first S2L sub-LSP in an outgoing Path message.
Note that if one or more SEROs contain loose hops, expansion of such Note that if one or more SEROs contain loose hops, expansion of such
loose hops MAY result in overflowing the Path message size. Section loose hops MAY result in overflowing the Path message size. Section
5.2.3 describes how signaling of the set of S2L sub-LSPs can be split 5.2.3 describes how signaling of the set of S2L sub-LSPs can be split
in more than one Path message. in more than one Path message.
The Record Route Object (RRO) contains the hops traversed by the Path The RECORD_ROUTE Object (RRO) contains the hops traversed by the Path
message and applies to all the S2L sub-LSPs signaled in the path mes- message and applies to all the S2L sub-LSPs signaled in the path
sage. A transit LSR MUST append its address in an incoming RRO and 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 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 the outgoing Path messages. Each such updated RRO MUST be formed
using the rules in [RFC3209]. using the rules in [RFC3209].
If a LSR is unable to support a S2L sub-LSP in a Path message, a 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 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 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, 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 all other branches are allowed to set up) and the failed branches are
reported in PathErr messages in which the Path_State_Removed flag reported in PathErr messages in which the Path_State_Removed flag
MUST NOT be set. However, the ingress LSR may set a LSP Integrity 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 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- entire LSP should fail to set up. This is described further in
tion 12. section 12.
5.2.3. Transit Fragmentation 5.2.3. Transit Fragmentation
In certain cases a transit LSR may need to generate multiple Path In certain cases a transit LSR may need to generate multiple Path
messages to signal state corresponding to a single received Path mes- messages to signal state corresponding to a single received Path
sage. For instance ERO expansion may result in an overflow of the message. For instance ERO expansion may result in an overflow of the
resultant Path message. It is desirable not to rely on IP fragmenta- resultant Path message. It is desirable not to rely on IP
tion in this case. In order to achieve this, the multiple Path mes- fragmentation in this case. In order to achieve this, the multiple Path
sages generated by the transit LSR, are signaled with the Sub-Group 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- 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 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 by the transit LSR for the P2MP LSP carries a distinct <Sub-Group
Originator ID, Sub-Group ID> tuple. Originator ID, Sub-Group ID> tuple.
When multiple Path messages are used by an ingress or transit node, When multiple Path messages are used by an ingress or transit node,
each Path message SHOULD be identical with the exception of the S2L each Path message SHOULD be identical with the exception of the S2L
sub-LSP related information (e.g., SERO), message and hop information sub-LSP related information (e.g., SERO), message and hop information
(e.g., INTEGRITY, MESSAGE_ID and RSVP_HOP), and the sub-group fields (e.g., INTEGRITY, MESSAGE_ID and RSVP_HOP), and the sub-group fields
of the SENDER_TEMPLATE objects. Except when performing a make- of the SENDER_TEMPLATE objects. Except when performing a make-
before-break operation, the tunnel sender address and LSP ID fields before-break operation as specified in section 14.1, the tunnel
MUST be the same in each message, and for transit nodes, the same as sender address and LSP ID fields MUST be the same in each message,
the values in the received Path 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 As described above one case in which the Sub-Group Originator ID of a
received Path message is changed is that of transit fragmentation. received Path message is changed is that of transit fragmentation.
The Sub-Group Originator ID of a received Path message may also be Another case is when the Sub-Group Originator ID of a received Path
changed in the outgoing Path message and set to that of the LSR orig- message may be changed in the outgoing Path message and set to that
inating the Path message based on a local policy. For instance a LSR of the LSR originating the Path message based on a local policy. For
may decide to always change the Sub-Group Originator ID while per- instance a LSR may decide to always change the Sub-Group Originator
forming ERO expansion. The Sub-Group ID MUST not be changed if the ID while performing ERO expansion. The Sub-Group ID MUST not be
Sub-Group Originator ID is not being changed. changed if the Sub-Group Originator ID is not being changed.
5.2.4. Control of Branch Fate Sharing 5.2.4. Control of Branch Fate Sharing
An ingress LSR can control the behavior of an LSP if there is a fail- An ingress LSR can control the behavior of an LSP if there is a
ure during LSP setup or after an LSP has been established. The failure during LSP setup or after an LSP has been established. The
default behavior is that only the branches downstream of the failure default behavior is that only the branches downstream of the failure
are not established, but the ingress may request 'LSP integrity' such are not established, but the ingress may request 'LSP integrity' such
that any failure anywhere within the LSP tree causes the entire P2MP that any failure anywhere within the LSP tree causes the entire P2MP
LSP to fail. LSP to fail.
The ingress LSP may request 'LSP integrity' by setting bit [TBA] of The ingress LSP may request 'LSP integrity' by setting bit [TBA] of
the Attributes Flags TLV. The bit is set if LSP integrity is the Attributes Flags TLV. The bit is set if LSP integrity is
required. required.
It is RECOMMENDED to use the LSP_ATTRIBUTES Object for this flag and It is RECOMMENDED to use the LSP_ATTRIBUTES Object for this flag and
not the LSP_REQUIRED_ATTRIBUTES Object. not the LSP_REQUIRED_ATTRIBUTES Object.
A branch LSR that supports the Attributes Flags TLV and recognizes A branch LSR that supports the Attributes Flags TLV and recognizes
this bit MUST support LSP integrity or reject the LSP setup with a this bit MUST support LSP integrity or reject the LSP setup with a
PathErr carrying the error "Routing Error"/"Unsupported LSP PathErr message carrying the error "Routing Error"/"Unsupported LSP
Integrity" Integrity"
5.3. Grafting 5.3. Grafting
The operation of adding egress LSR(s) to an existing P2MP LSP is 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 termed as grafting. This operation allows egress nodes to join a P2MP
LSP at different points in time. LSP at different points in time.
There are two methods to add S2L sub-LSPs to a P2MP LSP. The first 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 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 existing Path message and refreshing the entire Path message. Path
message processing described in section 4 results in adding these S2L 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 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 S2L sub-LSPs to a Path message the ERO compression encoding may have
to be recomputed. to be recomputed.
The second is to use incremental updates described in section 10.1. 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- The egress LSRs can be added by signaling only the impacted S2L
LSPs in a new Path message. Hence other S2L sub-LSPs do not have to sub-LSPs in a new Path message. Hence other S2L sub-LSPs do not have
be re-signaled. to be re-signaled.
6. Resv Message 6. Resv Message
6.1. Resv Message Format 6.1. Resv Message Format
The Resv message follows the [RFC3209] and [RFC3473] format: The Resv message follows the [RFC3209] and [RFC3473] format:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
skipping to change at page 16, line 47 skipping to change at page 16, line 47
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL> <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ] [ <S2L sub-LSP descriptor [ <RECORD_ROUTE> ] [ <S2L sub-LSP descriptor
list> ] list> ]
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ] <SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <S2L sub-LSP descriptor list> ] [ <S2L sub-LSP descriptor list> ]
<S2L sub-LSP descriptor list> ::= <S2L sub-LSP descriptor> <S2L sub-LSP descriptor list> ::= <S2L sub-LSP descriptor>
[ <S2L sub-LSP descriptor list> ] [ <S2L sub-LSP descriptor list> ]
<S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <P2MP SEC- <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <P2MP
ONDARY_EXPLICIT_ROUTE> ] SECONDARY_EXPLICIT_ROUTE> ]
FILTER_SPEC is defined in section 20.4. FILTER_SPEC is defined in section 20.4.
The S2L sub-LSP descriptor has the same format as in section 4.1 with The S2L sub-LSP descriptor has the same format as in section 4.1 with
the difference that a P2MP_SECONDARY_RECORD_ROUTE object is used in the difference that a P2MP_SECONDARY_RECORD_ROUTE object is used in
place of a P2MP SECONDARY_EXPLICIT_ROUTE object. The P2MP_SEC- place of a P2MP SECONDARY_EXPLICIT_ROUTE object. The P2MP_SEC-
ONDARY_RECORD_ROUTE objects follow the same compression mechanism as ONDARY_RECORD_ROUTE objects follow the same compression mechanism as
the P2MP SECONDARY_EXPLICIT_ROUTE objects. Note that that a Resv mes- the P2MP SECONDARY_EXPLICIT_ROUTE objects. Note that that a Resv
sage can signal multiple S2L sub-LSPs that may belong to the same message can signal multiple S2L sub-LSPs that may belong to the same
FILTER_SPEC object or different FILTER_SPEC objects. The same label FILTER_SPEC object or different FILTER_SPEC objects. The same label
SHOULD be allocated if the <Source Address, LSP-ID> fields of the SHOULD be allocated if the <Sender Address, LSP-ID> fields of the
FILTER_SPEC object are the same. FILTER_SPEC object are the same.
However different upstream labels are allocated if the <Source However different upstream labels are allocated if the <Sender
Address, LSP-ID> of the FILTER_SPEC object is different as that Address, LSP-ID> of the FILTER_SPEC object is different as that
implies different P2MP LSP. implies different P2MP LSP.
6.2. Resv Message Processing 6.2. Resv Message Processing
The egress LSR MUST follow normal RSVP procedures while originating a The egress LSR MUST follow normal RSVP procedures while originating a
Resv message. The Resv message carries the label allocated by the Resv message. The Resv message carries the label allocated by the
egress LSR. egress LSR.
A subsequent node MUST allocates its own label and pass it in the A subsequent node MUST allocates its own label and pass it in the
skipping to change at page 18, line 4 skipping to change at page 18, line 4
from downstream Resv messages for that P2MP LSP. Note that a transit 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 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 attached to it. Hence this results in the setup of a P2MP LSP from
the ingress-LSR to the egress LSRs. the ingress-LSR to the egress LSRs.
The ingress LSR may need to understand when all desired egresses have The ingress LSR may need to understand when all desired egresses have
been reached. This is achieved using <S2L_SUB_LSP> objects. been reached. This is achieved using <S2L_SUB_LSP> objects.
Each branch node can potentially send one Resv message upstream for Each branch node can potentially send one Resv message upstream for
each of the downstream receivers. This MAY result in overflowing the each of the downstream receivers. This MAY result in overflowing the
Resv message, particularly when considering that the number of mes- Resv message, particularly when considering that the number of
sages increases the closer the branch node is to the ingress. messages increases the closer the branch node is to the ingress of
the P2MP LSP.
Transit nodes MUST replace the Sub-Group ID fields received in the Transit nodes MUST replace the Sub-Group ID fields received in the
FILTER_SPEC objects with the value that was received in the Sub-Group FILTER_SPEC objects with the value that was received in the Sub-Group
ID field of the Path message from the upstream neighbor, when the ID field of the Path message from the upstream neighbor, when the
node set the Sub-Group Originator field in the associated Path mes- node set the Sub-Group Originator field in the associated Path mes-
sage. ResvErr messages generation is unmodified. Nodes propagating sage. ResvErr messages generation is unmodified. Nodes propagating
a received ResvErr message MUST use the Sub-Group field values car- a received ResvErr message MUST use the Sub-Group field values
ried in the corresponding Resv message. carried in the corresponding Resv message.
6.2.1. Resv Message Throttling 6.2.1. Resv Message Throttling
A branch node may have to send the Resv message being sent upstream A branch node may have to send the Resv message being sent upstream
whenever there is a change in a Resv message for a S2L sub-LSP whenever there is a change in a Resv message for a S2L sub-LSP
received from downstream. This can result in excessive Resv messages received from one of the downstream neighbors. This can result in
sent upstream, particularly when the S2L sub-LSPs are established for excessive Resv messages sent upstream,particularly when the S2L
the first time. In order to mitigate this situation, branch nodes sub-LSPs are established for the first time. In order to mitigate
can limit their transmission of Resv messages. Specifically, in the this situation, branch nodes can limit their transmission of Resv mes-
case where the only change being sent in a Resv message is in one or sages. Specifically, in the case where the only change being sent in
more SRRO objects, the branch node SHOULD transmit the Resv message a Resv message is in one or more SRRO objects, the branch node SHOULD
only after a delay time has passed since the transmission of the pre- transmit the Resv message only after a delay time has passed since
vious Resv message for the same session. This delayed Resv message the transmission of the previous Resv message for the same session.
SHOULD include SRROs for all branches. Specific mechanisms for Resv This delayed Resv message SHOULD include SRROs for all branches.
message throttling are implementation dependent and are outside the Specific mechanisms for Resv message throttling are implementation
scope of this document. dependent and are outside the scope of this document.
6.3. Record Routing 6.3. Record Routing
6.3.1. RRO Processing 6.3.1. RRO Processing
A Resv message contains a record route per S2L sub-LSP that is being 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 signaled by the Resv message if the sender node requests route
recording by including a RRO in the Path message. The same rule is recording by including a RRO in the Path message. The same rule is
used during signaling of P2MP LSP i.e. insertion of the RRO in the 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 Path message used to signal one or more S2L sub-LSP triggers the
inclusion of an RRO for each sub-LSP. inclusion of an RRO for each sub-LSP.
The record route of the first S2L sub-LSP is encoded in the RRO. The record route of the first S2L sub-LSP is encoded in the RRO.
Additional RROs for the subsequent S2L sub-LSPs are referred to as Additional RROs for the subsequent S2L sub-LSPs are referred to as
P2MP_SECONDARY_RECORD_ROUTE objects (SRROs). Their format is speci- P2MP_SECONDARY_RECORD_ROUTE objects (SRROs). Their format is speci-
fied in section 20.5. The ingress node then receives the RRO and fied in section 20.5. The ingress node then receives the RRO and
possibly the SRRO corresponding to each subsequent S2L sub-LSP. Each possibly the SRRO corresponding to each subsequent S2L sub-LSP. Each
S2L_SUB_LSP object is followed by the RRO/SRRO. The ingress node can <S2L_SUB_LSP> object is followed by the RRO/SRRO. The ingress node
then determine the record route corresponding to a particular S2L 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 sub-LSP. The RRO and SRROs can be used to construct the end to end
Path for each S2L sub-LSP. Path for each S2L sub-LSP.
6.4. Reservation Style 6.4. Reservation Style
Considerations about the reservation style in a Resv message apply as Considerations about the reservation style in a Resv message apply as
described in [RFC3209]. The reservation style in the Resv messages 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 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 Tunnel MUST be signaled with the same reservation style. Irrespective
of whether the reservation style is FF or SE, the S2L sub-LSPs that 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 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 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 labels then they MUST share resources. The S2L sub-LSPs that belong
to different P2MP LSP MUST NOT share labels. If the reservation style to different P2MP LSP MUST NOT share labels. If the reservation style
is FF than S2L Sub-LSPs that belong to different P2MP LSP MUST NOT is FF than S2L sub-LSPs that belong to different P2MP LSP MUST NOT
share resources. If the reservation style is SE than S2L sub-LSPs share resources. If the reservation style is SE than S2L sub-LSPs
that belong to different P2MP LSP and the same P2MP Tunnel SHOULD that belong to different P2MP LSP and the same P2MP Tunnel SHOULD
share resources where they share hops, but MUST not share labels. share resources where they share hops, but MUST not share labels.
7. PathTear Message 7. PathTear Message
7.1. PathTear Message Format 7.1. PathTear Message Format
The format of the PathTear message is as follows: The format of the PathTear message is as follows:
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ] <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
[ [ <MESSAGE_ID_ACK> | [ [ <MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK> ... ] <MESSAGE_ID_NACK> ... ]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
[ <sender descriptor> ] [ <sender descriptor> ]
[ <S2L sub-LSP descriptor list> ] [ <S2L sub-LSP list> ]
<sender descriptor> ::= (see earlier definition) <S2L sub-LSP list> ::= <S2L_SUB_LSP> [ <S2L sub-LSP list> ]
The definition of <sender descriptor> is not changed by this docu-
ment.
Note: it is assumed that the S2L sub-LSP descriptor will not include Note: it is assumed that the S2L sub-LSP descriptor will not include
the P2MP SECONDARY_EXPLICIT_ROUTE object associated with each the P2MP SECONDARY_EXPLICIT_ROUTE object associated with each S2L
S2L_SUB_LSP being deleted sub-LSP being deleted.
7.2. Pruning 7.2. Pruning
The operation of removing egress LSR(s) from an existing P2MP LSP is The operation of removing egress LSR(s) from an existing P2MP LSP is
termed as pruning. This operation allows egress nodes to be removed termed as pruning. This operation allows egress nodes to be removed
from a P2MP LSP at different points in time. This section describes from a P2MP LSP at different points in time. This section describes
the mechanisms to perform pruning. the mechanisms to perform pruning.
7.2.1. Implicit S2L Sub-LSP Teardown 7.2.1. Implicit S2L Sub-LSP Teardown
Implicit teardown uses standard RSVP message processing. Per standard Implicit teardown uses standard RSVP message processing. Per standard
RSVP processing, a S2L sub-LSP may be removed from a P2MP TE LSP by 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- 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- ously advertised the S2L sub-LSP. This message MUST list all S2L
LSPs that are not being removed. When using this approach, a node 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 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 MUST ensure that the S2L sub-LSP is not included in any other Path
state associated with session before interrupting the data path to state associated with session before interrupting the data path to
that egress. All other message processing remains unchanged. that egress. All other message processing remains unchanged.
When implicit teardown is used to delete one or more S2L sub-LSPs, by 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 modifying a Path message, a transit LSR may have to generate a
PathTear message downstream to delete one or more of these S2L sub- 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 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- sub-LSP(s) there are no remaining S2L sub-LSPs to send in the corre-
skipping to change at page 21, line 10 skipping to change at page 21, line 10
in the PathTear message. The transit LSR may need to generate multi- in the PathTear message. The transit LSR may need to generate multi-
ple PathTear messages for an incoming PathTear message if it had per- ple PathTear messages for an incoming PathTear message if it had per-
formed transit fragmentation for the corresponding incoming Path mes- formed transit fragmentation for the corresponding incoming Path mes-
sage. sage.
When a P2MP LSP is removed by the ingress, a PathTear message MUST be 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. generated for each Path message used to signal the P2MP LSP.
8. Notify and ResvConf Messages 8. Notify and ResvConf Messages
This section is currently under discussion between the authors and 8.1. Notify Messages
will be updated in the next revision.
Notify Request and Notify messages are described in [RFC3473]. If a The Notify Request object and Notify messages are described in
transit router sets the sub-group originator ID in the SENDER_TEM- [RFC3473]. Both object and messages SHALL be supported for delivery
PLATE object of a Path message to its own address and the Path mes- of upstream and downstream notification. Processing not detailed in
sage carries a Notify Request object then the router MUST set the this section MUST comply to [RFC3473].
notify node address in the Notify Request object to its own address.
If this router receives a corresponding Notify message from down-
stream than it MUST generate a Notify message upstream towards the
Notify node address that the router had received in the incoming Path
message. The receiver of a Notify message MUST identify the sender
state referenced in the message based on the SESSION and SENDER_TEM-
PLATE objects.
ResvConf messages are described in [RFC2205]. An egress LSR may 1. Upstream Notification
include a RESV_CONFIRM object that contains the egress LSR's address.
If a transit LSR is merging Resv messages received from more than If a transit LSR sets the Sub-Group Originator ID in the
egress LSR and one or more of these Resv messages contain a RESV_CON- SENDER_TEMPLATE object of a Path message to its own address and the
FIRM object than the transit LSR MUST set its own address in the incoming Path message carries a Notify Request object then this LSR
RESV_CONFIRM object in the Resv message that it generates. Also if MUST change the Notify node address in the Notify Request object to
the transit LSR changes the sub-group originator ID in the generated its own address in the Path message that it sends.
Resv message and it includes a RESV_CONFIRM object in the Resv mes-
sage, it MUST set its own address in the RESV_CONFIRM object. Upon If this router subsequently receives a corresponding Notify message
receiving a ResvConf message from upstream the transit LSR MUST gen- from a downstream LSR than it MUST:
erate a ResvConf message towards each of the downstream LSRs that had
included RESV_CONFIRM objects in the corresponding Resv messages. As - send a Notify message upstream toward the Notify
with Notify messages, the receiver of a ResvConf message MUST iden- node address that the LSR received in the Path message.
tify the state referenced in the message based on the SESSION and - process the sub-group fields of the SENDER_TEMPLATE
FILTER_SPEC objects. 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_TEMPLATE.
2. Downstream Notification
A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
object(s) of a Resv message to the value, that was received in the
corresponding Path message. If the incoming Resv message carries a
Notify Request object then the LSR MUST set the Notify node address
in the Notify Request object to the value, that was received in the
corresponding Path message, in the Resv message that it sends
upstream.
If this router subsequently receives a corresponding Notify message
from upstream LSR than it MUST:
- send a Notify message downstream toward the Notify
node address that the LSR received in the Resv message.
- process the sub-group fields of the FILTER_SPEC object in 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 sent downstream by this LSR.
The receiver of a (downstream) Notify message MUST identify the state
referenced in this message based on the SESSION and FILTER_SPEC
objects.
The consequence of these rules for a P2MP LSP is that an upstream
Notify message generated on a branch will result in a Notify being
delivered to the upstream Notify node address. The receiver of the
Notify message MUST NOT assume that the Notify message applies to all
downstream egresses, but MUST examine the information in the message
to determine to which egresses the 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 taken directly from [RFC2205]. An egress
LSR may include a RESV_CONFIRM object that contains the egress LSR's
address. The object and 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 in the FILTER_SPEC
object(s) of a Resv message to the value, that was received in the
corresponding Path message. If the incoming Resv message carries a
RESV_CONFIRM object then the LSR MUST include a RESV_CONFIRM object
in the corresponding Resv message that it sends upstream and MUST set
the receiver address in the RESV_CONFIRM object to the value that was
received in the corresponding Path message.
If this router subsequently receives a corresponding ResvConf message
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 Resv message.
- process the sub-group fields of the FILTER_SPEC object in the
received ResvConf message, and modify their values in the ResvConf
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 message MUST identify the state referenced
in this message based on the SESSION and FILTER_SPEC objects.
The consequence of these rules for a P2MP LSP is that a ResvConf mes-
sage generated at the ingress will result in a ResvConf message being
delivered to the branch and then to the receiver address in the orig-
inal RESV_CONFIRM object. The receiver of a ResvConf message MUST NOT
assume that the ResvConf message should be sent to all downstream
egresses, but MUST replicate the message according to the
RESV_CONFIRM objects received in Resv messages. Some downstream branches
branches might not request ResvConf messages, and ResvConf messages
SHOULD NOT be on these branches. All downstream branches that do
requested ResvConf messages MUST be sent such a message.
9. Refresh Reduction 9. Refresh Reduction
The refresh reduction procedures described in [RFC2961] are equally The refresh reduction procedures described in [RFC2961] are equally
applicable to P2MP LSP described in this document. Refresh reduction applicable to P2MP LSP described in this document. Refresh reduction
applies to individual messages and the state they install/maintain, applies to individual messages and the state they install/maintain,
and that continues to be the case for P2MP LSP. and that continues to be the case for P2MP LSP.
10. State Management 10. State Management
State signaled by a P2MP Path message is managed by a local implemen- State signaled by a P2MP Path message is managed by a local implemen-
tation using the <P2MP ID, Tunnel ID, Extended Tunnel ID> as part of tation using the <P2MP ID, Tunnel ID, Extended Tunnel ID> as part of
the SESSION object and <Tunnel Sender Address, LSP ID, Sub-Group the SESSION object and <Tunnel Sender Address, LSP ID, Sub-Group
Originator ID, Sub-Group ID> as part of the SENDER_TEMPLATE object. Originator ID, Sub-Group ID> as part of the SENDER_TEMPLATE object.
Additional information signaled in the Path message is part of the Additional information signaled in the Path/Resv message is part of
state created by a local implementation. This mandatorily includes the state created by a local implementation. This mandatorily
PHOP and SENDER_TSPEC object. includes PHOP/NHOP and SENDER_TSPEC/FILTER_SPEC object.
10.1. Incremental State Update 10.1. Incremental State Update
RSVP as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and RSVP as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and
GMPLS [RFC3473] uses the same basic approach to state communication GMPLS [RFC3473] uses the same basic approach to state communication
and synchronization, namely full state is sent in each state adver- and synchronization, namely full state is sent in each state adver-
tisement message. Per [RFC2205] Path and Resv messages are idempo- tisement message. Per [RFC2205] Path and Resv messages are idempo-
tent. Also, [RFC2961] categorizes RSVP messages into two types: trig- tent. Also, [RFC2961] categorizes RSVP messages into two types: trig-
ger and refresh messages and improves RSVP message handling and scal- ger and refresh messages and improves RSVP message handling and scal-
ing of state refreshes but does not modify the full state advertise- ing of state refreshes but does not modify the full state advertise-
skipping to change at page 23, line 21 skipping to change at page 24, line 43
ferent Path messages in a single Path message in order to reduce the 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 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 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- 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 ated into a single Path message. This may happen when one or more S2L
sub-LSPs are pruned from the existing Path states. sub-LSPs are pruned from the existing Path states.
The new Path message is signaled by the node that is combining multi- 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 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- in a single Path message. This Path message MAY contain a new Sub-
Group ID field value. When a new Path and Resv message that is sig- Sub-Group ID field value. When a new Path and Resv message that is
naled for an existing S2L sub-LSP is received by a transit LSR, state signaled for an existing S2L sub-LSP is received by a transit LSR,
including the new instance of the S2L sub-LSP is created. 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 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 new Path messages until a Resv message listing the S2L sub-LSP and
corresponding to the new Path message is received by the combining corresponding to the new Path message is received by the combining
node. Hence until this point state for the S2L sub-LSP SHOULD be 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 maintained as part of the Path state for both the old and the new
Path message [Section 3.1.3, 2205]. At that point the S2L sub-LSP Path message [Section 3.1.3, RFC2205]. At that point the S2L sub-LSP
SHOULD be deleted from the old Path state using the procedures of SHOULD be deleted from the old Path state using the procedures of
section 7. section 7.
A Path message with a sub-Group_ID(n) may signal a set of S2L sub- A Path message with a sub-Group_ID(n) may signal a set of S2L
LSPs that belong partially or entirely to an already existing Sub- sub-LSPs that belong partially or entirely to an already existing
Group_ID(i), the SESSION object and <Sender Tunnel Address, LSP-ID, Sub-Group_ID(i), the SESSION object and <Sender Tunnel Address,
Sub-Group Originator ID> being the same. Or it may signal a strictly LSP-ID, Sub-Group Originator ID> being the same. Or it may signal a
non-overlapping new set of S2L sub-LSPs with a strictly higher sub- strictly non-overlapping new set of S2L sub-LSPs with a strictly higher
Group_ID value. sub-Group_ID value.
1) If sub-Group_ID(i) = sub-Group_ID(n), then either a full refresh 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 is indicated by the Path message or a S2L Sub-LSP is added to/deleted
from the group signaled by sub-Group_ID(n) from the group signaled by sub-Group_ID(n)
2) If sub-Group_ID(i) != sub-Group_ID(n), then the Path message is 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 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 an already existing Sub-Group_ID(i) or a strictly non-overlapping set
of S2L sub-LSPs. of S2L sub-LSPs.
skipping to change at page 24, line 19 skipping to change at page 25, line 39
lar S2L sub-LSP changes the state only for that S2L sub-LSP. Hence 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 other S2L sub-LSPs are not impacted. In case the ingress node
requests the maintenance of the 'LSP integrity', any error reported requests the maintenance of the 'LSP integrity', any error reported
within the P2MP TE LSP must be reported at (least at) any other within the P2MP TE LSP must be reported at (least at) any other
branching nodes belonging to this LSP. Therefore, reception of an branching nodes belonging to this LSP. Therefore, reception of an
error message for a particular S2L sub-LSP MAY change the state of error message for a particular S2L sub-LSP MAY change the state of
any other S2L sub- LSP of the same P2MP TE LSP. any other S2L sub- LSP of the same P2MP TE LSP.
11.1. PathErr Messages 11.1. PathErr Messages
The PathErr message will include one or more S2L_SUB_LSP objects. The The PathErr message will include one or more <S2L_SUB_LSP> objects.
resulting modified format for a PathErr Message is: The resulting modified format for a PathErr message is:
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ] <PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | [ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ] <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC> <SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ] [ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<sender descriptor> <sender descriptor>
[ <S2L sub-LSP descriptor list> ] [ <S2L sub-LSP descriptor list> ]
skipping to change at page 24, line 43 skipping to change at page 26, line 17
Sub-Group Originator field and propagate a received PathErr message Sub-Group Originator field and propagate a received PathErr message
upstream MUST replace the Sub-Group fields received in the PathErr upstream MUST replace the Sub-Group fields received in the PathErr
message with the value that was received in the Sub-Group fields of message with the value that was received in the Sub-Group fields of
the Path message from the upstream neighbor. Note the receiver of a the Path message from the upstream neighbor. Note the receiver of a
PathErr message is able to identify the errored outgoing Path mes- PathErr message is able to identify the errored outgoing Path mes-
sage, and outgoing interface, based on the Sub-Group fields received sage, and outgoing interface, based on the Sub-Group fields received
in the PathErr message. in the PathErr message.
11.2. ResvErr Messages 11.2. ResvErr Messages
The ResvErr message will include one or more S2L_SUB_LSP objects. The The ResvErr message will include one or more <S2L_SUB_LSP> objects.
resulting modified format for a ResvErr Message is: The resulting modified format for a ResvErr Message is:
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ] <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | [ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ] <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ] <ERROR_SPEC> [ <SCOPE> ]
[ <ACCEPTABLE_LABEL_SET> ... ] [ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
skipping to change at page 25, line 29 skipping to change at page 27, line 5
During setup and during normal operation, PathErr messages may be During setup and during normal operation, PathErr messages may be
received at a branch node. In all cases, a received PathErr message received at a branch node. In all cases, a received PathErr message
is first processed per standard processing rules. That is: the is first processed per standard processing rules. That is: the
PathErr message is sent hop-by-hop to the ingress/branch LSR for that PathErr message is sent hop-by-hop to the ingress/branch LSR for that
Path message. Intermediate nodes until this ingress/branch LSR MAY Path message. Intermediate nodes until this ingress/branch LSR MAY
inspect this message but take no action upon it. The behavior of a inspect this message but take no action upon it. The behavior of a
branch LSR that generates a PathErr message is under the control of branch LSR that generates a PathErr message is under the control of
the ingress LSR. the ingress LSR.
The default behavior is that the PathErr does not have the The default behavior is that the PathErr message does not have the
Path_State_Removed flag set. However, if the ingress LSR has set the Path_State_Removed flag set. However, if the ingress LSR has set the
'LSP integrity' flag on the Path message (see LSP_ATTRIBUTE object in LSP integrity flag on the Path message (see LSP_ATTRIBUTE object in
section 20) and if the Path_State_Removed flag is supported, the LSR 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 generating a PathErr to report the failure of a branch of the P2MP
LSP SHOULD set the Path_State_Removed flag. LSP SHOULD set the Path_State_Removed flag.
A branch LSR that receives a PathErr message with the A branch LSR that receives a PathErr message with the
Path_State_Removed flag set MUST act according to the wishes of 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 ingress LSR. The default behavior is that the branch LSR clears the
Path_State_Removed flag on the PathErr and sends it further upstream. 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 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 integrity flag is set on the Path message, the branch LSR MUST send
PathTear on all downstream branches and send the PathErr message PathTear on all other downstream branches and send the PathErr mes-
upstream with the Path_State_Removed flag set. sage upstream with the Path_State_Removed flag set.
A branch LSR that receives a PathErr message with the A branch LSR that receives a PathErr message with the
Path_State_Removed flag clear MUST act according to the wishes of the Path_State_Removed flag clear MUST act according to the wishes of the
ingress LSR. The default behavior is that the branch LSR forwards the ingress LSR. The default behavior is that the branch LSR forwards the
PathErr upstream and takes no further action. However, if the LSP PathErr upstream and takes no further action. However, if the LSP
integrity flag is set on the Path message, the branch LSR MUST send integrity flag is set on the Path message, the branch LSR MUST send
PathTear on all downstream branches and send the PathErr upstream PathTear on all downstream branches and send the PathErr upstream
with the Path_State_Removed flag set (per [RFC3473]). with the Path_State_Removed flag set (per [RFC3473]).
In all cases, the PathErr message forwarded by a branch LSR MUST con- In all cases, the PathErr message forwarded by a branch LSR MUST con-
skipping to change at page 27, line 40 skipping to change at page 29, line 10
ing to the new Path message is received by the re-optimizing node. At 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 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- the procedures of section 7. Sub-tree re-optimization is then com-
pleted. pleted.
As is always the case, a node may choose to combine multiple path As is always the case, a node may choose to combine multiple path
messages as described in section 10.2. messages as described in section 10.2.
15. Fast Reroute 15. Fast Reroute
[RSVP-FR] extensions can be used to perform fast reroute for the [RFC4090] extensions can be used to perform fast reroute for the
mechanism described in this document. mechanism described in this document.
15.1. Facility Backup 15.1. Facility Backup
Facility backup as described in [RSVP-FR] can be used to protect P2MP Facility backup as described in [RFC4090] can be used to protect P2MP
LSPs. LSPs.
If link protection is desired, a bypass tunnel is used to protect the If link protection is desired, a bypass tunnel is used to protect the
link between the PLR and next-hop. Thus all S2L sub-LSPs that use the link between the PLR and next-hop. Thus all S2L sub-LSPs that use the
link can be protected in the event of link failure. Note that all link can be protected in the event of link failure. Note that all
such S2L sub-LSPs belonging to a particular instance of a P2MP tunnel such S2L sub-LSPs belonging to a particular instance of a P2MP tunnel
will share the same outgoing label on the link between the PLR and will share the same outgoing label on the link between the PLR and
the next-hop. This is the P2MP LSP label on the link. Label stacking the next-hop. This is the P2MP LSP label on the link. Label stacking
is used to send data for each P2MP LSP in the bypass tunnel. The is used to send data for each P2MP LSP in the bypass tunnel. The
inner label is the P2MP LSP label allocated by the nhop. During fail- inner label is the P2MP LSP label allocated by the nhop. During fail-
skipping to change at page 28, line 29 skipping to change at page 29, line 37
sent to the MP, by the PLR. It is recommended that the PLR use the sent to the MP, by the PLR. It is recommended that the PLR use the
sender template specific method to identify these Path messages. sender template specific method to identify these Path messages.
Hence the PLR will set the source address in the sender template to a 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- local PLR address. The MP will use the LSP-ID to identify the corre-
sponding S2L sub-LSPs. sponding S2L sub-LSPs.
The MP MUST not use the <sub-group originator ID, sub-group ID> while The MP MUST not use the <sub-group originator ID, sub-group ID> while
identifying the corresponding S2L sub-LSPs. identifying the corresponding S2L sub-LSPs.
In order to further process a S2L sub-LSP it will determine the pro- 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 object. tected S2L sub-LSP using the LSP-id and the <S2L_SUB_LSP> object.
If node protection is desired, the bypass P2P tunnel must intersect 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 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 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- 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. 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- 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 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 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 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 tunnel label. During failure of the protected node the PLR will send
Path messages for the protected S2L Sub-LSPs to the MP using proce- Path messages for the protected S2L sub-LSPs to the MP using
dures that are same as the link protection procedures described procedures that are same as the link protection procedures described
above. Node protection may require the PLR to be branch capable as 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- 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 LSPs passing through the protected node. Else all the S2L sub-LSPs
passing through the protected node must also pass through a MP that passing through the protected node must also pass through a MP that
is downstream from the protected node. is downstream from the protected node.
15.2. One to One Backup 15.2. One to One Backup
One to one backup as described in [RSVP-FR] can be used to protect a One to one backup as described in [RFC4090] can be used to protect a
particular S2L sub-LSP against link and next-hop failure. Protection particular S2L sub-LSP against link and next-hop failure. Protection
may be used for one or more S2L sub-LSPs between the PLR and the may be used for one or more S2L sub-LSPs between the PLR and the
next-hop. All the S2L sub-LSPs corresponding to the same instance of next-hop. All the S2L sub-LSPs corresponding to the same instance of
the P2MP tunnel, between the PLR and the next-hop share the same P2MP the P2MP tunnel, between the PLR and the next-hop share the same P2MP
LSP label. LSP label.
All or some of these S2L sub-LSPs may be protected. All or some of these S2L sub-LSPs may be protected.
The detour S2L sub-LSPs may or may not share labels, depending on the The detour S2L sub-LSPs may or may not share labels, depending on the
detour path. Thus the set of outgoing labels and next-hops for a P2MP detour path. Thus the set of outgoing labels and next-hops for a P2MP
skipping to change at page 31, line 30 skipping to change at page 32, line 38
PE1 can setup a P2P LSP to P1 and use that as a LSP segment. The Path PE1 can setup a P2P LSP to P1 and use that as a LSP segment. The Path
messages for PE3 and PE4 can now be tunneled over the LSP segment. messages for PE3 and PE4 can now be tunneled over the LSP segment.
Thus P3 is not aware of the P2MP LSP and does not process the P2MP Thus P3 is not aware of the P2MP LSP and does not process the P2MP
control messages. control messages.
18. P2MP LSP Remerging and Cross-Over 18. P2MP LSP Remerging and Cross-Over
This section is currently under discussion between the authors and This section is currently under discussion between the authors and
will be updated in the next revision. will be updated in the next revision.
The functional description described so far assumes that multiple This section details the procedures for detecting and dealing with
Path messages received by a LSR for the same P2MP LSP arrive on the re-merge and cross-over. The term re-merge refers to the case of an
same incoming interface. However this may not always be the case. ingress or transit node that creates a branch of a P2MP LSP, a re-
merge branch, which intersects the P2MP LSP at another node farther
down the tree. This may occur due to such events as an error in path
calculation, an error in manual configuration, or network topology
changes during the establishment of the P2MP LSP. If the procedures
detailed in this section are not followed, data duplication will
result.
P2MP tree remerging or cross-over occurs when a transit or egress The term cross-over refers to the case of an ingress or transit node
node receives the signaling state i.e. Path message for the same P2MP that creates a branch of a P2MP LSP, a cross-over branch, which
TE LSP from more than one previous hop. If the remerged S2L sub-LSPs intersects the P2MP LSP at another node farther down the tree. It is
are sent out on different interfaces there is no data plane issue. unlike re-merge in that at the intersecting node the cross-over
However if the remerged S2L sub-LSPs are sent out on the same inter- branch has a different outgoing interface as well as a different
face it can result in data duplication downstream. In order to incoming interface. This may be necessary in certain combinations of
describe identification of cross over and remerging by a LSR let us topology and technology; e.g., in a transparent optical network in
list the various cases when state for a S2L sub-LSP is received by a which different wavelengths are required to reach different leaf
LSR. nodes.
Case1: S2L sub-LSP already exist as part of an existing Path state. Normally, a P2MP LSP has a single incoming interface on which all of
The following are the various sub-cases. the Path messages associated with that P2MP LSP are received. The
a) The new S2L sub-LSP uses the same PHOP and outgoing interface incoming interface is identified by the IF_ID RSVP_HOP Object, if
as the existing S2L sub-LSP. This is either a refresh or can occur present, and by interface over which the Path message was received if
when multiple existing Path messages are combined in a new Path mes- the IF_ID RSVP_HOP Object is not present. However, in the case of
sage. dynamic LSP re-routing, the incoming interface may change.
b) The new S2L sub-LSP uses the same PHOP but different outgoing Similarly, in both the re-merge case and cross-over cases, a node
interface as the existing S2L sub-LSP. This is a case of re-routing. will receive a Path message for a given P2MP LSP on a different
c) The new S2L sub-LSP uses a different PHOP and same outgoing incoming interface, and the node needs to be able to distinguish
interface as the existing S2L sub-LSP. This is a case of re-routing. between dynamic LSP re-routing and the re-merge/cross-over cases.
d) The new S2L sub-LSP uses a different PHOP and a different out-
going interface as compared to the existing S2L sub-LSP. This is a
case of re-routing.
Case2: S2L sub-LSP does not exist as part of an existing Path state. (Make-before-break represents yet another similar but different case,
The following are the sub-cases. in that the incoming interface associated with the make-before-break
a) The new S2L sub-LSP uses a PHOP and outgoing interface that is P2MP LSP may be different than that associated with the original P2MP
same as the PHOP and outgoing interface used by an existing S2L sub- LSP. However, the two P2MP LSPs will be treated as distinct, but
LSP that belongs to the same P2MP LSP. This is a legal case of sig- related, LSPs because they will have different LSP ID field values in
naling a new S2L sub-LSP. their SENDER_TEMPLATE objects.)
b) The new S2L sub-LSP uses a PHOP that is same as that used by an
existing S2L sub-LSP. However the outgoing interface is different
from the outgoing interfaces used by existing S2L sub-LSPs belonging
to the same P2MP LSP. This is a legal case of signaling a new S2L
sub-LSP.
c) The new S2L sub-LSP uses a different PHOP than that used by any
of the existing S2L sub-LSP that belong to the same P2MP LSP . How-
ever the outgoing interface is same as the outgoing interface used by
an existing S2L sub-LSPs. This is a case of remerging.
d) The new S2L sub-LSP uses a different PHOP than that used by any
of the existing S2L sub-LSP that belong to the same P2MP LSP. Also
the outgoing interface is different from the outgoing interfaces used
by existing S2L sub-LSPs. This is a case of cross-over.
Case 2(d) above identifies cross-over and this is considered legal. 18.1. Procedures
Case 2(c) above identifies remerging in the data plane. If the LSR is
capable of remerging in the data plane this is considered legal.
The below procedure applies for remerging. 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.
The remerge error case is detected by checking incoming Path messages Dynamic LSP rerouting is identified by checking whether there is any
that represent new P2MP TE LSP state and seeing if they represent intersection between the set of SUB-LSP objects associated with the
both known LSP state and a different S2L sub-LSP list. Specifically, matching P2MP LSP Path state and the set of SUB-LSP objects in the
the remerge check MUST be performed when processing Path messages received Path message. If there is any intersection, then dynamic
that contain SESSION, SENDER_TEMPLATE and RSVP_HOP objects that have re-routing has occurred. If there is no intersection between the two
not previously been seen on a particular interface. The remerge check sets of SUB-LSP objects, then either re-merge or cross-over has
consists of attempting to locate state that has the same values in occurred. (Note that in the case of dynamic LSP rerouting, Path mes-
the SESSION object and in the tunnel sender address and LSP ID fields sages for the non-intersecting members of set of SUB-LSPs associated
of the SENDER_TEMPLATE object. with the matching P2MP LSP Path state will be received subsequently
on the new incoming interface.)
If no matching state is located, then there is no remerge condition. 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.
If matching state is found, then the list of S2L Sub-LSPs associated 18.1.1. Re-Merge Procedures
with the new Path message is compared against the list present in the
located state. If any addresses in the lists of S2L sub-LSPs match,
then it is the legal LSP rerouting case mentioned here above.
If there are no overlap in the lists, the node checks whether any of There are two approaches to dealing with re-merge case. In the
the outgoing interfaces, as identified by the ERO/SUB_EROs, are an first, the node detecting the re-merge case, i.e., the re-merge node,
outgoing interface already associated with the existing P2MP LSP. If allows the re-merge case to persist but data from all but one incom-
not, then legal LSP crossing is being performed. Else re-merging has ing interface is dropped at the re-merge node. In the second, the
occurred and if the LSR is capable of remerging in the data plane, re-merge node initiates the removal of the re-merge branch(es) via
this is considered legal. In that case the LSR will return the label signaling. Which approach is used is a matter of local policy. A
already associated with the existing S2L sub-LSP with the matching node MUST support both approaches and MUST allow user configuration
egress interface, in the Resv message it sends upstream. If the LSR of which approach is to be used.
is not capable of remerging in the data plane the new Path message
MUST be handled according to remerge error processing as described
below.
The LSR generates a PathErr message with Error Code "Routing Prob- When configured to allow a re-merge case to persist, the re-merge
lem/P2MP Remerge Detected" towards the upstream node (i.e. the node node MUST validate consistency between the objects included the
that sent the Path message) until it reaches the node that caused the received Path message and the matching P2MP LSP Path state. Any
remerge condition. Identification of the offending node requires inconsistencies MUST result in an appropriate PathErr message sent to
special processing by the nodes upstream of the error. A node that the previous hop of the received Path message. The error code is set
receives a PathErr message that contains the error "Routing Prob- to "Routing Problem" and the error value is set to "P2MP Re-Merge
lem/P2MP Remerge Detected" MUST check to see if it is the offending Parameter Mistmatch".
node. This check is done by comparing the S2L sub-LSPs listed in the
PathErr message with existing LSP state. If any of the egresses are
already present in any Path state associated with the P2MP TE LSP
other than the one associated with the <SESSION, SENDER_TEMPLATE>
objects signaled in the PathErr message, then the node is the signal-
ing branch node that caused the remerge condition. This node SHOULD
then correct the remerge condition by adding all S2L sub-LSPs listed
in the offending Path state to the Path state (and Path message)
associated to these S2L sub-LSPs. Note that the new Path state may be
sent out the same outgoing interface in different Path messages in
order to meet IP packet size limitations. If use of a new outgoing
interface violates one or more SERO constraint, then a PathErr mes-
sage containing the associated egresses and any identified valid
egresses 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. If there are no inconsistencies, the node logically merges, from the
The only case where this process will fail is when all the listed S2L downstream perspective, the control state of incoming Path message
sub-LSPs are deleted prior to the PathErr message propagating to the with the matching P2MP LSP Path state. Specifically, procedures
ingress. In this case, the whole process will be corrected on the related to processing of messages received from upstream MUST NOT be
next (refresh or trigger) transmission of the offending Path message. 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 complete <S2L sub-LSP descriptor list> into sub-
sets that match the incoming Path messages and then constructing an
outgoing Resv message for each incoming Path message.
In all cases where a remerge error is not detected, normal processing When configured to allow a re-merge case to persist, the re-merge
continues. node receives data associated with the P2MP LSP on multiple incoming
interfaces, but it may only send the data from one of these inter-
faces to its outgoing interfaces, i.e., the node MUST drop data from
all but one incoming interface. This ensures that duplicate data is
not sent on any outgoing interface. The mechanism used to select the
incoming interface to use is implementation specific and is outside
the scope of this document.
When configured to correct the re-merge branch via signaling, the re-
merge node MUST send a PathErr message corresponding to the received
Path message. The PathErr message MUST include all of the objects
normally included in a PathErr message, as well as one or more SUB-
LSP objects from the set of sub-LSPs associated with the matching
P2MP LSP Path state. A minimum of three SUB-LSP objects is RECOM-
MENDED. This will allow the node that caused the re-merge to identify
the outgoing Path state associated with the valid portion of the P2MP
LSP. The PathErr message MUST include the error code "Routing Prob-
lem" and error value of "P2MP Remerge Detected". The node MAY set the
Path_State_Removed flag [RFC3473]. As is always the case, the
PathErr message is sent to the previous hop of the received Path mes-
sage.
A node that receives a PathErr message that contains the error "Rout-
ing Problem/P2MP Remerge Detected" MUST determine if it is the node
that created the re-merge case. This is done by checking whether
there is any intersection between the set of SUB-LSP objects associ-
ated with the matching P2MP LSP Path state and the set of SUB-LSP
objects in the received PathErr message. If there is, then the node
created the re-merge case.
The node SHOULD remove the re-merge case by moving the SUB-LSP
objects included in the Path message associated with the received
PathErr message to the outgoing interface associated with the match-
ing P2MP LSP Path state. A trigger Path message for the moved SUB-
LSP objects is then sent via that outgoing interface. If the
received PathErr message did not have the Path_State_Removed flag
set, the node SHOULD send a PathTear via the outgoing interface asso-
ciated with the re-merge branch.
If use of a new outgoing interface violates one or more SERO con-
straint, then a PathErr message containing the associated egresses
and any identified SUB-LSP objects SHOULD be generated with the error
code "Routing Problem" and error value of "ERO Resulted in Remerge".
The only case where this process will fail is when all the listed
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 mes-
sage.
19. New and Updated Message Objects 19. New and Updated Message Objects
This section presents the RSVP object formats as modified by this This section presents the RSVP object formats as modified by this
document. document.
19.1. SESSION Object 19.1. SESSION Object
A P2MP LSP SESSION object is used. This object uses the existing SES- A P2MP LSP SESSION object is used. This object uses the existing
SION C-Num. New C-Types are defined to accommodate a logical P2MP SESSION C-Num. New C-Types are defined to accommodate a logical P2MP
destination identifier of the P2MP Tunnel. This SESSION object has a destination identifier of the P2MP Tunnel. This SESSION object has a
similar structure as the existing point to point RSVP-TE SESSION similar structure as the existing point to point RSVP-TE SESSION
object. However the destination address is set to the P2MP ID instead object. However the destination address is set to the P2MP ID
of the unicast Tunnel Endpoint address. All S2L sub-LSPs part of the instead of the unicast Tunnel Endpoint address. All S2L sub-LSPs part
same P2MP LSP share the same SESSION object. This SESSION object of the same P2MP LSP share the same SESSION object. This SESSION
identifies the P2MP Tunnel. object identifies the P2MP Tunnel.
The combination of the SESSION object, the SENDER_TEMPLATE object and The combination of the SESSION object, the SENDER_TEMPLATE object and
the S2L SUB-LSP object, identifies each S2L sub-LSP. This follows the the <S2L_SUB_LSP> object, identifies each S2L sub-LSP. This follows
existing P2P RSVP-TE notion of using the SESSION object for identify- the existing P2P RSVP-TE notion of using the SESSION object for iden-
ing a P2P Tunnel which in turn can contain multiple LSPs, each dis- tifying a P2P Tunnel which in turn can contain multiple LSPs, each
tinguished by a unique SENDER_TEMPLATE object. distinguished by a unique SENDER_TEMPLATE object.
19.1.1. P2MP LSP Tunnel IPv4 SESSION Object 19.1.1. P2MP LSP Tunnel IPv4 SESSION Object
Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = TBA Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = TBA
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID | | P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 35, line 21 skipping to change at page 37, line 28
all zeros. Ingress nodes that wish to narrow the scope of a all zeros. Ingress nodes that wish to narrow the scope of a
SESSION to the ingress-PID pair may place their IPv4 address SESSION to the ingress-PID pair may place their IPv4 address
here as a globally unique identifier [RFC3209]. here as a globally unique identifier [RFC3209].
19.1.2. P2MP LSP Tunnel IPv6 SESSION Object 19.1.2. P2MP LSP Tunnel IPv6 SESSION Object
This is same as the P2MP IPv4 LSP SESSION Object with the difference This is same as the P2MP IPv4 LSP SESSION Object with the difference
that the extended tunnel ID may be set to a 16 byte identifier that the extended tunnel ID may be set to a 16 byte identifier
[RFC3209]. [RFC3209].
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 19.2. SENDER_TEMPLATE object
The sender template contains the ingress-LSR source address. LSP ID The SENDER_TEMPLATE object contains the ingress-LSR source address.
can be can be changed to allow a sender to share resources with LSP ID can be can be changed to allow a sender to share resources
itself. Thus multiple instances of the P2MP tunnel can be created, with itself. Thus multiple instances of the P2MP tunnel can be cre-
each with a different LSP ID. The instances can share resources with ated, each with a different LSP ID. The instances can share resources
each other, but use different labels. The S2L sub-LSPs corresponding with each other, but use different labels. The S2L sub-LSPs corre-
to a particular instance use the same LSP ID. sponding to a particular instance use the same LSP ID.
As described in section 4.2 it is necessary to distinguish different As described in section 4.2 it is necessary to distinguish different
Path messages that are used to signal state for the same P2MP LSP by 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 using a <Sub-Group ID Originator ID, Sub-Group ID> tuple. The
SENDER_TEMPLATE object is modified to carry this information as shown SENDER_TEMPLATE object is modified to carry this information as shown
below. below.
19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object 19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object
Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = TBA Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = TBA
skipping to change at page 37, line 18 skipping to change at page 39, line 43
IPv6 tunnel sender address IPv6 tunnel sender address
See [RFC3209] See [RFC3209]
Sub-Group Originator ID Sub-Group Originator ID
The Sub-Group Originator ID is set to the IPv6 TE Router 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 of the LSR that originates the Path message. This is either
the ingress LSR or a LSR which re-originates the Path the ingress LSR or a LSR which re-originates the Path
message with its own Sub-Group Originator ID. message with its own Sub-Group Originator ID.
Sub-Group ID Sub-Group ID
As above. As above in section 19.2.2.
LSP ID LSP ID
See [RFC3209] See [RFC3209]
19.3. S2L SUB-LSP Object 19.3. <S2L_SUB_LSP> Object
A new S2L Sub-LSP object identifies a particular S2L sub-LSP belong- A new <S2L_SUB_LSP> object identifies a particular S2L sub-LSP
ing to the P2MP LSP. belonging to the P2MP LSP.
19.3.1. S2L SUB-LSP IPv4 Object 19.3.1. <S2L_SUB_LSP> IPv4 Object
SUB_LSP Class = 50, S2L_SUB_LSP_IPv4 C-Type = TBA SUB_LSP Class = 50, S2L_SUB_LSP_IPv4 C-Type = TBA
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 S2L Sub-LSP destination address | | IPv4 S2L Sub-LSP destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Sub-LSP destination address IPv4 Sub-LSP destination address
IPv4 address of the S2L sub-LSP destination. IPv4 address of the S2L sub-LSP destination.
19.3.2. S2L SUB-LSP IPv6 Object 19.3.2. <S2L_SUB_LSP> IPv6 Object
SUB_LSP Class = 50, S2L_SUB_LSP_IPv6 C-Type = TBA SUB_LSP Class = 50, S2L_SUB_LSP_IPv6 C-Type = TBA
This is same as the S2L IPv4 Sub-LSP object, with the difference that This is same as the S2L IPv4 Sub-LSP object, with the difference that
the destination address is a 16 byte IPv6 address. the destination address is a 16 byte IPv6 address.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 S2L Sub-LSP destination address | | IPv6 S2L Sub-LSP destination address (16 bytes) |
| .... | | .... |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
19.4. FILTER_SPEC Object 19.4. FILTER_SPEC Object
The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
object. object.
19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object 19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object
skipping to change at page 38, line 43 skipping to change at page 41, line 23
Class = FILTER SPEC, P2MP LSP_IPv6 C-Type = TBA Class = FILTER SPEC, P2MP LSP_IPv6 C-Type = TBA
The format of the P2MP LSP_IPv6 FILTER_SPEC object is identical to The format of the P2MP LSP_IPv6 FILTER_SPEC object is identical to
the P2MP LSP_IPv6 SENDER_TEMPLATE object. the P2MP LSP_IPv6 SENDER_TEMPLATE object.
19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) 19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO)
The P2MP Secondary Explicit Route Object (SERO) is defined as identi- 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 cal to the ERO. The class of the P2MP SERO is the same as the SERO
defined in [RECOVERY] (TBA). The P2MP SERO C-Type = TBA The sub- defined in [RECOVERY]. The P2MP SERO uses a new C-Type = 2. The sub-
objects are identical to those defined for the ERO. objects are identical to those defined for the ERO.
19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO) 19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO)
The P2MP Secondary Record Route Object (SRRO) is defined as identical The P2MP SECONDARY_RECORD_ROUTE Object (SRRO) is defined as identical
to the ERO. The class of the P2MP SRRO is the same as the SRRO to the ERO. The class of the P2MP SRRO is the same as the SRRO
defined in [RECOVERY] (TBA). The P2MP SRRO C-Type = TBA. The sub- defined in [RECOVERY]. The P2MP SRRO uses a new C-Type = 2. The sub-
objects are identical to those defined for the RRO. objects are identical to those defined for the RRO.
20. IANA Considerations 20. IANA Considerations
20.1. New Class Numbers 20.1. New Class Numbers
IANA is requested to assign the following Class Numbers for the new 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 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- assigned via standards action. The sub-object types for the P2MP
ONDARY_EXPLICIT_ROUTE and P2MP_SECONDARY_RECORD_ROUTE follow the same SECONDARY_EXPLICIT_ROUTE and P2MP_SECONDARY_RECORD_ROUTE follow the
IANA considerations as those of the ERO and RRO [RFC3209]. same IANA considerations as those of the ERO and RRO [RFC3209].
50 Class Name = SUB_LSP 50 Class Name = SUB_LSP
C-Type C-Type
1 S2L_SUB_LSP_IPv4 C-Type 1 S2L_SUB_LSP_IPv4 C-Type
2 S2L_SUB_LSP_IPv6 C-Type 2 S2L_SUB_LSP_IPv6 C-Type
20.2. New Class Types 20.2. New Class Types
IANA is requested to assign the following C-Type values: IANA is requested to assign the following C-Type values:
skipping to change at page 40, line 18 skipping to change at page 42, line 43
C-Type C-Type
2 P2MP_SECONDARY_RECORD_ROUTE C-Type 2 P2MP_SECONDARY_RECORD_ROUTE C-Type
20.3. New Error Codes 20.3. New Error Codes
Four new Error Codes are defined for use with the Error Value "Rout- Four new Error Codes are defined for use with the Error Value "Rout-
ing Problem". IANA is requested to assign values. ing Problem". IANA is requested to assign values.
The Error Code "Unable to Branch" indicates that a P2MP branch cannot The Error Code "Unable to Branch" indicates that a P2MP branch cannot
be formed by the reporting LSR. IANA is requested to assign value 20 be formed by the reporting LSR. IANA is requested to assign value 23
to this Error Code. to this Error Code.
The Error Code "Unsupported LSP Integrity" indicates that a P2MP The Error Code "Unsupported LSP Integrity" indicates that a P2MP
branch does not support the requested LSP integrity function. IANA is branch does not support the requested LSP integrity function. IANA is
requested to assign value 21 to this Error Code. requested to assign value 24 to this Error Code.
The Error Code "P2MP Remerge Detected" indicates that a node has The Error Code "P2MP Remerge Detected" indicates that a node has
detected remerge. IANA is requested to assign value 22 to this Error detected remerge. IANA is requested to assign value 25 to this Error
Code. Code.
20.4. LSP Attributes Flags 20.4. LSP Attributes Flags
IANA has been asked to manage the space of flags in the Attibutes IANA has been asked to manage the space of flags in the Attibutes
Flags TLV carried in the LSP_ATTRIBUTES Object [LSP-ATTRIB]. This Flags TLV carried in the LSP_ATTRIBUTES Object [LSP-ATTRIB]. This
document defines two new flags as follows: document defines two new flags as follows:
Suggested Bit Number: 3 Suggested Bit Number: 3
Meaning: LSP Integrity Required Meaning: LSP Integrity Required
skipping to change at page 48, line 15 skipping to change at page 50, line 39
27. Full Copyright Statement 27. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
28. Acknowledgement 28. Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 113 change blocks. 
420 lines changed or deleted 559 lines changed or added

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