P2MP
Click on the red underlined text to get to the source
... networks. However these specifications do not provide a mechanism
for building point-to-multipoint (P2MP) TE LSPs.
...
... RFC3209]
and [RFC3473]) to support P2MP TE LSPs satisfying the set of
requirements described in [RFC4461 ...
... Resource Reservation
Protocol (RSVP) that RSVP-TE inherits for building P2MP LSPs. A P2MP
LSP is comprised of multiple source-to-leaf (S2L ...
... RSVP-TE inherits for building P2MP LSPs. A P2MP
LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These
...
... RSVP semantics to
result in a P2MP TE LSP. One Path message may signal one or multiple
S2L sub-LSPs ...
... Path message may signal one or multiple
S2L sub-LSPs for a single P2MP LSP. Hence the S2L sub-LSPs belonging
to a P2MP LSP ...
... P2MP LSP. Hence the S2L sub-LSPs belonging
to a P2MP LSP can be signaled using one Path message or split across
multiple Path messages ...
... combination with other techniques, to support different applications.
Specification of how applications will use P2MP TE LSPs and how the
paths of P2MP ...
... P2MP TE LSPs and how the
paths of P2MP TE LSPs are computed is outside the scope of this
document.
...
... P2MP TE LSP.
The P2MP TE LSP is set up by associating multiple S2L sub-LSPs and
relying on data replication ...
... replication at branch nodes. This is described
further in the following sub-sections by describing P2MP tunnels and
how they relate to S2L sub-LSPs.
...
... P2MP Tunnels ...
...
The defining feature of a P2MP TE LSP is the action required at
branch nodes where data replication ...
... SESSION object. This object contains the
identifier of the P2MP Session, which includes the P2MP Identifier ...
... identifier (Extended Tunnel ID). The P2MP ID is a four-octet number
and is unique within the scope of the ingress LSR.
...
... Address field is replaced by the P2MP ID field. The P2MP SESSION
object is defined in section 19.1
...
... P2MP LSP ...
...
A P2MP LSP is identified by the combination of the P2MP ID, Tunnel
ID, and Extended Tunnel ID ...
...
A P2MP LSP is identified by the combination of the P2MP ID, Tunnel
ID, and Extended Tunnel ID that are part of the P2MP ...
... P2MP ID, Tunnel
ID, and Extended Tunnel ID that are part of the P2MP SESSION object,
and the tunnel ...
... P2MP
SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is
defined in section 19.2.
...
... RSVP messages. While the use of RSVP messages is the same,
P2MP LSP state differs from P2P LSP ...
... state in a number of ways. A
P2MP LSP comprises multiple S2L Sub-LSPs, and as a result of this, it
may not be possible to represent full state ...
... and from P2MP TE LSPs. An additional issue is that the P2MP LSP must
also handle the state "re-merge" problem, see [RFC4461 ...
... SENDER_TEMPLATE
and SESSION objects, are used to represent a portion of a P2MP LSP's
state. This portion of a P2MP LSP ...
... node to "branch" signaling state for a P2MP LSP,
but to not branch the data associated with the P2MP LSP. Typical
...
... state for a P2MP LSP,
but to not branch the data associated with the P2MP LSP. Typical
applications for generation and use of multiple sub-groups are (1)
...
...
A P2MP LSP is constituted of one or more S2L sub-LSPs.
...
... An S2L sub-LSP exists within the context of a P2MP LSP. Thus, it is
identified by the P2MP ID, Tunnel ID ...
... context of a P2MP LSP. Thus, it is
identified by the P2MP ID, Tunnel ID, and Extended Tunnel ID that are
...
... address and LSP ID fields
of the P2MP SENDER_TEMPLATE object, and the S2L sub-LSP destination
address ...
... An EXPLICIT_ROUTE Object (ERO) or P2MP_SECONDARY_EXPLICIT_ROUTE
Object (SERO) is used to optionally specify the explicit route of a
...
... C-type is defined in section 19.5, and a matching
P2MP_SECONDARY_RECORD_ROUTE Object C-type is defined in section 19.6.
...
...
The mechanism in this document allows a P2MP LSP to be signaled using
one or more Path messages. Each Path message ...
... S2L sub-LSPs;
and they also allow separate manipulation of sub-trees of the P2MP
LSP. The reason for allowing a single Path message to signal
multiple S2L sub-LSPs ...
... Path message signals a single S2L sub-LSP (that is, the Path
message is only targeting a single leaf in the P2MP tree), the
EXPLICIT_ROUTE object ...
... The path of each subsequent S2L sub-LSP is encoded in a
P2MP_SECONDARY_EXPLICIT_ROUTE object (SERO). The format of the SERO
is the same as an ERO ...
... RFC3473]). Each
subsequent S2L sub-LSP is represented by tuples of the form < [<P2MP
SECONDARY_EXPLICIT_ROUTE>], <S2L ...
... LSR that is a destination of the P2MP LSP. Each S2L sub-LSP is
associated with the same P2MP LSP ...
... P2MP LSP. Each S2L sub-LSP is
associated with the same P2MP LSP using common P2MP SESSION object
...
... S2L sub-LSP is
associated with the same P2MP LSP using common P2MP SESSION object
and <Sender ...
... Sender Address, LSP-ID> fields in the P2MP SENDER_TEMPLATE
object. Hence, it can be combined with other S2L sub-LSPs ...
... object. Hence, it can be combined with other S2L sub-LSPs to form a
P2MP LSP. Another S2L sub-LSP belonging to the same instance of this
S2L sub-LSP ...
... S2L sub-LSP belonging to the same instance of this
S2L sub-LSP (i.e., the same P2MP LSP) SHOULD share resources with
this S2L sub-LSP. The session ...
... this S2L sub-LSP. The session corresponding to the P2MP TE tunnel is
determined based on the P2MP ...
... 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
...
... LSR that supports RSVP-TE
signaled P2MP LSPs MUST be able to receive and process multiple Path
messages for the same P2MP LSP ...
... P2MP LSPs MUST be able to receive and process multiple Path
messages for the same P2MP LSP and multiple S2L sub-LSPs in one Path
message. This implies that such an LSR ...
... 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 ...
... LSR MAY use multiple Path messages for signaling a P2MP
LSP. This may be because a single Path message may not be large
enough to signal the P2MP LSP ...
... P2MP
LSP. This may be because a single Path message may not be large
enough to signal the P2MP LSP. Or it may be that when new leaves are
added to the P2MP LSP, they are signaled in a new Path message ...
... enough to signal the P2MP LSP. Or it may be that when new leaves are
added to the P2MP LSP, they are signaled in a new Path message. Or
an ingress LSR ...
... Path message. Or
an ingress LSR MAY choose to break the P2MP tree into separate
manageable P2MP ...
... the trunk and certain branches. The scope of this management
decomposition of P2MP trees is bounded by a single tree (the P2MP ...
... S2L sub-LSPs). Per
[RFC4461], a P2MP LSP MUST have consistent attributes across all
portions of a tree. This implies that each Path message ...
... tree. This implies that each Path message that is used
to signal a P2MP LSP is signaled using the same signaling attributes
...
... sub-LSPs from the different Path messages belonging to
the same P2MP LSP SHOULD share labels and resources where they share
hops to prevent multiple copies of the data being sent.
...
... LSR that signal state for the
same P2MP LSP are signaled with the same SESSION object and have the
same <Source address ...
... Path messages generated by an LSR to signal state for the same P2MP
LSP have the same Sub-Group Originator ID and have a different sub-
Group ...
... PathErr message MUST be sent for the impacted S2L sub-LSP,
and normal processing of the rest of the P2MP LSP SHOULD continue.
The default behavior is that the remainder of the LSP is not impacted
...
... Path message that is
generated by the transit LSR for the P2MP LSP carries a distinct
<Sub-Group Originator ID, Sub-Group ...
... that any failure anywhere within the LSP tree causes the entire P2MP
LSP to fail.
The ingress LSP ...
...
The operation of adding egress LSR(s) to an existing P2MP LSP is
termed grafting. This operation allows egress nodes to join ...
... termed grafting. This operation allows egress nodes to join a P2MP
LSP at different points in time.
There are two methods ...
... 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 ...
... P2MP LSP. The first
is to add new S2L sub-LSPs to the P2MP LSP by adding them to an
existing Path message and refreshing the entire Path message ...
... Path message. Path
message processing described in section 4 results in adding these S2L
sub-LSPs to the P2MP LSP. Note that as a result of adding one or
more S2L sub-LSPs to a Path message ...
... S2L sub-LSP
descriptor in section 4.1 with the difference that a
P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
...
... P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
SECONDARY_EXPLICIT_ROUTE object. The P2MP ...
... P2MP
SECONDARY_EXPLICIT_ROUTE object. The P2MP_SECONDARY_RECORD_ROUTE
objects follow the same compression ...
... RECORD_ROUTE
objects follow the same compression mechanism as the P2MP
SECONDARY_EXPLICIT_ROUTE objects. Note that a Resv message ...
... FILTER_SPEC object is different, as that implies that
the FILTER_SPEC refers to a different P2MP LSP.
...
... SE filter spec for
the same P2MP LSP (whether on one or multiple Resv messages) on the
same Resv MUST be allocated the same label, and FF ...
... The node that sends the Resv message, for a P2MP LSP, upstream MUST
associate the label assigned by this node ...
... received from downstream Resv messages, for that P2MP LSP. Note that
a transit node may become a replication ...
... node may become a replication point in the future when a
branch is attached to it. Hence, this results in the setup of a P2MP
LSP from the ingress LSR to the egress LSRs.
...
... Resv messages.
Specifically, in the case where the only change being sent in a Resv
message is in one or more P2MP_SECONDARY_RECORD_ROUTE objects
(SRROs ...
... Path message. The same rule is used during signaling of P2MP LSPs.
That is, inclusion of an RRO ...
... Additional recorded routes for the subsequent S2L sub-LSPs are
encoded in P2MP_SECONDARY_RECORD_ROUTE objects (SRROs). Their format
...
... can be either FF or SE. All P2MP LSPs that belong to the same P2MP
Tunnel MUST be signaled with the same reservation ...
... SE. All P2MP LSPs that belong to the same P2MP
Tunnel MUST be signaled with the same reservation style.
Irrespective of whether the reservation ...
... FF or SE, the S2L
sub-LSPs that belong to the same P2MP LSP SHOULD share labels where
they share hops. If the S2L sub-LSPs that belong to the same P2MP
LSP ...
... P2MP LSP SHOULD share labels where
they share hops. If the S2L sub-LSPs that belong to the same P2MP
LSP share labels then they MUST share resources. If the reservation
style is FF ...
... style is FF, then S2L sub-LSPs that belong to different P2MP LSPs
MUST NOT share resources or labels. If the reservation ...
... P2MP LSPs and the same
P2MP tunnel SHOULD share resources where they share hops, but they
MUST not share labels in packet environments.
...
... The operation of removing egress LSR(s) from an existing P2MP LSP is
termed as pruning. This operation allows egress nodes to be removed ...
... nodes to be removed
from a P2MP LSP at different points in time. This section describes
the mechanisms to perform pruning.
...
... RSVP processing, an S2L sub-LSP may be removed from a P2MP
TE LSP by sending a modified message for the Path or Resv message
that previously advertised the S2L sub-LSP ...
... removes an S2L sub-LSP
from a P2MP TE LSP MUST ensure that the S2L sub-LSP is not included
in any other Path state ...
... SESSION and SENDER_TEMPLATE objects corresponding to the
P2MP LSP and the <Sub-Group Originator ID, Sub-Group ID> tuple
...
... Path message need to be removed from
the P2MP LSP. Other S2L sub-LSPs, from other sub-groups signaled
...
... Path message.
When a P2MP LSP is removed by the ingress, a PathTear message MUST be
generated for each Path message ...
... removed by the ingress, a PathTear message MUST be
generated for each Path message used to signal the P2MP LSP.
...
... 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
...
... address. The object and message SHALL be supported for the
confirmation of receipt of the Resv message in P2MP TE LSPs.
Processing not detailed in this section MUST comply to [RFC2205 ...
... FILTER_SPEC objects.
The consequence of these rules for a P2MP LSP is that a ResvConf
message generated at the ingress will result in a ResvConf message
being delivered to the branch and then to the receiver ...
... refresh reduction procedures described in [RFC2961] are equally
applicable to P2MP LSPs described in this document. Refresh
...
... reduction applies to individual messages and the state they
install/maintain, and that continues to be the case for P2MP LSPs.
...
...
State signaled by a P2MP Path message is identified by a local
implementation using the <P2MP ...
... P2MP Path message is identified by a local
implementation using the <P2MP ID, Tunnel ID, Extended Tunnel ID>
...
... overcome this drawback and add/delete S2L sub-LSPs to/from a P2MP LSP
by incrementally updating the existing state.
...
... S2L sub-LSPs to be incrementally added to or deleted from the
P2MP LSP by allowing a Path or a PathTear message to incrementally
change the existing P2MP LSP Path state ...
... P2MP LSP by allowing a Path or a PathTear message to incrementally
change the existing P2MP LSP Path state.
...
... As described in section 5.2, multiple Path messages can be used to
signal a P2MP LSP. The Path messages are distinguished by different
<Sub-Group ...
... S2L sub-LSP state expiration, and
provides the ability to perform incremental P2MP LSP state updates.
...
... There is a tradeoff between the number of Path messages used by the
ingress to maintain the P2MP LSP and the processing imposed by full
state messages when adding S2L sub-LSPs ...
... Path message in order to reduce
the number of Path messages needed to maintain the P2MP LSP. This
can also be done by a transit node that performed fragmentation ...
... requests 'LSP integrity', an error reported on a branch of a P2MP TE
LSP for a particular S2L sub-LSP may change the state of any other
...
... state of any other
S2L sub-LSP of the same P2MP TE LSP. This is explained further in
section 11.3.
...
... LSR generating a PathErr to report the failure of a
branch of the P2MP LSP SHOULD set the Path_State_Removed flag.
...
... P2MP LSP and Sub-LSP Re-Optimization ...
... LSPs to reach the
destinations of the P2MP tunnel. There are two methods that can be
used to accomplish this. The first is make-before-break ...
... make-before-break procedure
defined in [RFC3209]. Thus, a new P2MP LSP is established. Each S2L
sub-LSP is signaled with a different LSP ID, corresponding to the new
...
... S2L
sub-LSP is signaled with a different LSP ID, corresponding to the new
P2MP LSP. After moving traffic to the new P2MP LSP, the ingress can
...
... P2MP LSP. After moving traffic to the new P2MP LSP, the ingress can
tear down the old P2MP LSP. This procedure can be used to re-
...
... traffic to the new P2MP LSP, the ingress can
tear down the old P2MP LSP. This procedure can be used to re-
optimize the path of the entire P2MP LSP or the paths to a subset of
...
... tear down the old P2MP LSP. This procedure can be used to re-
optimize the path of the entire P2MP LSP or the paths to a subset of
the destinations of the P2MP LSP ...
... P2MP LSP or the paths to a subset of
the destinations of the P2MP LSP. When modifying just a portion of
the P2MP LSP, this approach requires the entire P2MP LSP ...
... destinations of the P2MP LSP. When modifying just a portion of
the P2MP LSP, this approach requires the entire P2MP LSP to be re-
signaled.
...
... P2MP LSP. When modifying just a portion of
the P2MP LSP, this approach requires the entire P2MP LSP to be re-
signaled.
...
... node
initiating the path change initiates one or more separate Path
messages for the same P2MP LSP, each with a new sub-Group ID. The
generation of these Path messages ...
... RFC4090] for each Path message and S2L sub-LSP of a P2MP LSP. Each
S2L sub-LSP of a P2MP LSP ...
... P2MP LSP. Each
S2L sub-LSP of a P2MP LSP MUST have the same protection
characteristics. The RRO processing MUST apply to SRRO ...
... The sections that follow describe how fast reroute may be applied to
P2MP MPLS TE LSPs in all of the principal ...
... node protection of LSRs on
the path of a P2MP LSP. The downstream labels MUST be learned by the
Point of Local Repair ...
... Note that all such S2L sub-LSPs belonging to a particular instance of
a P2MP tunnel SHOULD share the same outgoing label on the link
between the PLR ...
... PLR and the next-hop as per section 5.2.1. This is the
P2MP LSP label on the link. Label stacking is used to send data for
each P2MP LSP ...
... P2MP LSP label on the link. Label stacking is used to send data for
each P2MP LSP into the bypass tunnel. The inner label ...
... tunnel. When the PLR forwards incoming
data for a P2MP LSP into the bypass tunnel, the outer label is the
...
... MP to the set of S2L sub-LSPs belonging to that P2MP LSP.
After detecting failure of the protected node ...
... is not branch capable, and one or more S2L sub-LSPs are added to a
P2MP tree, and these S2L sub-LSPs do not transit the existing MP ...
... next-hop. All the S2L sub-LSPs corresponding to the same
instance of the P2MP tunnel between the PLR and the next-hop SHOULD
...
... PLR and the next-hop SHOULD
share the same P2MP LSP label, as per section 5.2.1. All such S2L
sub-LSPs belonging to a P2MP LSP MUST be protected.
...
... share the same P2MP LSP label, as per section 5.2.1. All such S2L
sub-LSPs belonging to a P2MP LSP MUST be protected.
The backup S2L sub-LSPs ...
... PLR.
Thus, the set of outgoing labels and next-hops for a P2MP LSP, at the
PLR, may change once protection is triggered. Consider a P2MP LSP ...
... P2MP LSP, at the
PLR, may change once protection is triggered. Consider a P2MP LSP
that is using a single next-hop and label between the PLR ...
... backup Path message. A backup S2L sub-LSP MUST be treated as
belonging to a different P2MP tunnel instance than the one specified
by the LSP-ID. Furthermore multiple backup S2L sub-LSPs ...
... LSP-ID. Furthermore multiple backup S2L sub-LSPs MUST be
treated as part of the same P2MP tunnel instance if they have the
same LSP-ID and the same DETOUR objects. Note that, as specified in
...
... LSP-ID and the same DETOUR objects. Note that, as specified in
section 4, S2L sub-LSPs between different P2MP tunnel instances use
different labels.
...
... LSRs in a network are capable of processing the
P2MP extensions described in this document, but do not support P2MP
branching in the data plane ...
... network are capable of processing the
P2MP extensions described in this document, but do not support P2MP
branching in the data plane. If such an LSR ...
... It is also conceivable that some LSRs, in a network deploying P2MP
capability, may not support the extensions described in this
document. If a Path message ...
... capability, may not support the extensions described in this
document. If a Path message for the establishment of a P2MP LSP
reaches such an LSR, it will reject it with a PathErr ...
...
LSRs that do not support the P2MP extensions in this document may be
included as transit LSRs by the use of LSP ...
... LSP stitching and LSP hierarchy [RFC4206] allows P2MP LSPs
to be built in such an environment. A P2P ...
... P2P LSP segment is signaled
from the last P2MP-capable hop that is upstream of a legacy LSR to
...
... upstream of a legacy LSR to
the first P2MP-capable hop that is downstream of it. This assumes
that intermediate legacy LSRs ...
... LSRs are transit LSRs: they cannot act as
P2MP branch points. Transit LSRs along this LSP segment do not
...
... LSP segment do not
process control plane messages associated with the P2MP LSP.
Furthermore, these transit LSRs also do not need to have P2MP ...
... P2MP LSP.
Furthermore, these transit LSRs also do not need to have P2MP data
plane capabilities as they only need to process data belonging to the
P2P ...
... LSP segment. Hence, these transit LSRs do not need to support
P2MP MPLS. This P2P LSP segment ...
... MPLS. This P2P LSP segment is stitched to the incoming P2MP
LSP. After the P2P LSP segment is established, the P2MP ...
... P2MP
LSP. After the P2P LSP segment is established, the P2MP Path message
is sent to the next P2MP ...
... LSP. Hence, label stacking can be used to enable use of the same
LSP segment for multiple P2MP LSPs. Stitching and nesting
considerations and procedures are described further in [LSP-STITCH ...
... may be desirable to do this dynamically. The ingress can use IGP
extensions to determine P2MP-capable LSRs [TE-NODE-CAP]. It can use
...
... this information to compute S2L sub-LSP paths such that they avoid
legacy non-P2MP-capable LSRs. The explicit route object of an S2L
sub-LSP ...
... the path. The corresponding explicit route contains a list of
objects up to the P2MP-capable LSR that is adjacent to a legacy LSR
...
... P2MP-capable
LSR. The P2MP-capable LSR expands the loose hop using its Traffic
Engineering Database (TED ...
... signaling.
The P2MP-capable LSR that initiates the non-adjacent signaling
message to the next P2MP ...
... P2MP-capable LSR that initiates the non-adjacent signaling
message to the next P2MP-capable LSR may have to employ a fast
detection mechanism (such as [BFD ...
... detection mechanism (such as [BFD] or [BFD-MPLS]) to the next P2MP-
capable LSR. This may be needed for the directed Path message ...
... RFC4206] while
setting up P2MP LSP, as described in the previous section, to reduce
control plane processing along transit LSRs ...
... control plane processing along transit LSRs that are P2MP capable.
This is applicable only in environments where LSP hierarchy can be
...
... LSRs along a P2P LSP segment, being used by a P2MP
LSP, do not process control plane messages associated with the P2MP
LSP. In fact, they are not aware of these messages as they are
...
... LSP segment, being used by a P2MP
LSP, do not process control plane messages associated with the P2MP
LSP. In fact, they are not aware of these messages as they are
tunneled over the P2P LSP segment ...
... PE3 and PE4 can now be tunneled over
the LSP segment. Thus, P3 is not aware of the P2MP LSP and does not
process the P2MP control messages ...
... LSP segment. Thus, P3 is not aware of the P2MP LSP and does not
process the P2MP control messages.
...
... P2MP LSP Re-Merging and Cross-Over ...
... an ingress or transit node that creates a branch of a P2MP LSP, a re-
merge branch, that intersects the P2MP LSP at another node ...
... creates a branch of a P2MP LSP, a re-
merge branch, that intersects the P2MP LSP at another node farther
down the tree ...
... 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.
...
... node that creates a branch of a P2MP LSP, a cross-over branch, that
intersects the P2MP LSP at another node ...
... creates a branch of a P2MP LSP, a cross-over branch, that
intersects the P2MP LSP at another node farther down the tree. It is
...
... nodes.
Normally, a P2MP LSP has a single incoming interface on which all of
the data for the P2MP LSP ...
... P2MP LSP has a single incoming interface on which all of
the data for the P2MP LSP is received. The incoming interface is
identified by the IF_ID RSVP_HOP ...
... node will
receive a Path message for a given P2MP LSP identifying a different
incoming interface for the data, and the node ...
... interface associated with the make-before-break
P2MP LSP may be different than that associated with the original P2MP
LSP. However, the two P2MP LSPs ...
... make-before-break
P2MP LSP may be different than that associated with the original P2MP
LSP. However, the two P2MP LSPs will be treated as distinct (but
...
... P2MP LSP may be different than that associated with the original P2MP
LSP. However, the two P2MP LSPs will be treated as distinct (but
related) LSPs ...
... Path message, it MUST check whether it has
matching state for the P2MP LSP. Matching state is identified by
comparing the SESSION ...
... SESSION and SENDER_TEMPLATE objects of each
locally maintained P2MP LSP Path state. The P2MP ID, Tunnel ID ...
... Path message is different than the incoming interface of the
matching P2MP LSP Path state, then the node MUST determine whether it
...
... S2L_SUB_LSP objects associated with
the matching P2MP LSP Path state and the set of S2L_SUB_LSP ...
... S2L_SUB_LSPs
associated with the matching P2MP LSP Path state will be received
subsequently on the new incoming interface ...
... Path message MUST identify the outgoing interfaces
associated with the matching P2MP Path state. Re-merge has occurred
if there is any intersection between the set of outgoing interfaces ...
... if there is any intersection between the set of outgoing interfaces
associated with the matching P2MP LSP Path state and the set of
outgoing interfaces ...
... consistency between the objects included in the
received Path message and the matching P2MP LSP Path state. Any
inconsistencies MUST result in a PathErr message ...
... Error Code is set to "Routing
Problem", and the Error Value is set to "P2MP Re-Merge Parameter
Mismatch".
...
... state of incoming Path message
with the matching P2MP LSP Path state. Specifically, procedures
related to processing of messages received from upstream ...
...
When configured to allow a re-merge case to persist, the re-merge
node receives data associated with the P2MP LSP on multiple incoming
interfaces, but it MUST only send the data from one of these
...
... LSP objects from the set of sub-LSPs associated with the
matching P2MP LSP Path state. A minimum of three S2L_SUB_LSP ...
... Error Code "Routing Problem" and Error Value of "P2MP Re-Merge
Detected". The node MAY set the Path_State_Removed flag ...
... Error Value
"Routing Problem/P2MP Re-Merge Detected" MUST determine if it is the
node that created ...
... S2L_SUB_LSP
objects associated with the matching P2MP LSP Path state and the set
of other-branch S2L ...
... node detecting the re-merge case, in the PathErr message that were
taken from the matching P2MP LSP Path state. Such S2L_SUB_LSP ...
... PathErr message to the outgoing interface associated with the
matching P2MP LSP Path state. A trigger Path message for the moved
...
... destination identifier of the P2MP tunnel. This SESSION object has a
similar structure as the existing point-to-point ...
... SESSION
object. However the destination address is set to the P2MP ID
instead of the unicast Tunnel Endpoint ...
... address. All S2L sub-LSPs
that are part of the same P2MP LSP share the same SESSION object.
This SESSION ...
... SESSION object.
This SESSION object identifies the P2MP tunnel.
The combination of the SESSION ...
... 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 ...
... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+