Internet Engineering Task Force Yunzhou Li INTERNET-DRAFT Nortel Networks 4 June 1999 Group Specific MSDP Peering 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. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), ftp.ietf.org (US East Coast), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract The MSDP protocol is based on the assumption that there is one or a few RPs in the PIM domain. In the presence of potential numerous RPs in the context of multicast security, Source Active messages will be flooded unnecessarily to the RPs that are not responsible for the concerning group in the messages. This memo introduces MSDP server and proposes all RPs to set up internal group specific MSDP peering with the MSDP server. Each Source Active message will be forwarded between the MSDP server and the elected RP for the concerning groups in the message. The concept of group specific peering can also apply to MSDP routers between a central multicast domain and an edge domain. Y. Li Expires 5 December 1999 [Page i] Internet Draft Group Specific MSDP Peering 4 June 1999 1. Introduction The MSDP specification ([2]) implies a router supporting MSDP is a RP. In the presence of multiple RPs in a PIM-SM domain, each representing a distinct range of groups, multiple MSDP peering pairs have to be set up internally between these RPs. As a result, Source Active (SA) messages will be unnecessarily forwarded to each RP which is not the elected RP for the group it is concerned with. On the other hand, recent research in multicast security indicates a regional security broker can be a RP of a PIM domain. Hence the number of RPs in a PIM domain potentially can grow beyond what the PIM-SM specification ([1]) assumes. As a result, the overhead in unnecessarily forwarding SA messages internally in the PIM domain is significant. This document is to minimize forwarding MSDP messages internally by introducing MSDP server. The MSDP server is a candidate RP who represents all groups (224.0.0.0/4). It has the lowest priority so that it has the least chance to be elected as a RP. MSDP servers peer with each other externally. In a PIM domain, each individual RP obtain as a client an internal group specific peering session from local MSDP server. The MSDP server will forward to the RP only those SA messages with the concerning group in the RP's group scope. When a source originates multicast data, the RP responsible for the group in concern generates a SA message and sends it to the local MSDP server. The SA message will then be flooded server-by-server over the MSDP backbone. When receiving the SA message, each MSDP server will determine the local RP for the particular group and forward the message to the particular RP. This particular RP will determine if it has (*,G) state and, if so, will trigger (S,G) join towards the source. This approach will essentially minimize the MSDP traffic internally in PIM-SM domains, simplify autoconfiguration of internal MSDP peering, and facilitate configuration of MSDP policies. The concept of group specific MSDP peering can apply to MSDP routers between a central multicast domain and an edge domain. This can be done by MSDP policy. In this manner, edge domains will be protected from receiving excessive MSDP traffic. Y. Li Expires 5 December 1999 [Page 1] Internet Draft Group Specific MSDP Peering 4 June 1999 2. Terminology MSDP Server A MSDP server is a default candidate RP (C-RP), which is configured for all groups, i.e., 224.0.0.0/4. It has the lowest priority value so that, if there is another C-RP for more specific group range(s), this other C-RP will take precedence over the MSDP server for the election of the RP for a particular group. External MSDP Peering The peering between two MSDP servers or between a MSDP server and a RP in another PIM domain (provided there is no MSDP server in this other domain). Typically this is done by configuration. Internal MSDP Peering The peering between a RP and the local MSDP server. The RP should actively request a MSDP peering from the MSDP server. The internal peering is group specific; the MSDP server only forwards those SA messages with the concerning group in the RP's group scope. RP's Group Scope A RP's group scope is the range of group addresses which the RP indicates in its C-RP Advertisement messages. The bootstrap router may modify the group range. Y. Li Expires 5 December 1999 [Page 2] Internet Draft Group Specific MSDP Peering 4 June 1999 3. MSDP-Bit in C-RP Advertisement and Bootstrap Message We define a S-bit, or MSDP-bit, in both C-RP Advertisement and Bootstrap messages to indicate the MSDP capability of the C-RP. 3.1 Extended Candidate-RP-Advertisement 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type |S| Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-Cnt | Priority | Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S-bit If it is set, the C-RP has external MSDP peerings. If it is cleared, the C-RP has no external peering. 3.2 Extended Bootstrap 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Tag | Hash Mask len | BSR-priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-BSR-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP-Count-1 | Frag RP-Cnt-1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1-Holdtime | RP1-Priority |S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP2-Holdtime | RP2-Priority |S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Y. Li Expires 5 December 1999 [Page 3] Internet Draft Group Specific MSDP Peering 4 June 1999 | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPm-Holdtime | RPm-Priority |S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP-Count-n | Frag RP-Cnt-n | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1-Holdtime | RP1-Priority |S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP2-Holdtime | RP2-Priority |S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPm-Holdtime | RPm-Priority |S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S-bit If the S-bit in a RP fragment is set, the particular C-RP has external MSDP peerings. Otherwise, the RP has no external peering. 4. RP Considerations When it learns from the Bootstrap message that it itself is an elected RP for certain range of groups, a C-RP should actively start an internal MSDP peering session with the local MSDP server. However, if the C-RP itself is a MSDP server, there is no need for the above internal peering. The C-RP learns the MSDP server by looking up the S-bit in the Bootstrap message. However, if two or more MSDP sevrers are learned, the one with the highest priority should be taken. In case of a tie, the hash function should be run between them and the one with the highest hash value should be taken. Y. Li Expires 5 December 1999 [Page 4] Internet Draft Group Specific MSDP Peering 4 June 1999 When the RP learns a new source from PIM Register message, it constructs an SA message and sends to the local MSDP server. When the RP receives a SA-request from the MSDP server, it should return to the server with a set of SA entries, in a SA-Response message, for all active sources in the PIM domain. When the RP receives a PIM Join message for a group, creates (*,G) state and wants to know all active sources for group G, it should send the MSDP server an SA-Request message for the group. 5. MSDP Server Considerations A MSDP server indicates its MSDP external capability by sending Candidate RP Advertisement message to the Bootstrap router with the S-bit set. If the policy allow, the MSDP server should automatically accept MSDP internal peering session from each elected RP. When it receives a SA message from a RP in the same PIM domain, the MSDP server should forward it to all external MSDP peers. However, no copy of the SA message should be forwarded to the other RPs in the PIM domain. When it receives a SA message from an external MSDP peer, the server forwards it to external MSDP peers in peer-RPF flooding fashion. It also determines the elected RP for the group in concern, and forwards a copy of the SA message to the RP. When a MSDP server comes up from reboot, it may send a SA-request message to certain external MSDP peer, and to all elected RPs in the same PIM domains. The MSDP server processes SA-request message in same way as in the MSDP protocol ([2]). 6. Acknowledgement The multicast development group in Nortel Networks has provided valuable comments. Special thanks to Billy Ng for his comments and suggestions. Y. Li Expires 5 December 1999 [Page 5] Internet Draft Group Specific MSDP Peering 4 June 1999 References [1] D. Estrin et al, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [2] D. Farinacci et al, Multicast Source Discovery Protocol (MSDP), Internet Draft, work in progress, June 1998. Authors' Addresses Yunzhou Li Nortel Networks BL60-304 600 Technology Park Drive Billerica, MA 01821 Phone: 1-978-288-1130 Fax: 1-978-670-8760 E-mail: yunli@NortelNetworks.COM Y. Li Expires 5 December 1999 [Page 6]