IDMR Working Group Dave Thaler Internet Engineering Task Force Microsoft INTERNET-DRAFT Brad Cain 26 February 1999 Nortel Networks Expires August 1999 BGP Attributes for Multicast Tree Construction <draft-ietf-idmr-bgp-mcast-attr-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. This document is an Internet Draft. 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 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 a "work in progress". To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract The Multiprotocol Extensions for BGP-4 [MBGP] allow Network Layer Reachability Information to contain prefixes used for multicast forwarding. This document defines extensions to BGP-4 [BGP-4] which can be used to annotate such prefixes with information that can be used by multicast routing protocols when constructing trees. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 1. Introduction The Multiprotocol Extensions for BGP-4 [MBGP] allow Network Layer Reachability Information to contain prefixes used for multicast forwarding. These prefixes may be "come-from" unicast prefixes or multicast "go-to" prefixes (i.e. Class-D addresses). Multicast routing protocols use these prefixes to construct multicast distribution trees. We describe two BGP path attributes that may be used with prefixes used for multicast forwarding. The Forwarder Preference attribute is used by BGP speakers to elect a single forwarder on a multi-access link. The Data Flow Direction attribute describes the "directional" nature of the multicast tree for a given prefix. It may be used by multicast routing protocols which have the ability to construct multiple tree types (unidirectional and bidirectional trees), or to limit which routes can be used by multicast routing protocols which can only construct a single tree type. 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]. 2. Forwarder Preference - FWDR_PREF (Type Code XXX): In the case of a multi-access data link layer, multicast packets are sent natively on the link, and require special handling. Specifically, when packets are multicast natively on the link, each packet must only be sent onto the link by a single router, or duplicates will result. In order to reduce the number of duplicates sent on multi-access links, current multicast routing protocols elect a designated forwarder per route or use a data-driven "assert" mechanism. Some protocols (e.g. DVMRP [DVMRP]) elect a designated forwarder per route. A multicast tree branch using that route then uses the designated forwarder on the multi-access link. Other protocols [PIM-DM,PIM-SM] use data-driven mechanisms since they may use route exchange protocols which do not Expires August 1999 [Page 2]
Draft Multicast BGP Attributes February 1999 elect a designated forwarder, and run over links with multiple route exchange protocols. However, this mechanism has the disadvantage of periodically generating short bursts of duplicates. The forwarder preference attribute is for multicast routing protocols which use multi-protocol BGP for route selection. This attribute allows a designated forwarder to be elected on a multi-access link. Designated forwarder election only works, however, when full-peering exists on the multi-access link, but this is indeed the case on multicast friendly interconnects [MIX] today. Operation over multi-access links in the absense of full-peering is outside the scope of this document. 2.1. FWDR_PREF Details FWDR_PREF is an optional non-transitive attribute for the purpose of electing a single designated forwarder on a multi-access link. FWDR_PREF is used to inform other BGP speakers on the same link of the originating speaker's degree of preference for an advertised route for the purpose of electing a single designated forwarder on a multi-access link. FWDR_PREF is a four-octet non-negative integer with type code of XXX. A BGP speaker MUST include the same FWDR_PREF value on a given route when advertising it to each peer on the same multi-access link. To calculate the designated forwarder for a given route, the higher degree of preference is preferred. 3. Data Flow Direction - DIRECTION (Type Code XXX): Multicast routing protocols use a multicast-RIB to construct multicast forwarding trees. Multicast trees may be either uni-directional or bi- directional, source rooted or core rooted. Some multicast routing protocols [PIM-SM,BGMP] can build multiple tree types. The data flow direction attribute may be used to tag a route with a direction for which data is allowed to flow. This may be used for special links (e.g. satellite), or for enforcing policy. The data flow direction attribute is ONLY a route policy attribute. Its use is limited by the multicast routing protocol in use. Uni-directional trees provide aggressive loop prevention using a Reverse Path Forwarding (RPF) check mechanism whereby a specific incoming interface is chosen to accept packets from a destination. Uni- Expires August 1999 [Page 3]
Draft Multicast BGP Attributes February 1999 directional trees may provide a coarse grain policy whereby senders may be restricted to only coming from the correct RPF direction. For protocols which support multiple tree types, the data flow direction attribute may be used for tagging a route as uni-directional. This uni-directional route may be used for unidirectional shared trees (i.e. G-RIB route attribute) or for restrictions for non-member senders. High bandwidth, unidirectional transmission to low cost, receiver-only hardware is becoming an emerging network fabric, e.g. broadcast satellite links or some cable links. Such links can result in bidirectional islands connected via unidirectional links. One common solution to preserving dynamic routing is to add a layer between the network interface and the routing software to emulate bi-directional links through tunnels. However, this can result in non-optimal routing, especially since some routing protocols use forward-paths, while others use reverse-paths. 3.1. DIRECTION Details DIRECTION is an optional transitive attribute that can be used for the purpose of annotating a route with the direction(s) in which data is allowed to flow. Optionally, for Come-From routes, a register destination may be present. This destination may be used for encapsulating packets when uni-directional trees are constructed. The DIRECTION attribute contains a 1-octet "Data Flow Direction", optionally followed by three fields identifying a register destination if the data flow direction is Come-From-only. The DIRECTION attribute is type code XXX and is encoded as shown below: +-------------------------------------------------------------+ | Data Flow Direction (1 octet) | +-------------------------------------------------------------+ | Address Family Identifier (2 octets) - optional | +-------------------------------------------------------------+ | Length of Register Destination Address (1 octet) - optional | +-------------------------------------------------------------+ | Register Destination Address (variable) - optional | +-------------------------------------------------------------+ The use and the meaning of these fields are as follows: Data Flow Direction (DFD): 1 octet Expires August 1999 [Page 4]
Draft Multicast BGP Attributes February 1999 The following values are defined: 1 - Go-To. The route is valid only for traffic travelling towards the origin of the route. 2 - Come-From. The route is valid only for traffic travelling away from the origin of the route. A register destination is only useful for Come-From routes, as the purpose of the register destination is to provide a Go-To channel where none exists otherwise. 3 - Both Go-To and Come-From. The route is valid both for traffic travelling towards and away from the origin of the route. Address Family Identifier: This field carries the identity of the Network Layer protocol associated with the Network Address that follows. Presently defined values for this field are specified in RFC1700 (see the Address Family Numbers section). This field MUST NOT be present unless DFD=2. Length of Next Hop Network Address: A 1 octet field whose value expresses the length of the "Network Address of Register Destination" field as measured in octets. This field MUST NOT be present unless DFD=2. Network Address of Next Hop: A variable length field that contains the Network Address of the router to which encapsulated data packets may be sent. This field MUST NOT be present unless DFD=2. By default, if the DIRECTION attribute is not present, a route can be assumed to be "Both Go-To and Come-From". That is, the path may be assumed to provide bi-directional connectivity. However, it is the tree construction protocol which will ultimately chose the direction of data flow. 3.2. Direction Usage When a route is advertised whose next-hop is on the other side of a Expires August 1999 [Page 5]
Draft Multicast BGP Attributes February 1999 unidirectional link from the router to which the route is advertised, it should be annotated with the DIRECTION attribute. This can be used, for example, to provide a directional route over a satellite link with one set of attributes, and a separate (less preferred) route over a bidirectional tunnel. This lets traffic travelling in the direction of the physical link prefer to use that link. Traffic travelling in the opposite direction may prefer a separate path, while still being allowed to traverse the tunnel if desired (e.g. if a bidirectional path is required, and the tunnel is the only bidirectional link available). Protocols which construct bidirectional trees [CBT,BGMP] allow data to flow in both directions along tree branches maintained with "Join" and "Prune" messages. Such bidirectional branches MUST follow a route which is "Both Go-To and Come-From" (DFD=3). Several multicast routing protocols [DVMRP,PIMDM,PIMSM] can construct unidirectional source-specific trees by sending "Join" and "Prune" messages along the reverse path towards a source address, with the data flowing in the opposite direction. For this purpose, a Come-From route (DFD=2 or DFD=3) must be used. Similarly, protocols which construct unidirectional shared-trees [PIMSM] send "Join" and "Prune" messages along the reverse path towards a Rendezvous Point (RP) address, with the data flowing in the opposite direction. Again, a Come-From route (DFD=2 or DFD=3) must be used. Some protocols which normally construct bidirectional trees [BGMP] can construct a unidirectional tree if no DFD=3 route exists. Finally, shared-tree protocols [PIM-SM,CBT,BGMP] typically support non- member senders by forwarding data towards an address associated with the root (the RP/core's unicast address in PIM-SM and CBT, or the group address in BGMP). Packets from non-member senders may follow a Go-To route (DFD=1 or DFD=3) until they hit a router on the multicast distribution tree. 4. Security Considerations This extension to BGP does not change the underlying security issues. 5. References [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC Expires August 1999 [Page 6]
Draft Multicast BGP Attributes February 1999 1771, March 1995. [MBGP] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [DVMRP] Pusateri, T., "Distance vector multicast routing protocol", Internet Draft, March 1998. [MOSPF] Moy, J., "Multicast extensions to OSPF", RFC 1584, July 1993. [PIMSM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei. "Protocol independent multicast-sparse mode (PIM-SM): Protocol specification", RFC 2362, June 1998. [CBT] Ballardie, A., "Core based trees (CBT version 2) multicast routing: Protocol specification", RFC 2189, September 1997. [PIMDM] Estrin, D., Farinacci, D., Helmy, A., Jacobson, V., and L. Wei, "Protocol independent multicast (PIM), dense mode protocol specification", Internet Draft, May 1997. [MIX] LaMaster, H., Shultz, S., Meylor, J., and D. Meyer, "Multicast- Friendly Internet Exchange (MIX)", Internet Draft, draft-ietf- mboned-mix-00.txt, November 1998. 6. Author Information Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052 EMail: dthaler@microsoft.com Expires August 1999 [Page 7]
Draft Multicast BGP Attributes February 1999 Brad Cain Nortel Networks 3 Federal Street Billerica, MA 01821 EMail: bcain@baynetworks.com 7. Full Copyright Statement Copyright (C) The Internet Society (1999). 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 implmentation 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 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expires August 1999 [Page 8]
