One document matched: draft-wijnands-rtgwg-mcast-frr-tn-00.txt
Routing Working Group IJ. Wijnands, Ed.
Internet-Draft Cisco
Intended status: Standards Track A. Csaszar, Ed.
Expires: April 18, 2013 J. Tantsura
Ericsson
October 15, 2012
Tree Notification to Improve Multicast Fast Reroute
draft-wijnands-rtgwg-mcast-frr-tn-00
Abstract
This draft proposes using dataplane triggered notifications in order
to support multicast fast reroute methods in various ways. Sending
such notifications down the tree can be used to trigger fail-over in
nodes not adjacent to the failure. Sending such dataplane
notification up the tree can help to activate pre-built standby
backup tree segments.
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.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Wijnands, et al. Expires April 18, 2013 [Page 1]
Internet-Draft Tree Notification for Multicast FRR October 2012
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.
Wijnands, et al. Expires April 18, 2013 [Page 2]
Internet-Draft Tree Notification for Multicast FRR October 2012
Table of Contents
1. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Improving non-local failures . . . . . . . . . . . . . . . . . 5
3.1. Downstream Tree Notifications . . . . . . . . . . . . . . 6
3.2. DTNP processing/forwarding . . . . . . . . . . . . . . . . 6
4. Reduce the bandwidth consumption in failure-free network . . . 8
4.1. Upstream Tree Notifications . . . . . . . . . . . . . . . 8
4.2. Joining a tree in dedicated backup status . . . . . . . . 9
4.2.1. Single topology environment . . . . . . . . . . . . . 9
4.2.2. Multi-Topology Environment . . . . . . . . . . . . . . 10
4.3. Activation . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. MRT/MCI-Only Mode . . . . . . . . . . . . . . . . . . . . 10
5. The TN Packet . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. TN Packet Format . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. TN TimeStamp TLV Format . . . . . . . . . . . . . . . 12
5.2. Origination of TN Packets . . . . . . . . . . . . . . . . 13
6. IP/PIM Specific TN Components . . . . . . . . . . . . . . . . 13
6.1. IP/PIM Downstream Tree Notifications . . . . . . . . . . . 13
6.2. IP/PIM Upstream Tree Notifications . . . . . . . . . . . . 13
6.3. Incremental deployment . . . . . . . . . . . . . . . . . . 14
7. mLDP Specific TN Components . . . . . . . . . . . . . . . . . 14
7.1. mLDP Downstream Tree Notification . . . . . . . . . . . . 15
7.1.1. Originating a DTNP . . . . . . . . . . . . . . . . . . 15
7.1.2. Receiving a DTNP . . . . . . . . . . . . . . . . . . . 15
7.1.3. Forwarding a DTNP . . . . . . . . . . . . . . . . . . 15
7.2. mLDP Upstream Tree Notification . . . . . . . . . . . . . 15
7.2.1. Originating a UTNP . . . . . . . . . . . . . . . . . . 15
7.2.2. Receiving a UTNP . . . . . . . . . . . . . . . . . . . 16
7.2.3. Forwarding a UTNP . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Wijnands, et al. Expires April 18, 2013 [Page 3]
Internet-Draft Tree Notification for Multicast FRR October 2012
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 : Downstream Tree Notification Packet.
UTNP : Upstream Tree Notification Packet.
TNP : Tree Notification Packet, Upstream or Downstream
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 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).
Wijnands, et al. Expires April 18, 2013 [Page 4]
Internet-Draft Tree Notification for Multicast FRR October 2012
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 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 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.
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
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
Wijnands, et al. Expires April 18, 2013 [Page 5]
Internet-Draft Tree Notification for Multicast FRR October 2012
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 node detecting a local failure of its primary UMH MUST originate
a Downstream Tree Notification Packet (DTNP) to all downstream
branches of the tree. Each router that receives the DTNP determines
if it is a Repair Node for that tree. If it is not a Repair Node,
the DTNP is forwarded further down the tree. If the node is the
Repair Node, the secondary UMH is unblocked and the DTNP is
discarded. The DTNP allows a downstream router to unambigously
identify the multicast tree impacted by the failure.
In order to decrease reaction time, the DTNP SHOULD be originated
from the data plane when a local failure is detected, as well as
processed in the data plane when the DTNP is received. All the
information necessary to send and receive a DTNP has to be available
in the data plane in advance.
3.2. DTNP processing/forwarding
When a DTNP is received from an UMH, the node MUST check
o whether it has a secondary UMH, and if yes,
o whether this particular DTNP was received on the primary or
secondary UMH, and
o whether another DTNP had been received beforehand from the other
UMH.
Whenever a node receives a DTNP from its primary UMH and 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 the fact that a DTNP
has been received for 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 the
DTNP.
If a node receives two DTNPs, one from the primary UMH and another
one from the secondary UMH, then this node is not the Repair Node and
Wijnands, et al. Expires April 18, 2013 [Page 6]
Internet-Draft Tree Notification for Multicast FRR October 2012
it MUST forward the last received DTNP to all branches of the tree.
(Secondary UMH does not need to be unblocked since it cannot remedy
the failure.)
A DTNP received only from the secondary UMH MUST NOT be forwarded,
but the node has to store the fact that a DTNP has been received for
the secondary UMH for this multicast tree.
Whenever a decision has been taken to originate or forward a DTNP, it
will be automatically replicated to all downstream legs, given that
it is 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 the
operator network, so MCEs MUST prevent that DTNP packets propagate to
receivers or to other domains. Rephrased, nodes MUST NOT forward
DTNPs to legs that lead to receivers or to external autonomous
systems.
+-+ +-+ +-+ +-+
|F|---|G|---|H|---|I|
+-+ +-+ +-+ +-+
/ \
/ \
+---+ +-+ +-+ +-+ +-+ +-+
|MCI|~~~~~~|A|---|B|---|C|---|D|---|E|
+---+ +-+ +-+ +-+ +-+ +-+
\ / \ /
\ / \ /
+-+ +-+
|J| |K|
+-+ +-+
Figure 1: Remote failure example
As an example, consider Figure 1. If node A fails, B detects the
failure locally and triggers a DTNP (towards C). Node C is not the
Repair Node because it will receive the DTNP from both the primary
UMH (from B) and the secondary UMH (from J). Because node C is not
the Repair node it will forward the DTNP towards K and D (observing
rule 3.). K does not have a secondary UMH for this tree, so it will
send the DTNP downstream towards E (rule 2.). Node D has a secondary
UMH, so it applies rule 1. Node E applies rule 4. As a result,
subscribers sitting at or below nodes D and E will continue receiving
the multicast traffic.
Wijnands, et al. Expires April 18, 2013 [Page 7]
Internet-Draft Tree Notification for Multicast FRR October 2012
4. Reduce the bandwidth consumption in failure-free network
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 in the failure-free network as it
continuously uses bandwidth for both trees or segments. In such
networks it is relevant if the capacity serving backup purposes can
be used in the failure-free network, i.e., most of the time, by 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 not loaded with multicast traffic as long as there
is no failure. 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 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 they are blocked. Packets are not
forwarded to these interfaces unless an Upstream Tree Notification
Packet (UTNP) activates them.
Wijnands, et al. Expires April 18, 2013 [Page 8]
Internet-Draft Tree Notification for Multicast FRR October 2012
Sending notifications upstream helps facilitating live-standby mode
instead of live-live. Whenever a node detects a failure on the
primary tree (the failure being upstream from the node's location), a
UTNP SHOULD be sent upstream towards the source on the secondary tree
segment. It is to be noted that the reception of a DTNP MAY be used
as an upstream failure indication, so it MAY trigger sending a UTNP.
The UTNP activates the secondary tree segments at branching nodes,
i.e., unblocks the secondary OIFs.
Both the secondary JM and the UTNP go up the tree until a branching
node is reached. The branching node is
o in a single topology environment: a node that is part of the
primary tree and that also has a secondary leg; or
o the MCI.
4.2. Joining a tree in dedicated backup status
The secondary join process is almost identical to what the MRT and
MoFRR drafts describe, i.e., a 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 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 a regular JM (including adding a new entry to the OIF
list), but, in addition, the added OIF MUST be marked with "blocked"
flag. Traffic MUST NOT be forwarded through this interface for this
multicast tree while in blocked status.
If a node receives a primary JM after receiving a secondary JM from
the same neighbor, the node MUST reset the corresponding OIF entry to
"unblocked" state. Furthermore, the primary JM MUST be sent 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.
Wijnands, et al. Expires April 18, 2013 [Page 9]
Internet-Draft Tree Notification for Multicast FRR October 2012
4.2.2. Multi-Topology Environment
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 to the backup JM. Not only the repair
node, but each following node receiving the backup JM will route the
backup JM towards the source on the second topology. The dedicated
backup indication MUST be separated from the topology ID, i.e. 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 detected
on the primary multicast tree and the node has a secondary UMH
installed with stand-by status. Note that the upstream failure may
mean not only the (directly connected) UMH, but any failure up to the
MCI. Such an upstream failure may be detected in several ways (out
of scope). We note, however, that the reception of a DTNP from the
primary UMH MAY be used as such a trigger.
The UTNP activates the blocked OIF on which it was received. The
UTNP is forwarded up until a branching node is reached, which
discards the UTNP and starts forwarding multicast traffic on the leg
from where the UTNP was received (e.g., after unblocking the
respective OIF). If the branching node does not consider itself a
reliable forwarder of the multicast traffic of the indicated tree
(e.g., it received a failure indication in the form of a DTNP), it
also sent a UTNP after receiving that indication to its secondary
UMH, given it had one.
4.4. 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 for all
failures, the MCI. Other nodes MUST NOT consider themselves as
branching 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, UTNP MUST be forwarded directly to the MCI.
The 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.
Wijnands, et al. Expires April 18, 2013 [Page 10]
Internet-Draft Tree Notification for Multicast FRR October 2012
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.
5. The TN Packet
5.1. TN Packet Format
A Tree Notification is a 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 | Message Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version number: This is a 2 octet field encoding the version
number, currently 0.
Message 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.
Wijnands, et al. Expires April 18, 2013 [Page 11]
Internet-Draft Tree Notification for Multicast FRR October 2012
Originator ID: IPv4 address owned by the of the TN originator.
Sequence Number: Number starting at 0, and increased by 1 each time
a new TN is originated.
TLVs: TLVs (Type-Length-Value tuples).
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. 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wijnands, et al. Expires April 18, 2013 [Page 12]
Internet-Draft Tree Notification for Multicast FRR October 2012
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 TN Packets
TN packets SHOULD be pre-loaded to the data plane cards, e.g. to a
buffer, so that the packet only needs to be flushed when needed.
This minimizes 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 is not expected that a node has to send more than a few
1000s of TN packets.
6. IP/PIM Specific TN Components
The TN UDP datagram is encapsulated in an IP packet with (S,G) set as
source and destination in the IP header. Such a TN packet is
originated for each affected (S,G) multicast tree. The UDP
portnumber is set to an IANA assigned number for PIM TN.
6.1. IP/PIM Downstream Tree Notifications
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, the IP forwarding
engine MUST be programmed so that it monitors DTNP packets, which are
to be recognized among the (S,G) normal data packets based on their
UDP port number. If a DTNP is recognized, the affected tree can be
identified from the IP header's source and destination address
fields.
As noted in Section 3.2, nodes MUST NOT forward DTNP outside the
operator domain. I.e., nodes egressing 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 is to be sent upstream to the secondary UMH, i.e.,
upstream through the secondary incoming interface. The forwarding
engine MUST be programmed so that despite the UTNP packet having
(S,G) in the IP header, it MUST forward the UTNP packet upstream.
(U)TN(P) packets are to be recognized based on their UDP port number.
Wijnands, et al. Expires April 18, 2013 [Page 13]
Internet-Draft Tree Notification for Multicast FRR October 2012
Only nodes that have installed some OIFs in blocked (backup) status
need to keep monitoring for UTNP packets.
The UTN mechanism requires that, when a node performs a secondary
join, the PIM JOIN message indicates its dedicated "standby" status.
Such an indication is required so that the recipient of a standby PIM
JOIN can recognise that it can install its interface, through which
the standby PIM JOIN was received, into the OIF list in blocked
state. (A received UTNP could be one trigger to unblock such a
backup OIF.) An extension of PIM JOIN messages and mechanisms is the
responsibility of the PIM WG. It is to be noted that a secondary
status indication has already been proposed to the IETF in
[I-D.liu-pim-single-stream-multicast-frr].
6.3. Incremental deployment
The DTNP can be forwarded by legacy nodes as a data packet. So DTN
can be deployed incrementally if the failure detecting node and
repair nodes support it.
In case of UTN, the (S,G) addressed (U)TN(P) packet MUST be forwarded
towards to source, upstream. This is in contrast to the normal
forwarding procedures for (S,G) packets. This means that legacy
nodes cannot forward such packets. It remains to be studied if the
UTNP packet can be a unicast packet sent towards the source or MCI,
or if the UTNP packet can be tunneled through legacy nodes. In the
current version of the spec, legacy nodes cannot handle UTNP. As a
consequence, a node supporting this spec MUST NOT send dedicated
backup JOIN messages to a legacy node.
Detecting the capability of supporting Tree Notifications can be done
via capability advertisement. This should be specified by the PIM
WG. As an indication, it is likely that a "TN-Capable" PIM-Hello
option needs to be standardized.
7. mLDP Specific TN Components
Since MPLS is used as transport technology, the UTN and DTN are
forwarded up and down the LSP using MPLS encapsulation. The MPLS
label pushed onto the TN is the label associated with the MP LSP
impacted by the failure. This follows more of less the same
mechanism as described in [RFC4379]. Its important that a TN packet
is never IP forwarded when the tail of the MP LSP is reached. In
order to prevent IP forwarding, the destination address MUST be set
to an address from the 127/8 range for IPv4 and that same range
embedded in as IPv4-mapped IPv6 address. The source address in the
IP header MUST be set to an address local to the router. The UDP
Wijnands, et al. Expires April 18, 2013 [Page 14]
Internet-Draft Tree Notification for Multicast FRR October 2012
port number is set to an IANA assigned number for mLDP TN.
7.1. mLDP Downstream Tree Notification
7.1.1. Originating a DTNP
As documented in 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 LDP neighbor in the
Outgoing Interface List for each MP LSP impact by the failure using
the MPLS Label that this neighbor has assigned for that MP LSP.
7.1.2. Receiving a DTNP
A Downstream Tree Notification Packet is received inline with the
data on a particular LSP. If the receiving router is a Repair Node,
the MPLS forwarding logic will monitor the MPLS packets in order to
detect the DTN packet based on the UDP port number assigned for mLDP
TN. When a DTNP is detected, the outer MPLS label identifies the
LSP. No additional mechanism or lookups are needed here. The MPLS
forwarding code can immediately activate the standby upstream path
and disable the old primary path following the procedures described
in Section 3.2
7.1.3. Forwarding a DTNP
If a router is not a Repair Node for a particular LSP it does not
need to monitor the incoming traffic for that LSP in order to detect
the DFN packet. Such a router will just forward the DTN packet down
the LSP as normal data. Also, routers that don't support DTN
processing will always just forward a DTN packet as normal data. For
the network to benefit from this feature, not all routers need to be
DTN capable.
7.2. mLDP Upstream Tree Notification
7.2.1. Originating a UTNP
Following the procedures as described in Section 4.1, an UTNP MAY
need to be originated and sent to an upstream LDP neighbor. A P2MP
LSP has no upstream labeled path to reach the root because a P2MP LSP
is unidirectional. In order to create an upstream path that follows
the P2MP LSP all the way up towards the root 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 a DTNP on an upstream interface may
just choose to ignore these packets, or an LSR may filter out DTNP
Wijnands, et al. Expires April 18, 2013 [Page 15]
Internet-Draft Tree Notification for Multicast FRR October 2012
packets from ever being forwarded down the tree. More details will
be added in later revisions of the draft.
7.2.2. Receiving a UTNP
An Upstream Tree Notification 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 to forwarding. The outer label 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 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 the purpose of
UTN, node U MUST assign a unique label for each downstream LDP
neighbor. If that Label is unique, the UTNP will identify the MP LSP
and the downstream LDP neighbor. Since node U has selected the
downstream interface, it knows which interface to put in forwarding
mode.
7.2.3. Forwarding a UTNP
A UTNP has to be forward upstream towards the root of the MP LSP
following the procedures as defined in Section 4.3
8. Acknowledgements
The authors would like express their thanks for Gabor Enyedi for
initial discussions. The authors would also like to thank Stefan
Olofsson and Javed Asghar for commenting on the draft.
9. 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. Security Considerations
Two types of security problems can be foreseen by the authors:
o Handling illegally injected TN packets
Wijnands, et al. Expires April 18, 2013 [Page 16]
Internet-Draft Tree Notification for Multicast FRR October 2012
o Handling replay attacks (re-injecting previous TN messages)
o TN messages propagating outside an operator's domain
Illegal TN packets can be handled with authentication checks.
Providing authentication for TN messages will be considered in later
revisions of this spec.
Prevention of replay attacks needs authentication in combination with
sequence numbering.
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 and Section 7,
respectively.
11. References
11.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. 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.
Wijnands, et al. Expires April 18, 2013 [Page 17]
Internet-Draft Tree Notification for Multicast FRR October 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 (work in
progress), October 2010.
Authors' Addresses
IJsbrand Wijnands (editor)
Cisco
De kleetlaan 6a
Diegem, 1831
Belgium
Phone:
Email: ice@cisco.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
Wijnands, et al. Expires April 18, 2013 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-21 23:27:39 |