wdiff draft-wijnands-rtgwg-mcast-frr-tn-00.txt draft-wijnands-rtgwg-mcast-frr-tn-01.txt

Routing Working Group IJ. Wijnands, Ed.
Internet-Draft Cisco L. De Ghein
Intended status: Standards Track A. Csaszar, Ed. Cisco
Expires: April 18, 2013 January 9, 2014 G. Enyedi, Ed.
A. Csaszar
J. Tantsura
Ericsson
October 15, 2012
July 8, 2013

Tree Notification to Improve Multicast Fast Reroute
draft-wijnands-rtgwg-mcast-frr-tn-00
draft-wijnands-rtgwg-mcast-frr-tn-01

Abstract

This draft proposes using dataplane triggered notifications in order Tree Notifications to support
multicast fast reroute methods in various ways. Sending
such notifications down for PIM and mLDP. These Tree Notifications
are initiated by a node detecting the tree can be used to trigger fail-over in
nodes not adjacent failure to a Repair Node
downstream. A Repair Node is a node that has a pre-built backup path
that can circumvent the failure. Sending such dataplane
notification up Using this mechanism, a Repair Node
has the tree can help ability to activate learn about non-local failures quickly without
having to wait for the IGP to convergence. This draft also covers an
optional method to avoid bandwidth usage on the pre-built standby backup tree segments.
path.

Status of this Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on April 18, 2013. January 9, 2014.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

Table of Contents

1. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 4
3. Improving non-local failures . . . . . . . . . . . . . . . . . 5 4
3.1. Downstream Tree Notifications . . . . . . . . . . . . . . 6 5
3.2. DTNP processing/forwarding . . . . . . . DTN processing logic . . . . . . . . . 6
4. Reduce the bandwidth consumption in failure-free network . . . 8
4.1. Upstream Tree Notifications . . . . . . . 6
3.3. Repair Node discovery . . . . . . . . 8
4.2. Joining a tree in dedicated backup status . . . . . . . . 9
4.2.1. Single topology environment . . 8
3.3.1. Repair Node Information item . . . . . . . . . . . 9
4.2.2. Multi-Topology Environment . . 8
3.4. Reduce the bandwidth consumption in networks with fast
failover response times . . . . . . . . . . . . 10
4.3. Activation . . . . . 8
3.4.1. Joining a secondary tree in blocking mode . . . . . . 9
3.4.2. Upstream Tree Notifications . . . . . . . . . . . . . 10
4.4.
3.5. MRT/MCI-Only Mode . . . . . . . . . . . . . . . . . . . . 10
5. The
3.6. TN Packet . . . . Authentication . . . . . . . . . . . . . . . . . . . . 11
5.1.
3.7. The TN Packet Format . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1.
3.7.1. TN TimeStamp TLV Packet Format . . . . . . . . . . . . . . . 12
5.2. Origination of TN Packets . . . . . . . . . . . . . . . . 13
6. IP/PIM Specific 11
3.7.1.1. TN Components . . . . . . . . . . . . . . . . 13
6.1. IP/PIM Downstream Tree Notifications . . . . . . . . . . TimeStamp TLV Format . 13
6.2. IP/PIM Upstream Tree Notifications . . . . . . . . . . . . 13
6.3. Incremental deployment . . . . .
3.7.1.2. TN Signature TLV Format . . . . . . . . . . . . . 14
7. mLDP
4. PIM Specific TN Components . . . . . . . . . . . . . . . . . 14
7.1. mLDP Downstream Tree Notification . . . . . . . . . . . . 15
7.1.1. Originating a DTNP . . .
4.1. RNI item in PIM Join Message . . . . . . . . . . . . . . . 15
7.1.2. Receiving a DTNP .
4.2. Tree Information Item . . . . . . . . . . . . . . . . . . 15
7.1.3. Forwarding a DTNP 16
4.3. Incremental deployment . . . . . . . . . . . . . . . . . . 15
7.2. 18
5. mLDP Upstream Tree Notification . . . . . . . . . . . . . 15
7.2.1. Originating a UTNP . . . . . . Specific TN Components . . . . . . . . . . . . 15
7.2.2. Receiving a UTNP . . . . . 18
5.1. RNI item in mLDP Label Mapping . . . . . . . . . . . . . . 16
7.2.3. Forwarding a UTNP 18
5.2. Tree Information Item . . . . . . . . . . . . . . . . . . 16
8. 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 22

1. Terminology and Definitions

MoFRR : Multicast only Fast Re-Route.

LFA : Loop Free Alternate.

mLDP : Multi-point Label Distribution Protocol.

PIM : Protocol Independent Multicast.

UMH : Upstream Multicast Hop, a candidate next-hop that can be used
to reach the root of the tree.

tree : Either a PIM (S,G)/(*,G) tree or a mLDP P2MP or MP2MP LSP.

OIF : Outgoing InterFace, an interface used to forward multicast
packets down the tree towards the receivers. Either a PIM
(S,G)/(*,G) tree or a mLDP P2MP or MP2MP LSP.

IIF : Incoming InterFace, an interface where multicast traffic is
received by a router.

MCE : MultiCast Egress, the last node where the multicast stream
exits the current transport technology (MPLS-mLDP or IP-PIM)
domain or administrative domain. This maybe the router attached
to a multicast receiver.

MCI : MultiCast Ingress, the node where the multicast stream enters
the current transport technology (MPLS-mLDP or IP-PIM) domain.
This maybe the router attached to the multicast source.

DTNP

DTN : Downstream Tree Notification Packet.

UTNP Notification.

UTN : Upstream Tree Notification Packet.

TNP Notification.

TN : Tree Notification Packet, Notification, Upstream or Downstream

Repair Node : A node that can circumvent the failure.

JM : Join Message, the message used to join to a multicast tree,
i.e. to build up the tree. In PIM, this is a JOIN message, while
in mLDP this corresponds to a LabelMap Label Mapping message.

MRT : Maximally Redundant Trees.

Repair Node : The node performing a dual-join to the tree through
two different UMHs. Sometimes also called as dual-joining node or
merging node (it merges the secondary and primary tree).

RNI : The Repair Node Information is an item included in the TN
which holds the nessesary repair information when the TN is send
to the Repair Node.

Branching Node : A node, (i) which is considered as being on the
primary tree by its immediate UMH and (ii) which has at least one
secondary type of
OIF on the secondary tree installed for a multicast tree.

2. Introduction

Both [I-D.karan-mofrr] and [I-D.atlas-rtgwg-mrt-mc-arch] describe
"live-live" multicast protection, where a node joins a tree via
different candidate upstream multicast hops (UMH). With MoFRR the
list of candidate UMHs can come from either ECMP or Loop Free
Alternate (LFA) paths towards the MultiCast Ingress node (MCI). With
MRT, the candidate UMHs are determined by looking up the MCI in two
different (Red and Blue) topologies. In either case, the multicast
traffic is simultaneously received over different paths/topologies
for the same tree. The node 'dual-joining' the tree needs a
mechanism to prevent duplicate packets being forwarding to the end
user. For that reason a node 'dual-joining' the tree only accepts
packets from one of the UMHs at the time. Which UMH is preferred is
a local decision that can be based on IGP reachability, link status,
BFD, traffic flow monitoring, etc...

Should the node detect a local failure on the primary UMH, the node
has an instantly available secondary UMH that is it can switch to,
simply by unblocking the secondary UMH. The dual-joining node is
also called Repair Node in the following.

This draft attempts to improve these solutions by:

o Improving fail-over time and the reliability of failure detection
for non-local failures; and

o Reducing the bandwidth consumption in a failure-free network. network with fast failover
response times.

3. Improving non-local failures

If a failure is not local and happens further upstream, the dual-
joining node needs a fast and reliable mechanism (i) to detect the upstream
failure and (ii) to learn that other upstream nodes cannot circumvent
the failure. Existing methods based on traffic monitoring are
limited in scope and work best with a steady state packet flow.
Therefore, we propose a method which can trigger the unblocking the
secondary UMH independently of the packet flow.

Figure 1 shows an example. Consider that, e.g., node A goes down.
Nodes C, D and E cannot detect that locally, so they need to resort
to other means. After detecting the failure, node C should not
change to its secondary UMH (node J) as it won't help for the failure
of A. Node D, on the other hand, will have to unblock its secondary
UMH (node I). Yet again, with MoFRR, node E should not unblock its
secondary UMH (node K): (i) this won't help in resolving the failure
of node A, and (ii) one of its upstream nodes (node D in this case)
will be able to restore the stream with a fail-over action.

3.1. Downstream Tree Notifications

The

When a node detecting detects a local failure of its primary UMH it MUST
originate a Downstream Tree Notification Packet (DTNP) (DTN) to all downstream
branches of the tree. Each router that receives the DTNP determines
if Repair
Nodes directly below it in the multicast tree. The method of
discovering such nodes is described in Section 3.3. When a Repair
Node for that tree. If it is not receives a Repair Node, DTN containing the DTNP is forwarded further down primary UMH of the tree. If node, it must
switch to the node is secondary UMH.

DTN packets are sent via unicast to the Repair Node, the secondary UMH Node. The packet may
be forwarded using any transport that is unblocked and available (MPLS or IP) to
reach the DTNP is
discarded. destination. The DTNP allows IP precedence in the IP header should
have a downstream router to unambigously
identify value of 6 (Internetwork Control). The EXP field (Traffic
Class field) in the multicast tree impacted MPLS header should have a value of 6. The DTN
packets are identified by a well known port number (to be allocated).
Using a well-known port number it is easy for the failure.

In order Repair Node to decrease reaction time,
identify the DTNP SHOULD DTN packet and invoke the procedures as described in
this draft. We are proposing to allocate different port numbers for
PIM and MDLP since it will be originated
from easier to dispatch the data plane when packet to the
right process dealing with this request.

When a router detects a local failure is detected, failure, it should sent out the DTN
packet to the Repair Node as well fast as
processed in possible. The sooner the data plane when Repair
Node gets the packet, the sooner the traffic can be restored. It is
recommended that the DTNP DTN packet is received. All pre-created and originated from
the
information necessary to send data-plain. The same is true for receiving the DTN packet on the
Repair Node, the faster it can be processed, the faster the traffic
is restored. For both forwarding and receive a DTNP has to processing the DTN, control-
plain interaction SHOULD be available
in avoided to get the data plane in advance. best failover results.

3.2. DTNP processing/forwarding DTN processing logic

When a DTNP DTN packet is received from an UMH, on the node MUST check

o whether Repair Node it has a secondary UMH, must determine
which tree and if yes,

o whether this particular DTNP was received UMH the notification is for. The information encoded
in the DTN is specific for the type of tree being used, i.e. PIM vs
mLDP. For details on the primary or
secondary UMH, specific encoding see Section 4 and

o whether another DTNP had been received beforehand from
Section 5 for the other
UMH.

Whenever a node receives a DTNP from its primary UMH and details. Once the node has
a secondary UMH for which no DTNP had been received beforehand, this
node could be a Repair Node, so unblocks its secondary UMH. The DTNP
MUST not be forwarded, but the node has to store determined the fact that a DTNP
has been received for
tree and the primary UMH for this multicast tree.

If a node receives a DTNP from its primary UMH but does not have a
secondary UMH, this node is not the Repair Node and MUST forward following rules are use for processing the
DTNP. DTN.

1. If a node receives two DTNPs, one from the UMH encoded in the DTN packet is the primary UMH and another
one from in the
tree, the secondary UMH, then this node is not UMH MUST become the Repair Node new primary UMH and
it the
old primary MUST forward become the last received DTNP to all branches of secondary.

2. If the tree.
(Secondary UMH does not need to be unblocked since it cannot remedy encoded in the failure.)

A DTNP received only from DTN packet is the secondary UMH MUST NOT be forwarded,
but in the node has
tree, no action needs to store the fact that be taken.

3. If a DTNP DTN notification has been received for on both the primary and
secondary UMH for this multicast tree.

Whenever a decision has been taken to originate or forward in the tree, a DTNP, it
will new DTN notification MUST be automatically replicated
originated to all the Repair Node(s) downstream legs, given from this node.

In order for the Repair Node to determine that a DTN notification was
received for both the primary and secondary UMH, it is must store the
fact a multicast packet. DTNP MUST be replicated also to downstream
stand-by legs if such legs exist.

It would raise security issues if DTNPs propagated outside DTN was received for a particular UMH.

Consider the
operator network, so MCEs MUST prevent example in Figure 1 below. MCI is the root of a tree
that DTNP packets propagate to
receivers or to other domains. Rephrased, includes the nodes MUST NOT forward
DTNPs to legs that lead to receivers or to external autonomous
systems. as follows (based on the primary UMH).

->F->G->H->I
MCI
->A->B->C->D->E

Node C, D and E are candidate Repair Nodes.

-- Primary UMH
++ Secondary UMH

+-+ +-+ +-+ +-+
|F|---|G|---|H|---|I|
|F|+++|G|+++|H|+++|I|
+-+ +-+ +-+ +-+
/ \
/ \
+ +
+ +
+---+ +-+ +-+ +-+ +-+ +-+
|MCI|~~~~~~|A|---|B|---|C|---|D|---|E|
Source ---|MCI|------|A|---|B|---|C|---|D|---|E|--- Receiver
+---+ +-+ +-+ +-+ +-+ +-+
\ / \ /
\ / \ /
+ + + +
+ + + +
+-+ +-+
|J| |K|
+-+ +-+

Figure 1: Remote failure example

As an example, consider Figure 1. If

Suppose that the link between node A fails, and B failed, B is directly
connected and will detect the failure locally. In this case, node B
is the only node that detects the failure locally and triggers will originate a DTNP (towards C). DTN to
its downstream repair node C. Node C will receive the DTN for the UMH
that is the primary UMH. Following rule 1 (Section 3.2), node C will
make the backup UHM the new primary. No further action is needed
because C has repaired the tree via node J. Note, J would not have
sent a DTN to node C because J is not directly connected to the
failing link.

Suppose that node A fails, B and J are directly connected and detect
the failure locally. A DTN packet is triggered to first downstream
repair node of A, which is node C. Node C is an unusable Repair Node
because it will receive the DTNP from DTN for both the primary UMH (from B) and the
secondary UMH (from J). Because node Following rule 3 (Section 3.2), C is not can't
repair the tree and must sent a new DTN packet towards the Repair node it
Nodes of C, which are D, on the primary path, and E, on the secondary
path.

Suppose that the link between A and the MCI failed. Node A is
directly connected to the failure and will forward trigger a DTN packet to
its downstream repair node(s). In this case, node A has learned
about the DTNP towards K downstream repair node C twice, the primary UMH (via node
B) and D (observing
rule 3.). K does not have secondary UMH (via node J). Node C will therefore sent a DTN
packet including both the primary and secondary UMH to node C (see
Section 3.7 for this tree, so it will
send details on the DTNP downstream encoding). Following rule 3
(Section 3.2), C can't repair the tree and must sent a new DTN packet
towards the Repair Nodes of C, which are D, on the primary path, and
E, on the secondary path.

The DTN packet that D received from C will match against the primary
UMH. Following rule 1, D will activate the backup path to I. The DTN
packet that E (rule 2.). received from C will match against the backup UMH,
following rule 2, no action is taken. In the example one can see
that we recovered from the failure because node D started accepting
the data packets from node I and is forwarding them to node E.

3.3. Repair Node discovery

In example Figure 1 we wrote that nodes C, D has and E are the repair
nodes. How does a secondary
UMH, so node determine that it applies is a Repair Node? The rule 1.
is straightforward, a node that is enabled to join two UMH's, one in
active the other in backup ([I-D.karan-mofrr]), is a repair node on
the tree. A Repair node has the ability to repair the tree for the
nodes upstream from this node. In order for the Repair Node E applies rule 4. As to get
notified of upstream failures (ie DTN), the nodes upstream from the
Repair Node need to learn about it.

3.3.1. Repair Node Information item

A Repair Node MUST advertise its own address (either a result,
subscribers sitting at router ID or below
any directly connected address) and an UMH identifier to the nodes D
upstream on the tree. This address and E UMH are part of the RNI
(Repair Node Information) item that is included in the JM. The RNI
is carried hop by hop in the JM upstream. If a node along the path
is not a Repair Node, it will continue receiving save the multicast traffic.

4. RNI and forward if further
upstream. If the node is Repair Node, it will save the RNI and
include its own RNI in the JM sent further upstream. If a Repair
Node changes one if its UMH's, it needs to trigger a new RNI to its
upstream node(s) to notify them of the changed UMH. If a RNI is
received and it does not match the saved RNI, the new RNI overrides
the old RNI and triggers a JM with the new RNI to its upstream
node(s). A RNI includes protocol specific information on how to
identify the tree and UMH, for that reason it is documented in the
protocol specific sections Section 4 and Section 5.

The Repair Node MAY include additional information in the RNI for
reasons of security and robustness, please see Section 3.6 and
Section 3.7.1.

3.4. Reduce the bandwidth consumption in failure-free network networks with fast failover
response times

In some of networks, such as aggregation networks, bandwidth is more
sparse than, e.g., in core networks. Live-live multicast protection
results in traffic duplication more bandwidth consumption in the failure-free network as it
continuously uses bandwidth for pulls traffic on both trees or segments. trees. In such networks it is
relevant if the capacity serving backup purposes can be used in the failure-free network, i.e., used, most of
the time, by best-
effort best-effort or even by lower-than-best-effort traffic.

+---+ +-+ +-+
|MCI|~~~~~~|A|---|B|
+---+ +-+ +-+
\\ //
\\ //
+-+
|C|
+-+

Nodes A and B have receivers. Double lines show bandwidth
consumption that is superfluous when there is no failure in the
network.

Figure 2: Example for secondary segments occupying bandwidth in MoFRR

In live-standby mode the aim is that the secondary tree or secondary
tree segments are is not loaded with
forwarding multicast traffic as long as there is no failure. A In
order to achive such a "live-standby" type of multicast protection method,
however, requires two principal components:

o Blocking OIFs at branching points in the secondary tree to avoid
sending secondary packets in the first place; and

o Simple and fast-enough procedures to
following requirements must be able to activate the
standby tree or standby tree-segment.

4.1. Upstream Tree Notifications

The UTN mechanism requires that the secondary tree or tree segment
was built with dedicated backup status. In MoFRR or MRT live-live
mode the secondary tree and tree segments are active, only the merge
point, i.e. the Repair Node, keeps the secondary incoming interface
blocked. Dedicated backup status means that the OIFs corresponding
to the secondary tree are installed into the data plane but they are
installed with a flag denoting met:

o Upsteam nodes block their OIF when they are blocked. Packets are not
forwarded to these interfaces unless an Upstream Tree Notification
Packet (UTNP) activates them.

Sending notifications upstream helps facilitating live-standby mode
instead part of live-live. Whenever a node detects a failure on standby
tree.

o If all of the
primary tree (the failure being upstream from OIF's of the node's location), a
UTNP SHOULD be sent upstream towards node are marked as blocking, the source on node
joins the secondary tree
segment. It is to be noted in blocking mode further upstream.

o A procedure so that the reception of a DTNP MAY be used
as an upstream failure indication, so it MAY trigger sending node can quickly unblock its OIF
and starts to forward.

3.4.1. Joining a UTNP.
The UTNP activates the secondary tree segments at branching nodes,
i.e., unblocks the secondary OIFs.

Both the secondary in blocking mode

The JM and sent to the UTNP go up secondary UMH includes an identifier to indicate
the tree until a branching
node is reached. The branching node is

o in a single topology environment: a upstream node that is part MUST not forward packets down this branch of the
primary tree and that also has a secondary leg; or

o the MCI.

4.2. Joining a tree in dedicated backup status
tree. The secondary identifier is TBD. The mechanism to join process a secondary path
is almost identical to what the MRT and MoFRR drafts describe, i.e., i.e. a repair node Repair
Node simply sends a secondary JM through another UMH (on another
topology, in case of MRT).

For UTN, the secondary JM, however, has to explicitly indicate the
intended dedicated backup status. The backup indication MUST be an
opaque and transitive indication, so that legacy nodes transparently
keep the indication when sending the backup JM further up. In the
following, such a JM will be called as "backup JM". How a JM may
indicate its secondary status is protocol specific and will be
discussed in the appropriate chapter below.

4.2.1. Single topology environment

In If a single topology environment (MoFRR), the repair node sends the
secondary backup JM through a second UMH of its choice. From that
UMH on, the backup JM is routed towards the source as if it was a
regular JM. In every node, the backup JM MUST be processed
identically to receives a regular JM (including adding without a new entry to the
blocking identifier for an OIF
list), but, that previously was in addition, blocking mode,
the added OIF MUST be marked with "blocked"
flag. Traffic MUST NOT be forwarded through blocking mode is reset and the node stats forwarding out of this interface for
interface. If this
multicast node joined the tree while in blocked status.

If a node receives a primary JM after receiving blocking mode further
upstream, a secondary new JM from
the same neighbor, the node MUST reset the corresponding OIF entry be originated to
"unblocked" state. Furthermore, reset the primary JM MUST be sent blocking state
further
upwards if the node had no other "unblocked" OIFs, i.e., if the node
has not received a primary JM from any other neighbor for the given
multicast tree.

4.2.2. Multi-Topology Environment upstream.

3.4.2. Upstream Tree Notifications

In a multi-topology environment (MRT), the secondary tree is built
completely independent of the primary tree, on a second topology.
This topology ID is attached order to the backup JM. Not only the repair
node, but each following make an upstream node receiving the backup JM will route the
backup JM towards the source start forwarding on the second topology. The dedicated backup indication MUST be separated from the topology ID, i.e. path
quickly after a
legacy node could send JMs on the secondary topology but will not set
the dedicated backup flag.

4.3. Activation

UTNP SHOULD be originated when an upstream failure has been was detected on the primary multicast tree and the node has UMH, we sent a secondary UMH
installed with stand-by status. Note that
Upstream Tree Notification (UTN) to the upstream failure may
mean not only node on the (directly connected) UMH, but any backup
UMH. The failure up to on the
MCI. Such an upstream failure primary UMH may be local or detected using a
DTN. The UTN received by the upstream node should be processed in several ways (out
of scope). We note, however, that
the reception data-plane and reset the blocking state of a DTNP from the
primary UMH MAY be used as such a trigger.

The UTNP activates OIF. If this node
also joined the blocked OIF on which it was received. The
UTNP is tree in blocking mode upstream, a UTN has to be
forwarded up further upstream. This procedure is repeated until we find
a branching node that is reached, which
discards not in blocking mode or we reached the UTNP and starts forwarding multicast traffic on MCI.

When the leg
from where upstream node resets the UTNP was received (e.g., after unblocking blocking mode in the
respective OIF). If data-plane,
the control plane will still have the blocking mode set. In order
for the control plane to get in sync with the data-plane, the branching node does not consider itself
that originated the UTN MUST also trigger a
reliable forwarder of JM without blocking mode.

The upstream node receiving the multicast traffic of UTN must be able to identify the indicated tree
(e.g., it received a failure indication in
which the form of a DTNP), it
also notification is sent for, as well as the downstream
interface it applies to. The information is encoded in a UTNP after receiving same RNI
item that indication is used for DTN packets. For details please see the
protocol specific sections Section 4 and Section 5.

Like DTN packets, UTN packets are sent via unicast to its secondary
UMH, given it had one.

4.4. the upstream
node.

3.5. MRT/MCI-Only Mode

If each node in the network supports UTN and also all nodes support
MRT, the nodes may work in "MRT/MCI-only" mode.

In MRT/MCI-only mode, there is one single branching point Repair Node for all
failures, the MCI. Other nodes MUST NOT consider themselves as
branching nodes.
Repair Nodes. MRT ensures the necessary maximally disjoint secondary
tree up to the MCI, on a second topology. Only the MCI MUST keep its
OIFs corresponding to the secondary tree blocked. Similarly, only
MCEs MUST keep their secondary backup IIFs blocked. Any other nodes
MUST NOT block their (secondary) IIFs or OIFs.

In MRT/MCI-only mode, the UTNP MUST be forwarded directly to the MCI.
The
This mode enables that a node detecting a downstream failure of the
primary tree MAY send a UTNP upstream towards the source/MCI on the
primary tree.

If an UTNP is received by the MCI on the secondary topology in "MRT/
MCI-only" mode, the MCI MUST unblock the OIF where the UTNP was
received. This activates a whole sub-tree of the secondary tree.

If an UTNP is received by the MCI on the primary topology in "MRT/
MCI-only" mode, the MCI gets no information on which leg to activate
on the secondary tree, so it MUST activate (unblock) all secondary
legs.

3.6. TN Authentication

If a malicious attacker can reproduce the TN packet format, unwanted
reconvergence can be triggered. In order to avoid such attack, a TN
packet MAY contain a digital signature. Having authentication is
optional, it can be enabled or disabled in the network. If however
security is enabled, all the nodes must share the same secret key,
which they get either by configuration or from the multicast routing
protocol. Moreover, for protection against reply attacks, each TN
packet must contain a sequence number.

The sequence numbers in the network are not necessarily synchronised,
instead, each node can have its own. Sequence numbers can be
generated arbitrarily, it can be even some random value; the only
requirement is to create a new sequence number each time a
reconvergence was triggered due to a TN (i.e. the sequence number was
used).

The originator of the DTN packet MUST use the sequence number of the
Repair Node to create a TN signature TLV (see Section 3.7.1.2). For
UTN packet the sender MUST use its own sequence number, what it sent
previously to its UMH. The destination in this case must check
validity based on the sequence number of the sender.

A sequence number is learned from JM and part of the RNI. It is the
responsibility of multicast routing protocol to protect JM against
malicious change.

3.7. The TN Packet

5.1.

3.7.1. TN Packet Format

A Tree Notification is a an IPv4 or IPv6 UDP packet with the following
format.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number Nr | Message Type Address Family | Flags Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TreeInfo Count | TreeInfo size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TreeInfo item - 1 |
~ . ~
| TreeInfo item - n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TN option TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version number: This is a 2 1 octet field encoding the version
number, currently 0.

Message type:

Address Family: This is a 2 octet field encoding a value from
ADDRESS FAMILY NUMBERS in [RFC3232] that encodes the address
family for the Root Address of the tree.

Type: This is a 1 octet field encoding the message type, currently
two are defined;

Type 0: Downstream Tree Notification.

Type 1: Upstream Tree Notification.

Flags: A 1 octet field encoding the flags, currently no flags are
defined, set to zero on send, ignored when received.

Originator ID: 4 bytes long unique ID of the originator. That can
be some loopback IPv4 address owned if there is such, or can be set by
the of the TN originator. operator.

Sequence Number: Number starting unique for each failure case. It is
recommend to start at 0, and to be increased by 1 each time a new
TN is originated. The Sequence number may differ at each node,
thus the sender and the receiver must know the same sequence
number.

TreeInfo count: 2 octet field encoding the number of TreeInfo items
includes.

TreeInfo size: 2 octet field encoding the number of octets use to
encode the TreeInfo's following.

TreeInfo item: The encoding of this field is protocol specific, see
Section 4 and Section 5.

TN option TLVs: TLVs (Type-Length-Value tuples). tuples) describing
additional options for TN packets.

The TLV's have the following format.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: This is a 2 octet field encoding the type number of the TLV.

Length: This is a 2 octet field encoding the length of the Value in
octets.

Value: String of Length octets, to be interpreted as specified by
the Type field.

5.1.1.

3.7.1.1. TN TimeStamp TLV Format

The TimeStamp is an optional TLV that MAY be included when the TN was
originated, it has the following format.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TimeStamp: The TimeStamp is the time-of-day (in seconds and
microseconds, according to the sender's clock) in NTP format [NTP]
when the Tree Notification is sent.

5.2. Origination of

3.7.1.2. TN Packets Signature TLV Format

TN packets SHOULD Signature is an optional TLV, which protects the whole TNP
(including other TLVs) against attacks thus it must be pre-loaded to the data plane cards, e.g. to a
buffer, so that last TLV
if present. The signature is SHA-512 hash value. The input of the
hash function is as follows:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Complete packet only needs to be flushed when needed.
This minimizes content without signature TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secret key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Signature input: The input of the incurred delay.

One TN packet MUST be sent per affected multicast tree. This does
not lead to a scalability problem in practical network deployments,
where it hash function is not expected that a node has to send more than a few
1000s the packet
extended with TN security key

The build up of the TLV is as follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash function result |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signature: SHA-512 signature protecting TN packets.

6. IP/PIM

4. PIM Specific TN Components

The TN UDP datagram is encapsulated in an IP packet with (S,G) set as
source

In this section we are documenting the PIM specific data-structures
and destination in procedures (if they are different from the IP header. Such a generic procedures are
defined in this document). As described in this document, TN packet is
originated for each affected (S,G) multicast tree. packets
are UDP/IP packets sent via unicast to its destination. The UDP
portnumber port
number for PIM is set to an IANA the (to be) assigned IANA port number for
PIM-TN.

4.1. RNI item in PIM TN.

6.1. IP/PIM Downstream Tree Notifications Join Message

As explained before, DTNP is multicasted on each tree on each
outgoing interface (including potential "standby" OIFs). If a node
is a potential repair node for a multicast tree, described previously, PIM must insert the IP forwarding
engine MUST be programmed so that it monitors DTNP packets, which are RNI when sending a PIM
join to its UMH. The RNI includes its router ID, sequence number and
UMH Identifier. The UMH-ID can be recognized among the (S,G) normal data packets based locally unique identifier since
its has only local significance on their
UDP port number. If a DTNP is recognized, the affected tree can Repair Node. A good ID to use
would be
identified from the IP header's source and destination address
fields.

As noted in Section 3.2, nodes MUST NOT forward DTNP outside of the
operator domain. I.e., nodes egressing interface associated with the UMH the domain MUST filter and
discard DTNP packets on their egress interfaces.

The DTN mechanism does not require any update of
PIM related
specifications.

6.2. IP/PIM Upstream Tree Notifications

An originated UTNP join is to be sent upstream to the secondary UMH, i.e.,
upstream through the secondary incoming interface. to. The forwarding
engine MUST be programmed so that despite the UTNP packet having
(S,G) RNI is carried in the IP header, it MUST forward PIM Join as a new PIM
Attribute following [RFC5384]. The PIM RNI attribute has the UTNP packet upstream.
(U)TN(P) packets are to
following format for IPv4.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Type | Length | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Repair Node address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UMH-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

F Forward if not understood.

E End of Attributes, following [RFC5384].

Type: This 6 bit field should be recognized based on their UDP port number.

Only nodes that have installed some OIFs in blocked (backup) status
need to keep monitoring assigned by IANA for UTNP packets. TN specific
JOIN messages.

Length: Length = 10 octets.

Sequence number: 2 octets long field, describing the sequence
number of the sending Repair Node.

Repair Node address: The UTN mechanism requires that, when a node performs router ID of the Repair Node, in IPv4
address format.

UMH-ID: This is a secondary
join, 4 octet field encoding UMH identifier. This is
the IPv4 address of the interface associated with the UMH the PIM JOIN message indicates its dedicated "standby" status.
Such an indication
join is required so that sent to.

Figure 3: PIM IPv4 RNI attribute TLV

The PIM RNI attribute has the recipient following format for IPv6.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Type | Length | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Repair Node address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ UMH-ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

F Forward if not understood.

E End of a standby PIM Attributes, following [RFC5384].

Type: This 6 bit field should be assigned by IANA for TN specific
JOIN can recognise that it can install its interface, through which messages.

Length: Length = 16 octets.

Sequence number: 2 octets long field, describing the standby PIM JOIN was received, into sequence
number of the OIF list sending Repair Node.

Repair Node address: The router ID of the Repair Node, in blocked
state. (A received UTNP could be one trigger to unblock such IPv4
address format.

UMH-ID: This is a
backup OIF.) An extension of PIM JOIN messages and mechanisms 16 octet field encoding UMH identifier. This is
the
responsibility IPv6 address of the interface associated with the UMH the PIM WG. It
join is to be noted sent to.

Figure 4: PIM IPv6 RNI attribute TLV

4.2. Tree Information Item

A TN packet contains one or more TreeInfo items that allows a secondary
status indication has already been proposed Merge
Node to idenfy which tree(s) and interface(s) are effected by the IETF in
[I-D.liu-pim-single-stream-multicast-frr].

6.3. Incremental deployment TN.
The DTNP can be forwarded by legacy nodes as a data packet. So same encoding is used for DTN
can be deployed incrementally if the failure detecting node and
repair nodes support it.

In case of UTN, UTN packets. The PIM TreeInfo
items are defined for IPv4 and IPv6. Which version is to be included
in the (S,G) addressed (U)TN(P) TN packet depends on Address Family in the TN packet. The
UMH-ID included in the DTN MUST be forwarded
towards to source, upstream. This taken from the RNI that was
signalled for that tree. The UMH-ID for UTN packets is in contrast to the normal
forwarding procedures PIM
neighbor address for (S,G) packets. This means that legacy
nodes cannot forward such packets. It remains to be studied if tree. The TreeInfo item has the
UTNP packet can be following
format:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 group address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UMH-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Source Address: This is a unicast packet sent towards 4 octet field encoding the IPv4 source or MCI,
or if the UTNP packet can be tunneled through legacy nodes. In the
current version
address of the spec, legacy nodes cannot handle UTNP. As a
consequence, a node supporting tree. A source address of 0.0.0.0 means that this spec MUST NOT send dedicated
backup JOIN messages
TN relates to a legacy node.

Detecting (*,G) tree.

Group Address: This is a 4 octet field encoding the capability IPv4 group
address of supporting Tree Notifications can be done
via capability advertisement. This should be specified by the PIM
WG. As an indication, it tree.

UMH-ID: This is likely that a "TN-Capable" PIM-Hello
option needs to be standardized.

7. mLDP Specific TN Components

Since MPLS 4 octet field encoding UMH identifier.

Figure 5: PIM IPv4 TreeInfo item

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Source address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 group address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ UMH-ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Source Address: This is used as transport technology, the UTN and DTN are
forwarded up and down a 16 octet field encoding the LSP using MPLS encapsulation. The MPLS
label pushed onto IPv6 source
address of the tree. A source address of 0:0:0:0:0:0:0:0 means
that this TN relates to a (*,G) tree.

Group Address: This is a 16 octet field encoding the label associated with the MP LSP
impacted by the failure. This follows more IPv6 group
address of less the same
mechanism as described in [RFC4379]. Its important that a TN packet tree.

UMH-ID: This is never IP a 16 octet field encoding UMH identifier.

Figure 6: PIM IPv6 TreeInfo item

4.3. Incremental deployment

Joins with a RNI can be forwarded when through legacy nodes if the tail of
Transitive Attribute (see [RFC5384]) has the MP LSP F bit set to 1. It is reached. In
order
up to prevent IP forwarding, the destination address MUST be set network operator to an address from determine this. The DTN functionality
can be deployed incrementally as long as the 127/8 range for IPv4 node detecting the
failure and that same range
embedded Repair Nodes support it.

5. mLDP Specific TN Components

In this section we are documenting the mLDP specific data-structures
and procedures (if they are different from the generic procedures are
defined in as IPv4-mapped IPv6 address. The source address this document). As described in the
IP header MUST be set to an address local this document, TN packets
are UDP/IP packets sent via unicast to the router. its destination. The UDP port
number for mLDP is set to an IANA the (to be) assigned IANA port number for
mLDP-TN.

5.1. RNI item in mLDP TN.

7.1. Label Mapping

The RNI item for mLDP Downstream Tree Notification

7.1.1. Originating is encoded in a DTNP

As LDP MP Status TLV as documented
in [RFC6388] section Section 3.1, a Downstream Tree Notification
is sent by a router that detects a failure of an upstream link or
node. The DTN packet is then sent to each 5. A new LDP neighbor in the
Outgoing Interface List for each MP LSP impact by Status Value Element is created
for this purpose and called the failure using RNI Status. The RNI Status includes
the MPLS Label that this neighbor router ID, sequence number and UMH Identifier. The UMH-ID can be
locally unique identifier since its has assigned for that MP LSP.

7.1.2. Receiving a DTNP

A Downstream Tree Notification Packet is received inline with the
data only local significance on a particular LSP. If
the receiving router is a Repair Node, node. For mLDP the MPLS forwarding logic will monitor value that MUST be used is the MPLS packets in order to
detect Local
Label associated with the DTN packet based on UMH the UDP port number assigned for mLDP
TN. When a DTNP Label Mapping is detected, the outer MPLS label identifies the
LSP. No additional mechanism or lookups are needed here. sent to. The MPLS
forwarding code can immediately activate the standby upstream path
RNI status is carried in Label Mapping messages and disable has the old primary path following the procedures described
in Section 3.2

7.1.3. Forwarding a DTNP

If a router is not a
format.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RNI | Length | Seq. Number .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. | IPv4 Repair Node address .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. | UMH-ID reserved | UMH-ID Label .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. |
+-+-+-+-+-+-+-+-+

RNI Type: This 1 octet field assigned by IANA for RNI Status Value
Element Types.

Length: This is a particular LSP it does not
need to monitor 2 octet field, describing the incoming traffic for that LSP in order to detect length of the DFN packet. Such a router will just forward
Value, Length = 10 octets.

Sequence number: 2 octets long field, describing the DTN packet down sequence
number of the LSP as normal data. Also, routers that don't support DTN
processing will always just forward sending Repair Node.

IPv4 Repair Node address: The IPv4 address of the Repair Node.

UMH-ID reserved: 12 bit field, reserved.

UMH-ID Label: This is a DTN packet 20 bit field encoding a Label as normal data. For
the network to benefit from this feature, not all routers need to be
DTN capable.

7.2. UMH
identifier.

Figure 7: mLDP Upstream RNI Status Value Element

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RNI | Length | Status code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

MBB Type: Type 1 (to be assigned by IANA)

Length: 1
Status code: 1 = MBB request

2 = MBB ack

5.2. Tree Notification

7.2.1. Originating Information Item

A TN packet contains one or more TreeInfo items that allows a UTNP

Following the procedures as described in Section 4.1, an UTNP MAY
need Merge
Node to be originated identify which tree(s) and sent to an upstream LDP neighbor. A P2MP
LSP has no upstream labeled path to reach interface(s) are effected by the root because a P2MP LSP
TN. The same encoding is unidirectional. In order used for DTN and UTN packets. Following
[RFC6388], mLDP will assign a unique Label to create an each upstream path that follows
the P2MP LSP all node per
MP-LSP. This label identifies the way up towards UMH AND the root LSP. Since we apply the procedures are documented in [I-D.ietf-mpls-mldp-hsmp]. A MP2MP LSP already has
an upstream path to the root of the tree, however, these packets are
also forwarded down the tree by other LSRs. There are two possible
approuches, an LSRs that received
using a DTNP on an upstream interface may
just choose label to ignore these packets, or an LSR may filter out DTNP
packets from ever being forwarded down the tree. More details will
be added in later revisions of identify the draft.

7.2.2. Receiving a UTNP

An Upstream Tree Notification UMH and LSP, there is received on the upstream path
associated with the MP LSP by node U. If router U has a downsteam
interface in that MP LSPs OIF list that was joined in standby, it
will move that interface no need to forwarding. define
a IPv4 and IPv6 specific encoding. The outer label Label included in the MPLS
header will identify the MP LSP that is targeted. However, that does
not necessarily identify the downstream LDP neighbor and interface
that needs to DTN
MUST be put in forwarding state. Following the procedures
in [I-D.ietf-mpls-mldp-hsmp] node U MAY assign all the downstream LDP
neighbors the same label for the upstream path. For taken from the purpose of
UTN, node U MUST assign a unique label RNI that was signalled for each downstream LDP
neighbor. If that tree. The
Label for UTN packets is unique, the UTNP will identify the MP LSP
and the downstream LDP neighbor. Since node U Local Label that was allocated for that
tree. The TreeInfo item has selected the
downstream interface, it knows which interface to put in forwarding
mode.

7.2.3. Forwarding following format:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | UMH-Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Reserved: This is a UTNP

A UTNP has 12 bits filed, set to be forward upstream towards the root zero on sending, ignored
when received.

UMH-Label: This is a 20 bit field encoding MPLS Label of the MP LSP
following the procedures as defined in Section 4.3

8. UMH.

Figure 8: mLDP TreeInfo item

6. Acknowledgements

The authors would like express their thanks for Gabor Enyedi for
initial discussions. The authors would also like to thank Stefan
Olofsson and Olofsson, Javed Asghar and
Greg Sheperd for commenting their comments on the draft.

7. IANA Considerations

IANA is requested to allocate UDP port numbers to TN messages. One
port number for TN in IP/PIM context, and another one for MPLS/mLDP
context. The separation of UDP port numbers between IP and MPLS is
requested to prevent problems when a PIM multicast tree is
transported partly through an mLDP multicast tree.

10.

IANA is requested to allocate a value from "PIM Join Attribute" to
make routers capable to advertisement their Tree Notification
capability.

IANA is requested to allocate a value from "PIM Join Attribute Types"
for TN's join command extra information.

A new IANA registry is needed for "TN option TLVs". This describes
the types of TLVs containing extra options for TN messages.

8. Security Considerations

Two types of security problems can be foreseen by the authors:

o Handling illegally injected TN packets

o Handling replay attacks (re-injecting previous TN messages)

o TN messages propagating outside an operator's domain

Illegal TN packets can be handled detected with authentication checks. check.
Providing authentication for TN messages will be considered is described in later
revisions of this spec. Section 3.6.
Prevention of replay attacks needs authentication in combination with
sequence numbering. numbering, which is also described at the same section.

Preventing TN messages that travel inline with data packets MUST be
solved by nodes egressing the operator's domain. Solutions for IP
and MPLS are described in sections Section 6 4 and Section 7, 5,
respectively.

11.

9. References

11.1.

9.1. Normative References

[I-D.ietf-mpls-mldp-hsmp]
Jin, L., JOUNAY, F., Wijnands, I., and N. Leymann, "LDP
Extensions for Hub & Spoke Multipoint Label Switched
Path", draft-ietf-mpls-mldp-hsmp-00 (work in progress),
September 2012.

[I-D.ietf-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Envedi, G., Csaszar, A.,
Konstantynowicz, M., White, R., and M. Shand, "An
Architecture for IP/LDP Fast-Reroute Using Maximally
Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-01
(work in progress), March 2012.

[I-D.karan-mofrr]
Karan, A., Filsfils, C., Farinacci, D., Decraene, B.,
Leymann, N., and W. Henderickx, "Multicast only Fast Re-
Route", draft-karan-mofrr-02 (work in progress),
March 2012.

11.2.

[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format",
RFC 5384, November 2008.

[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011.

9.2. Informative References

[I-D.atlas-rtgwg-mrt-mc-arch]
Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G.
Envedi, "An Architecture for Multicast Protection Using
Maximally Redundant Trees",
draft-atlas-rtgwg-mrt-mc-arch-00 (work in progress),
March 2012.

[I-D.liu-pim-single-stream-multicast-frr]
Liu, H., Zheng, L., Bai, T., and Y. Yu, "Single Stream
Multicast Fast ReRoute (SMFRR) Method",
draft-liu-pim-single-stream-multicast-frr-01
draft-atlas-rtgwg-mrt-mc-arch-01 (work in progress), October 2010.
February 2013.

Authors' Addresses

IJsbrand Wijnands (editor)
Cisco
De kleetlaan 6a
Diegem, 1831
Belgium

Phone:
Email: ice@cisco.com

Luc De Ghein
Cisco
De kleetlaan 6a
Diegem, 1831
Belgium

Phone:
Email: ldeghein@cisco.com

Gabor Sandor Enyedi (editor)
Ericsson
Konyves Kalman Krt 11/B
Budapest, 1097
Hungary

Phone:
Email: Gabor.Sandor.Enyedi@ericsson.com
Andras Csaszar (editor)
Ericsson
Konyves Kalman Krt 11/B
Budapest, 1097
Hungary

Phone:
Email: Andras.Csaszar@ericsson.com

Jeff Tantsura
Ericsson
300 Holger Way
San Jose, California 95134
USA

Email: Jeff.Tantsura@ericsson.com