Internet Draft B. Nickless Document: draft-nickless-safi-mcast-app-00.txt Argonne National Laboratory Expires: December 2001 June 2001 Application of Multiprotocol BGP-4 to IPv4 Multicast Routing 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 BGP-4 Multiprotocol Extensions [BGP-MP] defines the values for the Subsequent Address Family Identifier field carried in the MP_REACH_NLRI and MP_UNREACH_NLRI attributes. This document defines how compliant systems should make use of these values for the purpose of routing IP multicast traffic. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Conventions used in this document..................................2 Introduction and Terminology.......................................2 Application of Multiprotocol BGP-4 SAFI Field......................2 Security Considerations............................................3 Acknowledgements...................................................3 References.........................................................4 Author's Address...................................................4 Nickless Informational - Expires November 2001 1 Application of Multiprotocol BGP-4 April 2001 To IPv4 Multicast Routing Overview Inter-Autonomous System IPv4 multicast routing is supported by the BGPv4 Multiprotocol Extensions. The topology defined by BGPv4 for multicast routing is used for two purposes: guiding the creation and direction of source-based multicast distribution trees, and assisting MSDP to flood knowledge of active Anycast sources. 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 [RFC2119]. Introduction and Terminology IPv4 multicast [MCAST] is an internetwork service that allows IPv4 datagrams sent from a source to be delivered to more than one interested receiver. That is, a given source sends a packet the network with a destination address 224/4 CIDR [CIDR] range. The network transports this packet to all receivers (replicated where necessary) that have registered their interest in receiving these packets. Application of Multiprotocol BGP-4 SAFI Field The topology of inter-domain IPv4 multicast forwarding is determined by BGPv4 [BGPV4] policy, as is IPv4 unicast forwarding. BGP provides reachability information. Reachability information for IPv4 Unicast and IPv4 Multicast prefixes can be advertised separately. (See [MBGP] for details and the definition of Network Layer Reachability Information (NLRI) and Subsequent Address Family Information (SAFI).) The practical definition of reachability is different for IPv4 unicast (NLRI=Unicast, SAFI=1) and IPv4 multicast (NLRI=Multicast, SAFI=2). In the case of BGP multicast advertisements (NLRI=Multicast, SAFI=2), reachability is defined to mean two things: First, IPv4 datagrams can be requested (or accepted) from multicast sources within the advertised prefix range. This causes the creation of source-rooted multicast distribution trees. Such requests MAY be made to the advertised NEXT_HOP by means of the PIM Sparse Mode [PIM-SM] protocol. Any other mutually agreed upon Nickless Informational - Expires December 2001 2 Application of Multiprotocol BGP-4 April 2001 To IPv4 Multicast Routing protocol that supports source-specific traffic requests MAY be used to support this requirement. Second, the MSDP [MSDP] speaker with the NEXT_HOP address SHOULD provide MSDP Source Active messages with the Source Active RP- Address field matching the advertised prefix range. Any other mutually agreed upon protocol that supports the spreading of knowledge of active Anycast sources MAY be used to support this requirement in lieu of, or in addition to, MSDP. These two definitions of BGP NLRI=Multicast flow from the original use of the Distance Vector Multicast Routing Protocol [DVMRP] for IPv4 multicast routing. (The BGP NLRI=Multicast topology replaces the topology functions of DVMRP.) DVMRP is a ôdenseö routing protocol, which means traffic is flooded outwards from the sources to all possible receivers. In this situation, an IPv4 multicast router has to decide which incoming interface may accept IPv4 datagrams from a given source (to avoid forwarding loops), as well as which incoming interface is appropriate for learning about a given multicast source. The current ôsparseö inter-domain forwarding model (requiring source-specific requests for traffic) requires both interpretations of BGP NLRI=Multicast became necessary for interoperability with the DVMRP-based model. Note that while MSDP is not strictly necessary for Autonomous Systems that only support Source Specific Multicast [SSM], MSDP depends on the latter interpretation of BGP NLRI=Multicast to avoid MSDP SA forwarding loops. There is a real danger of causing MSDP SA forwarding ôblack holesö unless Autonomous Systems with BGP NLRI=Multicast capable peerings also exchange MSDP Source Active messages. MBGP also supports combined multicast and unicast advertisements (SAFI=3). We define these advertisements to include the multicast meanings above in addition to reachability for unicast forwarding. This is an optimization for the case where the unicast forwarding and multicast acceptance/request/source-discovery topologies are congruent. Security Considerations The extensions defined in this document allow BGP speakers to make use of reachability information about IPv4 multicast sources. As such, no new security issues are raised beyond those that already exist in BGPv4, PIM-SM, and MSDP. Acknowledgements The author would like to thank David Meyer for his useful comments and suggestions, which have been incorporated in this Draft. Nickless Informational - Expires December 2001 3 Application of Multiprotocol BGP-4 April 2001 To IPv4 Multicast Routing This work was supported by the Mathematical, Information, and Computational Sciences Division subprogram of the Office of Advanced Scientific Computing Research, U.S. Department of Energy, under Contract W-31-109-Eng-38. References [RFC2119] RFC 2119: Key Words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. [MCAST] RFC 1112: Host extensions for IP multicasting. S.E. Deering. Aug-01-1989. [CIDR] RFC 1519: Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. September 1993. [BGPV4] RFC 1771: A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li. March 1995. [MBGP] RFC 2858: Multiprotocol Extensions for BGP-4. T. Bates, Y. Rekhter, R. Chandra, D. Katz. June 2000. [PIM-SM] RFC 2117: Protocol Independent Multicast-Sparse Mode (PIM- SM): Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June 1997. [MSDP] draft-ietf-msdp-spec-09.txt: Multicast Source Discovery Protocol (MSDP). D. Meyer (Editor). March 2001. [DVMRP] RFC 1075: Distance Vector Multicast Routing Protocol. D. Waitzman, C. Partridge, S.E. Deering. November 1988. Author's Address Bill Nickless Argonne National Laboratory 9700 South Cass Avenue #221 Phone: +1 630 252 7390 Argonne, IL 60439 Email: nickless@mcs.anl.gov Nickless Informational - Expires December 2001 4