wdiff draft-shen-pim-nnhop-nodes-00.txt draft-shen-pim-nnhop-nodes-01.txt

Network Working Group Naiming Shen
Internet Draft Liming Wei
Redback Networks
Expiration Date: June 2004 January 2005 Dino Farinacci
Procket Networks

December 2003

July 2004

Discovering PIM-SM Next-Nexthop Downstream Nodes

<draft-shen-pim-nnhop-nodes-00.txt>

<draft-shen-pim-nnhop-nodes-01.txt>

Status of this Memo

This document is an Internet-Draft

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and is any of which I become aware will be
disclosed, in full conformance accordance with
all provisions of Section 10 of RFC2026. RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

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.''

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document specifies extensions to PIM-SM in support of
next-nexthop downstream node discovery. This next-nexthop node
information can be used for PIM to fast re-route multicast
traffic onto explicitly routed tunnels, for downstream node
protection in case of outbound link or nexthop node failure.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [3].

1. Introduction

PIM-SM as defined in [1] creates PIM distribution trees by
downstream PIM nodes sending Join/Prune messages to either (*,G)
or (S,G) upstream PIM nodes. These Join/Prune messages are sent
hop by hop towards the RP or the sources of the group.
It is possible for a PIM node to know the direct downstream
neighbors, but currently it has no mechanism to learn the
downstream nodes of the adjacent neighbors, or the next-nexthop
downstream nodes. This document proposes an PIM-SM extension
to allow a PIM node to discover its next-nexthop downstream
neighbors.

One application for learning the next-nexthop downstream PIM
neighbors is IP multicast traffic fast re-route in NFRR (Nexthop
Fast ReRoute) node-protection [2]. The NFRR scheme allows a
node to perform fast re-route of IP multicast traffic onto a
(LSP) tunnel in case of a link or node failure. Such a Nexthop
Fast ReRoute tunnel will most likely be a MPLS TE LSP, but it can
be a source routed IP tunnel or a sub-IP tunnel.

When the NFRR is used for node-protection for IP multicast
traffic, a node acting as the Point of Local Repair (PLR) has
tunnels that terminate in the next-nexthop downstream PIM nodes.
These next-nexthop downstream nodes receive traffic forwarded by
the PLR through the protected node. For each multicast forwarding
path going through the PLR and the downstream protected node,
the PLR needs to learn the identity of the next-nexthop neighbors.

To discover PIM-SM next-nexthop downstream nodes, a PIM node needs
to learn its directly connected downstream nodes first. Thus
the downstream nodes MUST NOT suppress their Join/Prunes to the
upstream neighbors over the multi-access interfaces.

In order to allow the PLR to dynamicly associate an OIF (or a
protected downstream neighbor) of a (*,G) or (S,G), with a
tunnel (or tunnels) leading to the correct next-nexthop neighbors,
the PLR needs to learn the association between a next-nexthop
neighbor's interface address and the remote NFRR tunnel end point.
Since the NFRR tunnel's remote end point uses a router-ID, this
router-ID needs to be communicated back to the PLR node.

A new message type and a new Encoded Next-Nexthop Address format
is defined in this document to relay the downstream's Join/Prune
information to the upstream neighbors. This scheme allows a
PIM-SM node to send join/prune information with two-hop limit
upstream.

Two new Option Types are defined for PIM Hello message. One of
them is to indicate the sender is interested in receiving the
next-nexthop Join/Prune messages from the neighbors. Another
is to advertise the sender's router-ID in the Hello message.

2. Discovering PIM-SM Next-Nexthop Downstream Nodes Scheme

This PIM-SM extension involves 3 new actions: 1) downstream PIM
nodes advertise router ID in PIM Hello messages; 2) upstream PIM
nodes send Next-Nexthop Node Request to downstream nodes in Hello
messages; and 3) a PIM node modifies and relays downstream's
Join/Prune messages to all relevant upstream nodes. For each
(*,G) or (S,G), the PIM PLR node builds a relation of downstream
nodes and next-nexthop downstream nodes. When the outbound
interface going to the downstream node is down or the downstream
node itself is down, the PLR node can fast re-route the multicast
traffic directly to those next-nexthop downstream nodes using the
pre-built NFRR tunnels.

2.1 Example

The diagram below shows an example of this scheme.

lsp1
+---------------------------+
(S,G) | |
(upstreams) | <--- J/P --- V downstream
[R1]====>[R2]a=======>b[R3]=======>c[R4]-- (to receivers)
<- NNhop J/P --

Figure 1: NFRR node-protection for IP multicast traffic

Node R2 is the PLR (Point of Local Repair). It is configured
with an NFRR LSP for the purpose of protecting node R3. Assume R3
is the downstream PIM node of R2 for a (S,G), R4 is the
downstream node of R3 for the same (S,G). The links between the
nodes can be either point-to-point or multi-access.

R2 indicates to R3 in PIM Hellos, that it is interested in receiving
R3's downstream Join/Prune messages. R4 advertises its router-ID
to R3 in its Hello messages. When R3 receives a Join/Prune message
for the (S,G), it resends it in a Next-Nexthop Join/Prune (NNJP)
message to its upstream neighbor R2. This NNJP contains R4's
router-ID, which R3 learned from R4's Hello message. This NNJP
message is unicast directed at R2,

After R2 receives the relayed messages from R3, it can make the
association of its downstream R3 with NFRR LSP lsp1 for the (S,G).
In the case of link "a" going down, the multicast forward engine
on R2 can quickly switch the traffic for the (S,G) from OIF
of interface "a" onto lsp1. The RPF checks on R4 needs to
to accept multicast traffic from lsp1. The mechanism of this
modified RPF check for re-routed multicast traffic is described
in [2].

In a topology more complicated than that shown in figure 1, there
are multiple LSPs associated with a (S,G) over an oif, going to
multiple next-nexthop nodes.

2.2 Router-ID Option in Hello Message

A new option is defined to support the advertisement of a PIM
node's router-ID. A router-ID is a 4 byte number uniquely
identifying a PIM node. The same router-ID is also be used to
establish the tail-end of the NFRR LSP. A PLR PIM node makes
the association of a next-nexthop downstream node and a NFRR
tunnel based on the router-ID.

A router may have multiple router-IDs for different applications.
The router-ID being used for this option MUST match the NFRR LSP
destination address in order for PIM-SM on the PLR to make the
association.

2.3 Next-Nexthop Node Request Option in Hello Message

This option is used by an upstream node to indicate to its
downstream nodes that it is interested in receiving the
Join/Prune messages of their downstream nodes. An upstream
node can optionally send the Next-Nexthop Node Request when
there is at least one NFRR tunnel configured to protect the
downstream nodes over the interface. This request is implicitly
withdrawn if the last NFRR tunnel is torn down (or a NFRR LSP
is removed). Upon receiving the Hello messages with the
Next-Nexthop Node Request, a PIM node SHOULD relay the modified
Join/Prune messages from its downstream nodes to the relevant
upstream nodes who requested the service.

2.4 Next-Nexthop Node Address in Next-Nexthop Join/Prune Message

A new Next-Nexthop Join/Prune Message is defined for an PIM
node to modify and relay the downstream Join/Prune messages
to their corresponding upstream neighbors. The format of the
message is the same as the Join/Prune message except that
the Encoded Upstream Neighbor Unicast Address is replaced by
the Encoded Next-Nexthop Address and the message is destined
to a unicast interface address of the upstream neighbor.

A new Encoded Next-Nexthop Node Address is defined for this
scheme. The address family code and the Encoding Type are not
changed. The Address field includes the downstream node router-ID
and the downstream interface IP address. This new Encoded Address
is used in the Next-Nexthop Join/Prune Message to re-group the
(S,G)s for each upstream neighbors. A PIM node MUST silently drop
the packet if it does not support this Next-Nexthop Node extension,
or the sender of the message is not one of the downstream nodes
it protects, or the interface where it received this NNhop
Join/Prune message is pruned.

3. Packet Format

3.1 Router-ID Option in Hello Message

The Value field of the option Router-ID is a 4 byte number. This
option can be included in the Hello message to advertise the
unique address of the router.

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 (IANA allocate) | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2 Next-Nexthop Node Request Option in Hello Message

This option is used by upstream node to inform the downstream nodes
that it is interested in receiving the Next-Nexthop Node
information. This option can be included in the Hello message.

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 (IANA allocate) | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3 Next-Nexthop Join/Prune Message

This is a new PIM-SM message type. The code is to be allocated
by IANA. This message has the same format as the normal Join/Prune
message except for:

- the Next-Nexthop Node Address replaces the Upstream Neighbor
Unicast Address in Join/Prune message.

- the message is destined to an unicast interface address of
the intended upstream PIM neighbor.

This modified Join/Prune message is sent to the neighbor's
interface unicast address with TTL 1. This message MUST only
contain the (S,G)s or (*,G) which share the same upstream PIM
neighbor.

3.4 Next-Nexthop Node Address

This Next-Nexthop Node Address is used by a PIM node to replace
the Upstream Neighbor Address in the original Join/Prune message.

This Address contains the interface address and router-ID from the
next-nexthop PIM neighbor's original join/prune message.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Router ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID (Continued) | Unicast Address (Interface)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

Addr Family - The PIM address family of the Unicast Address of
Interface field of this address.

Encoding Type - The value is set to 0.

Router ID - A 4 byte number to represent the unique address of
an downstream PIM node.

Unicast Interface Address - The interface address of the downstream
PIM neighbor.

4. Security Considerations

This mechanism does not introduce any new security issue in LDP.

5. IANA Considerations

The Router-ID and Next-Nexthop Node Request option types
in Hello messages, the Next-Nexthop Join/Prune Mesage type and
the Next-Nexthop Node Address are proposed in this document.
This PIM-SM extension requires that IANA allocate those numbers.

6. Acknowledgments

The authors would like to thank Yiqun Cai for the discussion and
comments to this document.

7. References

[1] Estrin, et al., "Protocol Independent Multicast-Sparse Mode
(PIM- SM): Protocol Specification", RFC 2362, June 1998.

[2] Shen, N., Pan, P., "Nexthop Fast ReRoute for IP and MPLS",
Internet draft, draft-shen-nhop-fastreroute-01.txt, work in
progress.

[3] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

8. Author's Addresses

Naiming Shen
Redback Networks
300 Holger Way
San Jose, CA 95134
Email: naiming@redback.com

Liming Wei
Redback Networks
300 Holger Way
San Jose, CA 95134
Email: lwei@redback.com

Dino Farinacci
Procket Networks
dino@procket.com

7. Intellectual Property Considerations

Redback Networks may have

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed in
regard to some
pertain to the implementation or use of the specification contained technology described in
this document.

This document and translations of it may be copied and furnished or the extent to
others, and derivative works that comment on which any license under such rights
might or otherwise explain might not be available; neither does it
or assist represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in its implementation may be prepared, copied, published standards-track and distributed, in whole or
standards-related documentation can be found in part, without restriction BCP-11. Copies of
claims of rights made available for publication and any
kind, provided that assurances of
licenses to be made available, or the above copyright notice and this paragraph are
included on all result of an attempt made to
obtain a general license or permission for the use of such copies and derivative works. However,
proprietary rights by implementors or users of this
document itself may not specification can
be modified in any way, such as by removing obtained from the copyright notice or references IETF Secretariat.

The IETF invites any interested party to the Internet Society bring to its attention any
copyrights, patents or patent applications, or other
Internet organizations, except as needed for the purpose of
developing Internet standards in proprietary
rights which case the procedures for
copyrights defined in the Internet Standards process must may cover technology that may be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by practice
this standard. Please address the information to the IETF Executive
Director.

8. Full Copyright Notice

Copyright (C) The Internet Society or its successors or assigns. (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

9. References

[1] Estrin, et al., "Protocol Independent Multicast-Sparse Mode
(PIM- SM): Protocol Specification", RFC 2362, June 1998.

[2] Shen, N., Pan, P., "Nexthop Fast ReRoute for IP and MPLS",
Internet draft, draft-shen-nhop-fastreroute-00.txt, work in
progress.

[3] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

10. Author's Addresses

Naiming Shen
Redback Networks
300 Holger Way
San Jose, CA 95134
Email: naiming@redback.com

Liming Wei
Redback Networks
300 Holger Way
San Jose, CA 95134
Email: lwei@redback.com

Dino Farinacci
Procket Networks
dino@procket.com