draft-ietf-pim-ecmp-03.txt   draft-ietf-pim-ecmp-04.txt 
Network Working Group Yiqun Cai Network Working Group Yiqun Cai
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track Liming Wei Intended status: Standards Track Liming Wei
Expires: October 29, 2012 Heidi Ou Expires: December 30, 2012 Heidi Ou
Cisco Systems, Inc. Cisco Systems, Inc.
Vishal Arya Vishal Arya
Sunil Jethwani Sunil Jethwani
DIRECTV Inc. DIRECTV Inc.
April 27, 2012 June 28, 2012
Protocol Independent Multicast ECMP Redirect Protocol Independent Multicast ECMP Redirect
draft-ietf-pim-ecmp-03.txt draft-ietf-pim-ecmp-04.txt
Abstract Abstract
A Protocol Independent Multicast (PIM) [RFC4601] router uses the A Protocol Independent Multicast (PIM) router uses the Reverse Path
Reverse Path Forwarding (RPF) procedure to select an upstream Forwarding (RPF) procedure to select an upstream interface and router
interface and router to build forwarding state. When there are equal to build forwarding state. When there are equal cost multiple paths
cost multiple paths (ECMP), existing implementations often use hash (ECMP), existing implementations often use hash algorithms to select
algorithms to select a path. Such algorithms do not allow the spread a path. Such algorithms do not allow the spread of traffic among the
of traffic among the ECMPs according to administrative metrics. This ECMPs according to administrative metrics. This usually leads to
usually leads to inefficient or ineffective use of network resources. inefficient or ineffective use of network resources. This document
This document introduces the ECMP Redirect, a mechanism to improve introduces the ECMP Redirect, a mechanism to improve the RPF
the RPF procedure over ECMPs. It allows ECMP path selection to be procedure over ECMPs. It allows ECMP path selection to be based on
based on administratively selected metrics, such as data transmission administratively selected metrics, such as data transmission delays,
delays, path preferences and routing metrics. path preferences and routing metrics.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 29, 2012. This Internet-Draft will expire on December 30, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6
3.1. Sending ECMP Redirect . . . . . . . . . . . . . . . . . . 6 3.1. Sending ECMP Redirect . . . . . . . . . . . . . . . . . . 6
3.2. Receiving ECMP Redirect . . . . . . . . . . . . . . . . . 6 3.2. Receiving ECMP Redirect . . . . . . . . . . . . . . . . . 7
3.3. Transient State . . . . . . . . . . . . . . . . . . . . . 6 3.3. Transient State . . . . . . . . . . . . . . . . . . . . . 7
3.4. Interoperability . . . . . . . . . . . . . . . . . . . . . 7 3.4. Interoperability . . . . . . . . . . . . . . . . . . . . . 8
3.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 8
3.5.1. PIM ECMP Redirect Hello Option . . . . . . . . . . . . 8 3.5.1. PIM ECMP Redirect Hello Option . . . . . . . . . . . . 8
3.5.2. PIM ECMP Redirect Format . . . . . . . . . . . . . . . 8 3.5.2. PIM ECMP Redirect Format . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 10 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses terms defined in [RFC4601] to describe actions This document uses terms defined in [RFC4601] to describe actions
taken by PIM routers. taken by PIM routers.
The following terms have special significance for ECMP Redirect: The following terms have special significance for ECMP Redirect:
o Equal Cost Multiple Path (ECMP). In this document, the term ECMP o Equal Cost Multiple Path (ECMP). In this document, the term ECMP
refers to parallel, single-hop, equal cost links between adjacent refers to parallel, single-hop, equal cost links between adjacent
nodes. nodes.
o ECMP Bundle. An ECMP bundle is a set of PIM enabled interfaces on o ECMP Bundle. An ECMP bundle is a set of PIM enabled interfaces on
a router, where all interfaces belonging to the same bundle share a router, where all interfaces belonging to the same bundle share
the same routing metric. The ECMP links reside between the the same routing metric. The next hops for the ECMP are all 1 hop
upstream and downstream routers over the ECMP bundle. away.
There can be one or more ECMP bundles on any router, while one There can be one or more ECMP bundles on any router, while one
individual interface can only belong to a single bundle. ECMP individual interface can only belong to a single bundle. ECMP
bundles are created on a router via configuration. bundles are created on a router via configuration.
o RPF. RPF stands for Reverse Path Forwarding. o RPF. RPF stands for Reverse Path Forwarding.
o Upstream. Towards the root of the multicast forwarding tree. An o Upstream. Towards the root of the multicast forwarding tree. An
upstream router refers to a router that is forwarding, or upstream router refers to a router that is forwarding, or
potentially capable of forwarding data packets onto interfaces in potentially capable of forwarding data packets onto interfaces in
skipping to change at page 6, line 9 skipping to change at page 6, line 9
mechanism provides a means for an upstream router to instruct a mechanism provides a means for an upstream router to instruct a
downstream router to choose a different RPF path. downstream router to choose a different RPF path.
This specification does not dictate the scope of applications of this This specification does not dictate the scope of applications of this
mechanism. mechanism.
3. Protocol Specification 3. Protocol Specification
3.1. Sending ECMP Redirect 3.1. Sending ECMP Redirect
ECMP Redirects are sent by a preferred upstream router in a rate ECMP Redirects are sent by an upstream router in a rate limited
limited fashion, under the following conditions, fashion, under the following conditions,
o It detects a PIM Join on a non-desired outgoing interface; or o It detects a PIM Join on a non-desired outgoing interface; or
o It detects multicast traffic on a non-desired outgoing interface. o It detects multicast traffic on a non-desired outgoing interface.
In both cases, an ECMP Redirect is sent to the non-desired interface. In both cases, an ECMP Redirect is sent to the non-desired interface.
An outgoing interface is considered "non-desired" when, An outgoing interface is considered "non-desired" when,
o The upstream router is already forwarding the same flow out of o The upstream router is already forwarding the same flow out of
another interface belonging to the same ECMP bundle; another interface belonging to the same ECMP bundle;
o The upstream router is not forwarding the flow yet out any o The upstream router is not forwarding the flow yet out any
interfaces of the ECMP bundle, but there is another interface with interfaces of the ECMP bundle, but there is another interface with
more desired attributes. more desired attributes.
An upstream router MAY choose not to send ECMP Redirects if it An upstream router MAY choose not to send ECMP Redirects if it
becomes aware that some of the downstream routers are unreachable via becomes aware that some of the downstream routers are unreachable via
some links in ECMP bundle. some links in ECMP bundle.
An upstream router uses the "Neighbor Address" or the "Interface ID"
field in the ECMP Redirect message to indicate the interface it wants
traffic to be directed to. This Neighbor Address MUST be associated
with an interface in the same ECMP bundle as the ECMP Redirect
message's outgoing interface. If the Interface ID field is ignored,
this Neighbor Address field uniquely identifies a LAN and an upstream
router to which a downstream router SHOULD redirect its Join
messages, and an ECMP Redirect message MUST be discarded if the
Neighbor Address field in the message does not match the cached
neighbor address.
The Interface ID field is used in IPv4 when one or more RPF neighbors
in the ECMP bundle are unnumbered, or in IPv6 where link local
addresses are in use. For other IPv4 usage, this field is zero'ed
when sent, and ignored when received. If the "Router ID" part of the
Interface ID is zero, the field MUST be ignored. See [RFC6395] for
details of its assignment and usage in PIM Hellos. If the Interface
ID is not ignored, the receiving router of this message MUST use the
Interface ID, instead of Neighbor Address, to identify the new RPF
neighbor, and an ECMP Redirect message MUST be discarded if the
Interface ID field in the message does not match the cached interface
ID.
3.2. Receiving ECMP Redirect 3.2. Receiving ECMP Redirect
When a downstream router receives an ECMP Redirect, and detects that When a downstream router receives an ECMP Redirect, and detects that
the desired RPF path from its upstream router's point of view is the desired RPF path from its upstream router's point of view is
different from its current one, it SHOULD choose to prune from the different from its current one, it should choose to join the newly
current path and join the new path. The exact order of such actions suggested path and prune from the current path. The exact order of
is implementation specific. such actions is implementation specific.
If a downstream router receives multiple ECMP Redirects sent by If a downstream router receives multiple ECMP Redirects sent by
different upstream routers, it SHOULD use the Preference, Metric, or different upstream routers, it SHOULD use the Preference, Metric, or
other fields as specified below, as the tie breakers to choose the other fields as specified below, as the tie breakers to choose the
most preferred RPF interface and neighbor. most preferred RPF interface and neighbor.
If an upstream router receives an ECMP Redirect, it SHOULD NOT change If an upstream router receives an ECMP Redirect, it SHOULD NOT change
its forwarding behavior even if the ECMP Redirect makes it a less its forwarding behavior even if the ECMP Redirect makes it a less
preferred RPF neighbor on the receiving interface. preferred RPF neighbor on the receiving interface.
3.3. Transient State 3.3. Transient State
During a transient network outage with a single link cut in an ECMP During a transient network outage with a single link cut in an ECMP
bundle, a downstream router may lose connection to its RPF neighbor bundle, a downstream router may lose connection to its RPF neighbor
and the normal ECMP Redirect operation may be interrupted and the normal ECMP Redirect operation may be interrupted
temporarily. In such an event, the following actions are temporarily. In such an event, the following actions are
RECOMMENDED. RECOMMENDED.
The downstream router may select a new RPF neighbor. Among all ECMP The downstream router SHOULD select a new RPF neighbor. Among all
upstream routers, the one on the same LAN as the previous RPF ECMP upstream routers, the one on the LAN the previous RPF neighbor
neighbor is preferred. resided on is preferred.
If there is no upstream router reachable on the same LAN, the If there is no upstream router reachable on the LAN the previous RPF
downstream router will select a new RPF neighbor on a different LAN. neighbor resided on, the downstream router will select a new RPF
Among all ECMP upstream routers, the one that served as RPF neighbor neighbor on a different LAN. Among all ECMP upstream routers, the
before the link failure is preferred. Such a router can be one that served as RPF neighbor before the link failure is preferred.
identified by the Router ID, which is part of the Interface ID in the Such a router can be identified by the Router ID, which is part of
PIM ECMP Redirect Hello option. the Interface ID in the PIM ECMP Redirect Hello option.
During normal ECMP Redirect operations, when PIM Joins for the same During normal ECMP Redirect operations, when PIM Joins for the same
(*,G) or (S,G) are received on a different LAN, an upstream router (*,G) or (S,G) are received on a different LAN, an upstream router
will send ECMP Redirect to prune the non-preferred LAN. Such ECMP will send ECMP Redirect to prune the non-preferred LAN. Such ECMP
Redirects during partial network outage can be suppressed if the Redirects during partial network outage can be suppressed if the
upstream router decides that the non-preferred PIM Join is from a upstream router decides that the non-preferred PIM Join is from a
router that is not reachable via the preferred LAN. This check can router that is not reachable via the preferred LAN. This check can
be performed by retrieving the downstream's Router ID, using the be performed by retrieving the downstream's Router ID, using the
source address in the PIM Join, and searching neighbors on the source address in the PIM Join, and searching neighbors on the
preferred LAN for one with the same router ID. preferred LAN for one with the same router ID.
skipping to change at page 9, line 5 skipping to change at page 9, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | | | Preference | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-- ... Metric ... -+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-- ... Metric ... -+-+-+-+-+-+-+-+-+
| | | |
+- .. Metric .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +- .. Metric .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 2: ECMP Redirect Message Format Figure 2: ECMP Redirect Message Format
Type: TBD PIM Ver: See section 4.9 in [RFC4601].
Type: To be assigned by IANA.
Reserved: See section 4.9 in [RFC4601].
Checksum: See section 4.9 in [RFC4601].
Group Address (64/160 bits): Encoded-Group address as specified in
section 4.9.1 of [RFC4601].
Source Address (48/144 bits): Encoded-Unicast address as specified
in section 4.9.1 of [RFC4601].
Neighbor Address (32/128 bits): Address of desired upstream Neighbor Address (32/128 bits): Address of desired upstream
neighbor where the downstream receiver SHOULD redirect PIM Joins. neighbor where the downstream receiver redirects PIM Joins.
This address MUST be associated with an interface in the same ECMP Interface ID (64 bits): See [RFC6395] for details.
bundle as the ECMP Redirect message's outgoing interface. If the
"Interface ID" field (see below) is ignored, this "Neighbor
Address" field uniquely identifies a LAN and an upstream router to
which a downstream router SHOULD redirect its Join messages, and
an ECMP Redirect message MUST be discarded if the "Neighbor
Address" field in the message does not match cached neighbor
address.
Interface ID (64 bits): This field is used in IPv4 when one or more
RPF neighbors in the ECMP bundle are unnumbered, or in IPv6 where
link local addresses are in use. For other IPv4 usage, this field
is zero'ed when sent, and ignored when received. If the "Router
ID" part of the "Interface ID" is zero, the field MUST be ignored.
See [RFC6395] for details of its assignment and usage in PIM
Hellos. If the "Interface ID" is not ignored, the receiving
router of this message MUST use the "Interface ID", instead of
"Neighbor Address", to identify the new RPF neighbor, and an ECMP
Redirect message MUST be discarded if the "Interface ID" field in
the message does not match the cached interface ID.
Preference (8 bits): The first tie breaker when ECMP Redirects from Preference (8 bits): The first tie breaker when ECMP Redirects from
multiple upstream routers are compared against each other. multiple upstream routers are compared against each other.
Numerically smaller value is preferred. A reserved value (15) is Numerically smaller value is preferred. A reserved value (15) is
used to indicate the metric value following the "Preference" field used to indicate the metric value following the "Preference" field
is a Network Time Protocol (NTP) timestamp, encoded in the format is a Network Time Protocol (NTP) timestamp, encoded in the format
specified in [RFC5905], taken at the moment the sending router specified in [RFC5905], taken at the moment the sending router
started to forward out of this interface. started to forward out of this interface.
Metric (64 bits): The second tie breaker if the "Preference" values Metric (64 bits): The second tie breaker if the "Preference" values
are the same. Numerically smaller metric is preferred. This are the same. Numerically smaller metric is preferred. This
"Metric" can contain path parameters defined by users. When both "Metric" can contain path parameters defined by users. When both
"Preference" and "Metric" values are the same, "Neighbor Address" "Preference" and "Metric" values are the same, "Neighbor Address"
or "Interface ID" field is used as the third tie-breaker, or "Interface ID" field is used as the third tie-breaker,
depending on which field is used to identify the RPF neighbor, and depending on which field is used to identify the RPF neighbor, and
the bigger value wins. the bigger value wins.
4. IANA Considerations 4. IANA Considerations
skipping to change at page 10, line 11 skipping to change at page 10, line 30
A PIM Message Type (TBD) is requested to be assigned to the ECMP A PIM Message Type (TBD) is requested to be assigned to the ECMP
Redirect message. According to [RFC6166], the next available Type Redirect message. According to [RFC6166], the next available Type
value is 11 (0xB). value is 11 (0xB).
5. Security Considerations 5. Security Considerations
Security of the ECMP Redirect is only guaranteed by the security of Security of the ECMP Redirect is only guaranteed by the security of
the PIM packet, the security considerations for PIM Assert packets as the PIM packet, the security considerations for PIM Assert packets as
described in [RFC4601] apply here. Spoofed ECMP Redirect packets may described in [RFC4601] apply here. Spoofed ECMP Redirect packets may
cause the downstream routers to send PIM Joins to an undesired cause the downstream routers to send PIM Joins to an undesired
upstream router, and trigger more ECMP Redirect messages. upstream router, and trigger more ECMP Redirect messages. Security
considerations for PIM packets described in [RFC4601] also apply to
the new hello option defined here.
6. Acknowledgement 6. Acknowledgement
The authors would like to thank Apoorva Karan for helping with the The authors would like to thank Apoorva Karan for helping with the
original idea, Eric Rosen, Isidor Kouvelas, Toerless Eckert, Stig original idea, Eric Rosen, Isidor Kouvelas, Toerless Eckert, Stig
Venaas, Jeffrey Zhang, Bill Atwood and Adrian Farrel for their review Venaas, Jeffrey Zhang, Bill Atwood and Adrian Farrel for their review
comments. comments.
7. References 7. References
 End of changes. 18 change blocks. 
60 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/