One document matched: draft-raggarwa-pim-sm-remote-nbr-00.txt

Network Working Group                                  Rahul Aggarwal
Internet Draft                                         Tom Pusateri
Expiration Date: March 2004                            Juniper Networks

           PIM-SM Extensions for Supporting Remote Neighbors

                draft-raggarwa-pim-sm-remote-nbr-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 describes protocol extensions to PIM-SM for supporting
   PIM-SM neighbors that are not directly connected. The mechanism
   described herein makes use of PIM-SM Hello messages that are directed
   to the remote neighbor. Following the discovery of the remote
   neighbor PIM-SM Join and Prune messages can be exchanged.













draft-raggarwa-pim-sm-remote-nbr-00.txt                         [Page 1]

Internet Draft   draft-raggarwa-pim-sm-remote-nbr-00.txt  September 2003


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 [KEYWORDS].


1. Introduction

   PIM-SM as described in [PIM-SM] can be used for multicast routing in
   a network topology where all the participating routers are directly
   connected.  This does not apply to network topologies where it is
   desirable to exchange multicast routing information between non-
   directly connected i.e. remote neighbors. One approach, in this case,
   is to setup tunnels between the remote routers and model the tunnels
   as PIM-SM interfaces. However this requires the setup of tunnels and
   is operationally expensive.

   This document describes extensions to [PIM-SM] that can be used for
   multicast routing in a network topology with remote neighbors. The
   proposed mechanism is based on "directed" Hello messages that are
   exchanged between remote neighbors to establish remote neighbor
   adjacencies. Once the remote neighbor has been learned PIM-SM Join
   and Prune messages can be exchanged between the remote neighbors.


2. Directed Hello Messages

   [PIM-SM] relies on Hello messages to perform neighbor discovery. As
   described in [PIM-SM] Hello messages are sent periodically on each
   PIM-enabled interface.

   PIM Hello messages are sent to the ALL-PIM-ROUTERS link local IP
   multicast group with a TTL of 1. Neighbors will not accept Join or
   Prune messages from a router unless they have first heard a Hello
   message from that router.

   In the case of non-directly connected routers, the only existing
   mechanism for exchanging Hello messsages is to: a) Setup a tunnel
   between the remote routers and b) Model the tunnel as a PIM-SM
   interface. However this is not always desirable and is operationally
   expensive.

   This document introduces the concept of "directed" Hello messages to
   send Hello messages between remote routers. A directed Hello message
   is unicast to a remote router. A directed Hello message is sent once
   the local router decides to setup a neighbor adjacency with the
   remote router. This may be based on configuration or other mechanisms



draft-raggarwa-pim-sm-remote-nbr-00.txt                         [Page 2]

Internet Draft   draft-raggarwa-pim-sm-remote-nbr-00.txt  September 2003


   that are outside the scope of this document. Neighbor discovery is
   complete when the remote router sends a directed Hello message back
   to the originating router. This may be in response to the received
   Hello message or may be driven by configuration or based on other
   mechanisms outside the scope of this document.

   A directed Hello message is sent to a unicast address belonging to
   the remote router. The source address is set to an address of the
   local router. For example these addresses may be the loopback
   addresses of the respective routers. A new OptionType is introduced
   in the Hello message to identify a directed Hello message.

   OptionType 21 (To be assigned by IANA) Directed Hello


       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 = 21          |         Length = 4            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Reserved                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The Directed Hello OptionType MUST be included in a directed Hello
   message.  It is to be noted that an implementation may reject Hello
   messages if they are not received on a PIM-SM enabled interface.
   However this MUST be relaxed if the Hello message is a directed
   Hello.

   Once directed Hello messages have been exchanged between remote
   neighbors, they can start exchanging Join and Prune messages as
   described in the next section.


3. Join/Prune Messages Between Remote Neighbors

   As described in [PIM-SM] Join/Prune messages should only be accepted
   for processing if they are received from a known PIM-SM neighbor. The
   exchange of directed Hello messages, as described above, establishes
   a neighbor relationship between remote routers. Hence Join/Prune
   messages can then be exchanged between the remote neighbors. The
   Join/Prune messages are directed to the remote neighbor and are not
   processed hop by hop as in [PIM-SM].

   Whether a Join/Prune message is destined to a remote neighbor or sent
   to the directly connected neighbor, depends on the application. For
   instance a router maybe configured to send Join/Prune messages



draft-raggarwa-pim-sm-remote-nbr-00.txt                         [Page 3]

Internet Draft   draft-raggarwa-pim-sm-remote-nbr-00.txt  September 2003


   directly to a remote neighbor if that neighbor is the next-hop of the
   BGP route used to reach the multicast source.

3.1. RPF Interface

   [PIM-SM] uses the PIM-SM enabled interface used to reach the next-hop
   neighbor as the RPF interface. However in the case of remote
   neighbors the destination address in the Join/Prune message is that
   of the remote router. The interface on which it is sent out may well
   not be the interface on which the multicast traffic from the remote
   router is received. The RPF interface for remote neighbors depends on
   the application. For a typical application that uses remote PIM-SM
   neigbors, the multicast traffic will be tunnelled between the remote
   neighbors. In that case the RPF interface will be the tunnel on which
   the multicast traffic is expected to be received.  If the tunnel is
   modelled as a logical interface in an implementation, the RPF
   interface will be that particular logical interface.


4. Operation

   The usage of the mechanisms described in this document is application
   dependent and should be described in application specific documents.
   However it is envisaged that a typical application will involve a
   network topology where the edges of the network are PIM-SM capable,
   but it is not desirable to run PIM-SM in the middle of the network.
   Thus the edge routers will act as remote PIM-SM neighbors to exchange
   multicast routing state. This can also be viewed as a mechanism to
   connect PIM-SM network clouds over a non PIM-SM network. The non PIM-
   SM network may have different mechanisms for carrying multicast
   traffic.


5. Security Considerations

   Security considerations discussed in [PIM-SM] apply. Other security
   considerations are for further study.














draft-raggarwa-pim-sm-remote-nbr-00.txt                         [Page 4]

Internet Draft   draft-raggarwa-pim-sm-remote-nbr-00.txt  September 2003


6. IANA Considerations

   The directed Hello message OptionType requires an option type value
   that has to be IANA assigned. This document currently uses the next
   available value as the directed OptionType.


7. Acknowledgments

   We would like to acknowledge the work in the MPLS WG for a solution
   to a similar problem relating to the Label Distribution Protocol
   (LDP).


8. References

   [PIM-SM] PIM WG, B. Fenner, M. Handley, H. Holbrook, I. Kouvelas,
   "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
   Specification (Revised)", draft-ietf-pim-sm-v2-new-08.txt.

   [LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas,
   "LDP Specification", RFC 3036

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



Author Information


   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: rahul@juniper.net

   Tom Pusateri
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: pusateri@juniper.net









draft-raggarwa-pim-sm-remote-nbr-00.txt                         [Page 5]

Internet Draft   draft-raggarwa-pim-sm-remote-nbr-00.txt  September 2003


IPR Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


Full Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must 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 the Internet Society or its successors or assigns.

   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



draft-raggarwa-pim-sm-remote-nbr-00.txt                         [Page 6]

Internet Draft   draft-raggarwa-pim-sm-remote-nbr-00.txt  September 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































draft-raggarwa-pim-sm-remote-nbr-00.txt                         [Page 7]