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

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

Network Working Group                                  Rahul Aggarwal
Internet Draft                                         Tom Pusateri
Expiration Date: January 2005                          Juniper Networks


           PIM-SM Extensions for Supporting Remote Neighbors


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



Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or IPR claims of which I am aware have been disclosed, and any
   of which I become aware will be disclosed, in accordance with 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 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-01.txt                         [Page 1]


Internet Draft   draft-raggarwa-pim-sm-remote-nbr-01.txt       July 2004



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-01.txt                         [Page 2]


Internet Draft   draft-raggarwa-pim-sm-remote-nbr-01.txt       July 2004



   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 SHOULD 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 may be configured to send Join/Prune messages




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


Internet Draft   draft-raggarwa-pim-sm-remote-nbr-01.txt       July 2004



   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-01.txt                         [Page 4]


Internet Draft   draft-raggarwa-pim-sm-remote-nbr-01.txt       July 2004



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). Thanks to Ravi Shekhar for his comments.



8. References


8.1. Normative 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.


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


8.2. Informative References


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



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-01.txt                         [Page 5]


Internet Draft   draft-raggarwa-pim-sm-remote-nbr-01.txt       July 2004



9. Intellectual Property


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.



10. Full Copyright Statement


   Copyright (C) The Internet Society (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.















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


Internet Draft   draft-raggarwa-pim-sm-remote-nbr-01.txt       July 2004



11. Acknowledgement


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















































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