Internet Draft MSDP Working Group Masahiro Jibiki Internet Draft Atsushi Iwata Expires in six months NEC Corporation November 2000 MSDP Specific Forwarding Extension for Inter-Domain Multicast Forwarding <draft-jibiki-iwata-msdp-idmf-01.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 draft proposes a general inter-domain multicast forwarding (IDMF) mechanism for the PIM-SM multicast routing protocol and its application to the MSDP specific forwarding extension (MSDP-FE). Although there have been various inter-domain multicast routing and forwarding protocols, they are still limited in their capacity to handle policy routing, QoS routing, accounting and security, which network administrators are willing to use in their network. In order to overcome this limitation, we propose a novel approach to create an inter-domain multicast forwarding tree (or routing table) among multiple PIM-SM domains with logical multicast paths over which multicast packets are forwarded or flooded. The logical multicast paths are created by either the IP-in-IP tunneling method, the IP masquerade-like method, or the MPLS label switched path (LSP) method, which can easily reuse policy routing and QoS routing for unicast Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 1] Internet Draft November 2000 routing. These logical multicast paths are established among IDMF- capable nodes, which are located within each PIM-SM domain, either manually or by a dynamic IDMF tree construction protocol. This general framework for IDMF can be used as an MSDP based forwarding mechanism. Furthermore, the IDMF-capable nodes (i.e., MSDP-FE-capable nodes) can also function as a proxy sender of multicast packets. This can prevent a multicast receiver from changing an RP-tree into a global SP-tree, and also can help to reduce, on the surface, the number of multicast sources for a particular multicast group. This property can be effectively used for accounting, security, and scalability enhancement required for inter-domain communication. 1. Introduction Various inter-domain multicast routing protocols, such as the Multicast Source Discovery Protocol (MSDP) [MSDP] and the Border Gateway Multicast Protocol (BGMP) [BGMP], have been proposed and have been standardized in IETF. In particular, MSDP is expected to be a short term promising solution for inter-domain multicast routing due to its protocol simplicity and ease of deployment. MSDP is a mechanism to connect multiple PIM-Sparse Mode (PIM-SM) [RFC2362] domains to create a single global PIM-SM tree with distributed Rendezvous Points (RP) in each PIM-SM domain. The current MSDP draft [MSDP] discusses mainly the protocol mechanism for multicast source address advertisement among PIM-SM RPs, and does not well address the issue of multicast packet forwarding. Multicast packet forwarding is very important for handling policy routing, QoS routing, accounting and security, which network administrators are willing to use in their network. Therefore, this draft proposes a general framework for the inter-domain multicast forwarding (IDMF) scheme and MSDP specific forwarding extension based on the IDMF. The key elements of the proposed general IDMF scheme are: (1) Logical multicast path tree built among PIM-SM domains: Multicast traffic across PIM-SM domains can be aggregated in unicast-format packets and transferred along the logical multicast path tree (IDMF tree) among domains. This mechanism allows us to use policies and QoS control of the inter-domain traffic in the same way as in current unicast IP networks. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 2] Internet Draft November 2000 (2) Automatic/dynamic maintenance of IDMF tree: The characteristics of the IDMF tree (i.e., disconnection, delay, packet loss, failure and so on) can be periodically monitored. If the path cannot satisfy, for example, the QoS requirements of inter-domain traffic, only IDMF-capable nodes automatically reroute the path for establishing a new IDMF tree, so as to reduce the influence on the active inter-domain multicast traffic. (3) Proxy sender of inter-domain multicast packets: IDMF-capable nodes can also be equipped with the accounting and security mechanism required for inter-domain communication. As one means of enhancing security, IDMF-capable nodes can also behave as a proxy sender of multicast packets. There are two cases for this proxy sender; (1) the last-hop IDMF-capable node toward multicast receivers and (2) the first-hop IDMF-capable node from multicast senders. In the first case, this capability can prevent multicast receivers from changing the multicast path from shared RP-tree to the global source-based shortest-path tree (SP-tree). Since it is difficult to use the global SP-tree to ensure the above accounting and security for inter-domain traffic, it should be restricted as much as possible. In the second case, this capability can help to reduce the number of multicast sources (S) logically for a particular multicast group, although it may be difficult to reduce the number of multicast groups (G). Thus the property of (2) can be regarded as one of scalability enhancement. This draft focuses on MSDP specific forwarding extension (MSDP-FE) using a general IDMF scheme, and also mentions a proxy node implementation as an example, although the proposed scheme can be basically implemented on other platforms, such as PIM-SM RPs and area border routers. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 3] Internet Draft November 2000 2. Existing Inter-Domain Forwarding Problems The PIM-SM protocol uses the PIM-JOIN message to build a multicast traffic delivery tree, which can be an RP-tree shared from RP to multicast receivers or an SP-tree shared from multicast sources to receivers. This is because the PIM-JOIN message usually is sent along the best-effort unicast path from receivers to RP or sources, and intermediate routers along the path create a forwarding entry for the (*, G) or (S, G), so that they will be able to forward multicast packets downstream toward the multicast receivers. This means that this multicast path is built based on best-effort unicast path, thus no router can choose a multicast path which is different from the best-effort unicast path. Therefore, if the same tree construction mechanism is applied to the inter-domain multicast forwarding, we have to support a global SP- tree across several PIM-SM domains directly using PIM-JOIN messages. Although the current MSDP allows this global SP-tree mode, this mode has the following problems: (1) QoS routing and Traffic engineering for multicast packets: Since multicast traffic is passed along with the reverse path to which a join message was sent (usually best-effort unicast path to the RP), it is difficult to distinguish and manage a unicast path and a multicast path. That is, it is difficult for a network administrator to perform QoS routing and traffic engineering for multicast packets with the same approach as is done in unicast IP networks. (2) Policy routing for multicast packets: For the same reasons as given in (1), even if the network administrator wants to specify the policy for multicast routing and to control the multicast path, no suitable framework has yet been proposed for this. (3) Accounting and security enhancement for multicast packets: Currently, there is no mechanism for choosing and controlling users who are allowed to join the inter-domain multicast tree, and for switching over from the shared RP-tree to the SP-tree. There is also no mechanism for managing and controlling the multicast sender to allow multicast data to be sent to a multicast group. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 4] Internet Draft November 2000 That is, a multicast router must accept join messages from any receiver, and each node on the SP-tree must forward the multicast data that any sender transmits, regardless of policy considerations. Therefore, it is difficult to ensure the accounting and security in inter-domain multicasting. (4) Heterogeneous router capability support: When there is a network that does not support multicasting along the SP-tree, the nodes located downstream cannot always participate in the SP-tree. Although this problem can usually be solved by configuring a static tunneling across such a network, no mechanism to create such a tunnel flexibly and dynamically has been proposed yet. Although it may be possible to solve this problem by changing a topology and policy in a private domain from a single administrative perspective, it is very difficult to solve it between domains unless there is standard architecture for accommodating these capabilities. In order to solve the above problems, we propose a general inter- domain multicast forwarding (IDMF) scheme. The overview of the proposed scheme and its application to MSDP specific forwarding extension (MSDP-FE) are discussed in the following sections. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 5] Internet Draft November 2000 3. General Framework for IDMF This section addresses an overview of the inter-domain multicast forwarding (IDMF) scheme. IDMF is a novel approach to create a logical inter-domain multicast forwarding tree (IDMF tree) among multiple PIM-SM domains with logical multicast paths, over which multicast packets are forwarded or flooded. The logical multicast paths (IDMF paths) are created by either the IP-in-IP tunneling method [RFC2003], the IP masquerade-like method, or the MPLS label switched path (LSP) method [MPLS-ARCH][MPLS-LABEL], which can be used for aggregating multicast flows, on the surface, (i.e., reducing the number of multicast flows) toward the same PIM-SM domain along the same IDMF paths. Thus unicast packets and multicast packets destined for the same network can follow the same route as the unicast route, which is convenient for performing QoS routing, traffic engineering, and policy routing in the same way as in unicast IP networks. These IDMF paths are established among IDMF-capable nodes or proxies, which are located within each PIM-SM domain, either manually or by a dynamic IDMF tree construction protocol. One advantage of this is the effect on aggregation of multicast traffic along the IDMF paths between IDMF-capable nodes, this can be simplified to account for multicast packets and to filter those packets for security purposes. Another advantage is that the IDMF-capable nodes can behave as a proxy sender of multicast packets, which can prevent a multicast receiver from changing the shared RP-tree into the global SP-tree. This is effectively used so that the multicast receiver cannot know the real multicast source addresses, while receiving the traffic sent from the real multicast source nodes. This property also helps to achieve the accounting and security enhancement required for inter- domain communication. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 6] Internet Draft November 2000 4. Extension of MSDP Based on IDMF Scheme 4.1 Overview This subsection addresses an overview of MSDP specific forwarding extension (MSDP-FE) using a general IDMF scheme. MSDP-FE-capable nodes (i.e., RPs) create logical multicast paths (MSDP-FE paths) by one of three methods specified in the IDMF scheme. Thus, inter- domain multicast forwarding tree (MSDP-FE tree) among multiple PIM-SM domains is built along MSDP peerings by MSDP-FE paths. Multicast packets are forwarded or flooded over logical multicast paths according to the MSDP Peer-RPF Forwarding rules [MSDP], which is convenient to perform QoS routing, traffic engineering, and policy routing in the same way as in unicast IP networks. These MSDP-FE paths are established logically among MSDP-speaking routers which are located as RPs within each PIM-SM domain. That is, since RPs with an MSDP peering also have an MSDP-FE path for data transmission, by an MSDP-FE tree construction message, a data forwarding tree (MSDP-FE tree) is built along the reverse path against peer-RPF path (i.e., shortest path for SA message forwarding). This can be simplified to account for multicast packets and to filter those packets for security purposes. If accidents occur in the MSDP-FE tree and the tree is disconnected, the topology can revive by modification only at the node where peer-RPF is changed. Therefore, RPs check the peer- RPF of SA messages in order to dynamically modify the MSDP-FE tree topology. The MSDP-speaking routers can also behave as proxy senders of multicast packets and advertise aggregated SA messages, which prevents a multicast receiver from changing the shared RP-tree into the global SP-tree. This is effectively used so that the multicast receiver cannot know the real multicast source addresses, while receiving the traffic sent from the real multicast source nodes. This property also helps to enhance the accounting and security required for inter-domain communication. The following subsection explains the overview of the following items: (1) MSDP-FE tree construction (2) Packet delivery between PIM-SM domains using MSDP-FE (3) Restrictions on global SP-tree construction Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 7] Internet Draft November 2000 4.2 MSDP-FE Tree Construction The RP on MSDP-speaking routers establishes an MSDP peering to RP in another PIM-SM domain for multicast source address advertisement. Establishment of MSDP peerings can be performed in the same manner as a BGP [RFC1771] peering based on the policy of the network administrator. This MSDP peering can be used to establish an MSDP-FE path which is a logical multicast path for data forwarding between these peers. A global inter-domain multicast tree (MSDP-FE tree), in other words a data-forwarding tree, is built up on the MSDP peering tree, and has the same topology as that of the peer-RPF path to which SA messages are forwarded. The inter-domain multicast forwarding table (MSDP-FE forwarding table) is configured at each hop of the MSDP-FE-capable nodes. Furthermore, MSDP-FE-capable nodes (i.e., RP on MSDP-speaking routers) can also provide an MSDP-FE capability as proxy nodes. If MSDP-speaking routers behave as proxies and aggregate multicast flows, the topologies of MSDP-FE trees can be either in the form of a flat multicast tree or a hierarchical multicast tree, depending on the total size of the network. Receiving the PIM-JOIN messages, the RP updates the PIM-SM forwarding entry to support (*, G) and checks the multicast source addresses, which are associated with multicast group G in the MSDP database. Then, it sends an MSDP-FE-JOIN message for each multicast source to the upstream peer, according to the 'MSDP Peer-RPF Forwarding rules', along the reverse path in which the SA message was sent. The intermediate nodes forward the MSDP-FE-JOIN message to the upstream MSDP peer (i.e., peer-RPF), creating an MSDP-FE forwarding entry (*, G) pair, if such a forwarding entry does not yet exist. Therefore, each RP needs to hold the peer-RPF of the SA message. When an MSDP-FE-JOIN message reaches the originating RP of the SA message, the MSDP-FE-TYPE message which specifies the method of establishing a logical multicast path is returned from this originating RP up to the receiving RP along the reverse path in which the MSDP-FE-JOIN message was sent. The intermediate RPs which received the MSDP-FE-TYPE message add a unicast-type within the message to the MSDP-FE forwarding entry, and return an MSDP-FE-TYPE- ACK message to the peer-RPF which is the transmitting origin of this type message. When the ack message received in the peer-RPF shows rejection of the unicast-type specified in the last type message, this peer-RPF sends another type message. The MSDP-FE-TYPE-ACK message specifies also the port number in which downstream RP receives the unicast-type data. The intermediate RPs generates a new MSDP-FE-TYPE message with new unicast-type and transmits it toward a downstream peer, after replying to the ack message. The entry to Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 8] Internet Draft November 2000 which no MSDP-FE-TYPE message has been sent for a certain fixed time after transmitting MSDP-FE-JOIN message is deleted. Each RP on the established path sends an MSDP-FE-JOIN message to the peer-RPF in the same manner as PIM-SM periodically, in order to maintain the upstream MSDP-FE state, after an MSDP-FE-TYPE message reaches the receiving RP of the multicast packet. In order to prevent unnecessary MSDP-FE forwarding entries from remaining, entries to which a join message has not been sent for a certain fixed time are deleted in the same manner as type messages. There are three methods for creating the MSDP-FE paths: the IP-in-IP tunneling method, the IP masquerade-like method, and the MPLS label switched path (LSP) method. The IP-in-IP tunneling method [RFC2003], or encapsulation by IP, is a simple mechanism. However, if the packet length of a multicast packet is the same as the Maximum Transmission Unit (MTU) along the path, the packets have to be fragmented, and this is likely to cause a performance bottleneck in this processing. Considering that most of the current multicast applications are used for real-time applications, their packet lengths are very likely short, and the possibility of fragmentation may be less than that in normal unicast traffic situations. With the IP masquerade-like method, MSDP-FE-capable nodes need to convert original multicast IP packets into new unicast IP packets where the original IP multicast packet header information, such as source/destination IP address and source/destination port number, is aggregated into a source port number of the new unicast IP packet. The conversion rule is exchanged between MSDP peers in advance. Since this method does not change the packet length, it does not have a fragmentation problem. Instead the conversion takes more processing power to support the wire-speed forwarding in a short latency. The MPLS label switched path (LSP) method [MPLS-ARCH][MPLS-LABEL] is a scheme for tunneling lower layers than those in IP-in-IP tunneling. Although IP-in-IP tunneling uses 3rd layer forwarding capability in IP routing, MPLS LSP uses an MPLS layer forwarding (i.e., layer 2.5) beneath the 3rd layer routing. From the IP multicast packet point of view, MPLS LSP looks like a leased line service. The main benefit of using the MPLS LSP is to control the unicast path for improving the network utilization (i.e., traffic engineering), such as load balancing, multi-path routing and so on. However, since the label (shim header) has to be put in front of the IP multicast packet when forwarding, this method also has packet fragmentation problems. Since each approach has a trade-off for performance, the network Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 9] Internet Draft November 2000 administrator has to choose one of the methods, depending on the network configuration and traffic demand. 4.3 Packet Delivery between PIM-SM Domains in MSDP-FE The MSDP-FE capability is collocated within the RP of its own domain, and can detect the multicast packets sent from multicast senders within the domain. When receiving the multicast packets, the RP checks the MSDP-FE forwarding entry. If such a forwarding entry exists, the RP forwards or floods the received multicast packets along the associated outgoing MSDP-FE paths, in which the multicast packets are converted into unicast-type packets. When the RP receives a unicast-type packet from an MSDP peer, it processes the following: (1) The RP converts the received unicast-type packets into original multicast packets, and checks the PIM-SM forwarding entry associated with the multicast destination group. If an outgoing entry exists toward its own PIM-SM domain, the multicast packets are forwarded downstream toward the multicast receivers within the same domain through the shared RP-tree. This multicast packet format can select either an original multicast packet or a converted multicast packet in which the RP functions as a proxy of multicast senders. The latter case is discussed in the following subsection. (2) After checking the MSDP-FE forwarding entry, if the outgoing entry exists toward the next-hop (downstream) MSDP peers, the original multicast packets are encoded again with the unicast- type packets and are flooded along the associated downstream MSDP peers, except for the MSDP peer from which the unicast- type packet is received (i.e., the peer-RPF of the SA message). Since the MSDP-FE tree is built with logical multicast paths (MSDP-FE paths), it is possible to transmit multicast traffic across a domain boundary and to use the unicast route specified by BGP policy for multicast traffic. That is, in inter-domain multicast communication, the network administrator can re-use the current policy mechanism provided by BGP and QoS routing and signaling in the same manner as the unicast IP networks. Since multicast communication is emulated along the logical multicast communication, it is also possible to prevent eavesdropping between domains by unauthorized users. Moreover, since a multicast communication beyond the domain boundary can be controlled only by an RP, an accounting model can be easily developed. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 10] Internet Draft November 2000 4.4 Restriction of Global SP-Tree Construction As explained above, the MSDP-FE-capable node, the RP, forwards multicast packets downstream toward the shared RP-tree within the same domain, if an outgoing entry exists toward its own PIM-SM domain. In PIM-SM, the multicast receivers have the option of switching the receiving multicast tree from the shared RP-tree to the global SP-tree, once the amount of receiving packets goes beyond a predetermined threshold, so as to improve such performances as end- to-end delay. If the multicast tree switches from the shared RP-tree to the global SP-tree, multicast traffic will be delivered directly from the sender in another domain, and will not be passed through the RP within the same domain. As discussed in Sec.2, since the global SP-tree has several problems, the following three approaches are used for solving them. As a straightforward approach against a change in the multicast tree, there is a method of configuring the threshold to a special (or highest) value which prevents each PIM-SM router in a domain from switching the tree, even if the amount of receiving packets increases. Since the threshold value is defined as dependence on operation/implementation in RFC, this approach, along with RP fixing, is frequently used as a means of providing a stable network. Another approach is a scheme where the RP behaves as a proxy of multicast senders. The RP converts the original packets into a new multicast packet, which uses IP masquerade-like conversion for supporting this behavior. In this case, the RP can change the source address of the packet into its own address. Even if each multicast receiver switches from the shared RP-tree to the global SP-tree, the global SP-tree is established between the RP and the multicast receiver, which means it is only an intra-domain PIM-SM tree. Thus, the SP-tree is not built across a boundary of the domain. By using both approaches, inter-domain multicast communication can be performed without adding any modifications to the current PIM-SM. A third approach is to have all PIM-SM routers refuse any PIM-JOIN messages from receivers outside their own domain. However, in this case, PIM-SM needs to be modified so that any router which refuses a PIM-JOIN message returns an error message to the designated router (DR) of the receiver. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 11] Internet Draft November 2000 5. Modifications to Current MSDP Specifications In order to perform inter-domain multicast communication using MSDP, the current MSDP specifications need to be extended to MSDP-FE with respect to the following. 5.1 Peer-RPF Cache An MSDP-FE-JOIN message is sent to the peer-RPF, in the direction of the originating RP of the multicast packet, along the reverse path of the SA message. Therefore, each MSDP router not only caches the SA message, but needs to cache the peer-RPF for the SA message at the same time. When the peer-RPF is changed, the RP which detected this modification sends a new MSDP-FE-JOIN message generated from the MSDP-FE forwarding entry to the new peer-RPF, and tries to reconstruct the MSDP-FE tree. 5.2 New TLVs The following three TLVs need to be added. (1) MSDP-FE-Join TLV for receiver RP to send join message to the originating RP of the multicast packet (2) MSDP-FE-Type TLV for the originating RP to return methods for creating the logical multicast path to receiver RP (3) MSDP-FE-Type-Ack TLV for each RP to acknowledge a received MSDP-FE-TYPE message 5.3 New Timers In order to prevent unnecessary MSDP-FE forwarding entry from remaining, RPs send MSDP-FE-JOIN messages periodically in the same manner as PIM-SM. That is, entries to which a join message has not been sent for a certain fixed time are deleted. (1) MSDP-FE-Join-Timer for RPs periodically sending MSDP-FE-JOIN messages to peer-RPFs (2) MSDP-FE-Type-Timer for RPs waiting for an MSDP-FE-TYPE message after transmitting an MSDP-FE-JOIN message Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 12] Internet Draft November 2000 (3) MSDP-FE-Entry-Timer for RPs holding an MSDP-FE forwarding entry until the next MSDP-FE-JOIN message arrival 5.4 Data Packet Forwarding Each RP transmits a unicast-type packet to a peer along logical multicast paths, according to the MSDP-FE forwarding entry. There are three types of logical multicast paths, and the upstream RP notifies the downstream which type was adopted using an MSDP-FE-TYPE message. 5.5 Proxy Mode This extension is optional. However, by behaving as a proxy of a multicast sender, an MSDP-speaking router can aggregate a multicast flow and can prevent a shared RP-tree from switching to a global SP- tree. In case an RP behaves as a proxy, an SA message is advertised not according to the appearance of a new sender but according to the appearance of a new group. When sending data to a peer on a logical multicast path, the RP modifies the source port number of the unicast-type packet for every actual sender (i.e., IP masquerade-like conversion) and sends it. Correspondence with the port number selected in transmission and the actual sender is managed by each RP. When the receiver replies to the sender, this packet is sent to the source port of the RP. The RP transmits the packet to the actual sender according to the port number which received the reply from the multicast receiver. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 13] Internet Draft November 2000 6. Detailed Procedures for the Proposed MSDP-FE Scheme Figure.1 shows an example in which seven PIM domains A..G establish the MSDP peering and build the MSDP network. Domain A advertises the SA message SA-A. The arrows in Fig.1 indicates the direction of peer- RPF to SA-A. Although domain C may receive SA-A from domains B and G, since peer-RPF of C is B, C discards SA-A from G and advertises SA-A from B to D. +---+ <== +---+ <== +---+ <== +---+ | A +---------| B |---------| C |---------| D | +-+-+ +-+-+ +-+-+ +-+-+ | | | /\ | | | || | | | | | | +-+-+ <== +-+-+ <== +-+-+ | E +---------+ F +---------+ G | +---+ +---+ +---+ Figure 1: Example of an inter-domain multicast communication In Fig.1, when the receiver to the multicast group (224.60.70.80:3400) advertised by SA-A appears in domain C, the RP in domain C sends the MSDP-FE-JOIN message to the RP in domain B which is peer-RPF of SA-A, toward domain A. The enlarged view of the above PIM domains A..C is shown in the next page. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 14] Internet Draft November 2000 PIM-SM Domain A PIM-SM Domain B PIM-SM Domain C 133.25.0.0/16 192.50.0.0/16 210.14.0.0/16 +----------------+ +----------------+ +----------------+ | | | | | | | RP-A | | RP-B | | RP-C | | 133.25.24.10 | *2 | 192.50.22.8 | *1 | 210.14.40.7 | | #A2 | <== | #B1 #B2 | <== | #C1 #C2 | | O-----------------------O-----------------------O-------------- | #A1| | ==> | #B3| | ==> | #C3| | | : | *3 | : | *4 | : | | (Register Msg) | | (Multicast) | | (Multicast) | | : | ==> | : | ==> | : | | | *5 | *6 | | *8 | *7 | | *8 | | | <== | | | ==> | | | ==> | | O-------O | | +-------O | | +-------O | | DR Sender | | Receiver | | Receiver | | 133.25.15.3 | | 192.50.48.15 | | 210.14.72.16 | | | | | | | +----------------+ +----------------+ +----------------+ Figure 2: Details of the inter-domain multicast communication #XY in Fig.2 indicates the Yth interface with which RP-X in domain X is equipped. Moreover, the arrows *1, *2 indicate MSDP-FE-JOIN messages, and the arrows *3, *4 indicate MSDP-FE-TYPE messages. The arrows *5..*8 indicate multicast packets, but the headers of these packets are different. Sections 6.1..6.5 explain the forwarding/translation tables maintained at each RP, and the header structure of each packet *5..*8. Each RP maintains the inter-domain multicast forwarding table associated with: (1) Multicast-sender-to-RP forwarding (2) RP-to-RP forwarding (3) RP-to-multicast-receiver forwarding These tables are discussed in the following sections. In terms of (2), MSDP peerings are established among other RPs in other domains across the domain boundary. RPs use TCP connection between MSDP peers for updating the MSDP-FE forwarding/translation tables. In terms of (1) and (3), no special control connections are necessary between RPs and multicast senders/receivers. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 15] Internet Draft November 2000 6.1 Forwarding Table Maintained at the RP If a receiver for a multicast group (224.60.70.80:3400) specified by the SA message appears, RP-C will create the following entries and will send an MSDP-FE-JOIN message to RP-B. Source Group +------------------+-------------------+ | 133.25.15.3:2690 | 224.60.70.80:3400 | +------------------+-------------------+ Input Interface Type +------------------+-------------------+ | #C1 | Undecided | +------------------+-------------------+ Output Interface Type +------------------+-------------------+ | #C3 | Direct | +------------------+-------------------+ Figure 3: Newly added forwarding entry at RP-C The method with which RP-B changes a multicast packet into unicast is stored in the Type field for the input interface. Since this is information which will be notified by the MSDP-FE-TYPE message from RP-B, it is as yet undetermined. Moreover, in this example, the interface for delivering a multicast packet into the domain is stored in the Output Interface. Since a multicast packet is directly output to interface #C3, 'Direct' is stored in the Type field. If RP-B receives an MSDP-FE-JOIN message from RP-C, it will create the following entries and will transmit an MSDP-FE-JOIN message to RP-A. In this case, the Type field for the output interface shows IP masquerade-like conversion that uses the converting rule No.120 in a translation table. This information is notified to RP-C by the MSDP- FE-TYPE message afterwards. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 16] Internet Draft November 2000 Source Group +------------------+-------------------+ | 133.25.15.3:2690 | 224.60.70.80:3400 | +------------------+-------------------+ Input Interface Type +------------------+-------------------+ | #B1 | Undecided | +------------------+-------------------+ Output Interface Type +------------------+-------------------+ | #B2 | Masquerade:120 | +------------------+-------------------+ Figure 4: Newly added forwarding entry at RP-B Similarly, the originating RP of the multicast packet, RP-A, creates the following entries when it receives an MSDP-FE-JOIN message. Source Group +------------------+-------------------+ | 133.25.15.3:2690 | 224.60.70.80:3400 | +------------------+-------------------+ Input Interface Type +------------------+-------------------+ | #A1 | Direct | +------------------+-------------------+ Output Interface Type +------------------+-------------------+ | #A2 | IP-in-IP | +------------------+-------------------+ Figure 5: Newly added forwarding entry at RP-A The interface receiving a multicast packet from the sender in a domain is stored in this Input Interface field. Since #A1 receives a multicast packet directly, 'Direct' is stored in the Type field. Then, RP-A sends an MSDP-FE-TYPE message to RP-B in the #A2 direction. A type message is used to notify the method for creating the logical multicast path, and 'IP-in-IP' is specified in this case. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 17] Internet Draft November 2000 If RP-B receives the type message from RP-A, it will transmit a new type message in which IP masquerade-like conversion is specified with its converting rule to RP-C, after storing 'IP-in-IP' in Type field for the input interface. RP-C stores 'Masquerade:120' in Type field for the input interface when it receives the type message from RP-B. The port number in which each RP receives the unicast-type data is specified in the MSDP-FE-TYPE-ACK message. 6.2 Actions between Multicast Sender and RP Consider the case where the multicast sender (133.25.15.3) sends a multicast packet with the header information shown in Fig.6. Actually until the (S, G) state has been created in all the routers between RP and designated router (DR), this multicast packet is forwarded as packets encapsulated within unicast PIM-Register packets. After the (S, G) state has been created between them, the following multicast packet is forwarded to RP-A from the designated router in PIM-SM domain A. Destination Source +--------------+--------------+ IP | 224.60.70.80 | 133.25.15.3 | (IP address) +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 3400 | 2690 | (port number) +--------------+--------------+ Figure 6: Header information of the original multicast packet *5 in Fig.2 Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 18] Internet Draft November 2000 6.3 Actions between RP and Downstream RPs As explained above, the IP-in-IP tunneling method, the IP masquerade- like method, or the MPLS LSP method are used for creating logical multicast paths (MSDP-FE paths). Before actual transmission of unicast-type data, by an MSDP-FE-TYPE message, RP negotiates with each peer as to which method is to be used for packet encoding. The IP-in-IP tunneling method is used as a default method, if the MSDP peers fail to successfully negotiate the encoding method. 6.3.1 IP-in-IP Tunneling Method When IP-in-IP tunneling is used as an MSDP-FE path, an RP appends a new unicast IP header, which is destined to the MSDP peer, in front of an original multicast packet. The RP forwards or floods this unicast packet downstream to associated MSDP peers in the MSDP-FE forwarding and translation tables. Here, we explain an example based on the network topology shown in Fig.2. RP-A creates the following IP-in-IP header, which is appended in front of the IP multicast packet header shown in Fig.6. The entire IP-in-IP tunneling header is shown in Fig.7. RP-A forwards or floods this packet to RP-B. When the RP-B receives this packet, it strips off the IP header to get the original multicast packet. Destination Address: IP address of a downstream RP Source Address: IP address of RP itself transmitting this encapsulation packet Protocol Number: 4 (protocol number of IP) Destination Source +--------------+--------------+ IP | 192.50.22.8 | 133.25.24.10 | (IP address) +--------------+--------------+ | 4 | (protocol number) +--------------+--------------+ IP | 224.60.70.80 | 133.25.15.3 | (IP address) +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 3400 | 2690 | (port number) +--------------+--------------+ Figure 7: IP-in-IP header information used by packet *6 in Fig.2 Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 19] Internet Draft November 2000 As a UNIX implementation example, each RP opens a RAW socket and waits for arrival of a packet in IPPROTO_IP. Once the RP receives a packet, it compares the source address in the IP header of the packet with its own forwarding entries shown in Sec.6.1. If the source address is included in the entries and 'IP-in-IP' is specified in the Type field for the input interface, the RP strips off the IP header to get the original multicast packet. Then, RP-B compares the destination address (i.e., the multicast group) of the original multicast packet with the Group field in the MSDP-FE forwarding entry. If both are equal, RP-B creates another IP- in-IP tunneling header for this packet as shown in Fig.8 and outputs this packet to the output interface toward the downstream RPs. In this example, RP-B forwards the packet again to RP-C. Note that the IP and UDP headers of the original multicast packet are not changed along the RP-to-RP path. Destination Address: IP address to a downstream RP Source Address: IP address of RP itself, which floods down the IP-in-IP tunneling packet Protocol Number: 4 (protocol number of IP) Destination Source +--------------+--------------+ IP | 210.14.40.7 | 192.50.22.8 | +--------------+--------------+ | 4 | (protocol number) +--------------+--------------+ IP | 224.60.70.80 | 133.25.15.3 | (IP address) +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 3400 | 2690 | (port number) +--------------+--------------+ Figure 8: IP-in-IP header information used by packet *7 in Fig.2 Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 20] Internet Draft November 2000 6.3.2 IP Masquerade-Like Method When the IP masquerade-like method is used as an MSDP-FE path, RP converts an original multicast IP header into a new unicast IP header, such as source/destination IP address and source/destination port number. The key to the original header information is shown by a source port number (unique ID within the RP) of the new unicast IP packet. The RP exchanges in advance such conversion rule by MSDP-FE- TYPE message, which includes the relationship between the original multicast header information and the assigned unique ID (i.e., a new source port number), as follows. << MSDP-FE-TYPE message contents >> (1) Destination address (multicast group) (2) Destination port number (3) Source address (multicast sender address) (4) Source port number (5) Unique ID for identifying above header information (this is used as the source port number in IP masquerade header) The downstream RP receives the MSDP-FE-TYPE message from an upstream MSDP peer, and checks the MSDP-FE translation table for associated downstream MSDP peers. If such peers exist, the RP assigns another new ID for flooding the packets to further downstream RPs. After exchanging the above information, the RP converts the header of the original multicast packet as follows and transmits to the downstream RPs. Destination Address: IP address of the downstream RP Destination Port Number: Port number in which the downstream RP receives the unicast-type packet Source Address: IP address of RP itself forwarding the multicast packets Source Port Number: Unique ID for identifying the original multicast packet header. This information is exchanged in advance by MSDP-FE-TYPE message between MSDP peers. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 21] Internet Draft November 2000 When the downstream RP receives the IP masquerade packets, it restores the packets into the original multicast packet by using the source port number which is associated with the original multicast headers. Destination Source +--------------+--------------+ IP | 224.60.70.80 | 133.25.15.3 | (IP address) +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 3400 | 2690 | (port number) +--------------+--------------+ Figure 9: Header information of the original multicast packet *5 in Fig.2 For example, given that the multicast sender (133.25.15.3) sends the multicast packet with the header information shown in Fig.9, RP-A sends the MSDP-FE-TYPE message including the following information to RP-B: Destination Address: 224.60.70.80 Destination Port Number: 3400 Source Address: 133.25.15.3 Source Port Number: 2690 Unique ID: 4210 RP-B returns the MSDP-FE-TYPE-ACK message back to the RP-A, indicating 5370 as the receiving port number. After such a negotiation is done, RP-A performs a conversion of the original multicast header into the value shown in Fig.10, and transmits the IP masquerade-like packet to RP-B. Based on the source port number, RP-B can recognize that the multicast packet shown in Fig.9 is encoded with the IP masquerade-like method. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 22] Internet Draft November 2000 Destination Source +--------------+--------------+ IP | 192.50.22.8 | 133.25.24.10 | (IP address) +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 5370 | 4210 | (port number) +--------------+--------------+ Figure 10: Header information of the IP masquerade-like packet *6 in Fig.2 When RP-B receives the MSDP-FE-TYPE message from RP-A, it checks the MSDP-FE forwarding entry to see the next downstream MSDP peers, RP-C in this example. RP-B assigns a new unique ID (for example, 6640) for the logical multicast path between RP-B and RP-C, and sends a newly generated MSDP-FE-TYPE message to RP-C. RP-C sends back an MSDP-FE- TYPE-ACK message, indicating 4990 as a receiving port number. Then, RP-B transmits the IP masquerade-like packet shown in Fig.11 to RP-C. In the same manner as RP-B, after acquiring 6640 from the source port number of the received packets, RP-C restores the original multicast packet. Destination Source +--------------+--------------+ IP | 210.14.40.7 | 192.50.22.8 | +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 4990 | 6640 | (port number) +--------------+--------------+ Figure 11: Header information of the IP masquerade-like packet *7 in Fig.2 6.3.3 MPLS Label Switched Path (LSP) Method When the MPLS LSP method is used as an MSDP-FE path, RP appends an MPLS shim header[MPLS-LABEL], which is destined to the MSDP peer, in front of an original multicast packet. The RP forwards or floods this unicast packet downstream to associated peer RPs, based on the multicast forwarding table. The MPLS shim header is a 4 byte header, which consists of MPLS label field (20 bits), Experimental bit field, (3 bits), Bottom of stack field (1 bit), and Time to Live field (8 bits). Path selection with label switching is controlled by this MPLS Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 23] Internet Draft November 2000 label field. Except for the prepended header format, the same behavior as IP-in-IP tunneling is applied for this mode. 6.4 Actions between RP and Multicast Receivers As explained in Sec.4.4, in order to prevent multicast receivers from switching from the shared RP-tree to the global SP-tree, RP behaves as a proxy of multicast senders. This also can be done in the same approach as in the IP masquerade-like method described above. Each RP assigns a new unique ID for the original multicast packet header before forwarding it down into its own PIM-SM domain. The new unique ID is assigned to the source port number of forwarding packets, as follows. Destination Address: Multicast group Destination Port Number: Destination port number Source Address: IP Address of RP forwarding the multicast packets Source Port Number: Unique ID for identifying the above header address. Figure 12 shows a modification of the sender address and port number shown in Fig.2. Let us consider the case where RP-B forwards the multicast packet by changing the source address and the source port number of the original multicast packets. Additionally, let us consider the case where the multicast receiver also replies back with unicast to the RP, which can be forwarded to the real multicast sender by changing the header of the reply message. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 24] Internet Draft November 2000 PIM-SM Domain B | 192.50.0.0/16 +----|--------------------------------------------------+ | | | | | Receiver | | | *8 ====> 192.50.48.15 | --------------O-----------..................---------O | <==== | RP-B <==== *9 | *10 | 192.50.22.8 | | +------+-------------------+------------------+ | | | 5500 | 224.60.70.80:3400 | 133.25.15.3:2690 | | | +------+-------------------+------------------+ | | | | | | | | : : : : | | MSDP-FE Translation Table | | | +-------------------------------------------------------+ Figure 12: Example of sender address/port# conversion in intra-domain multicast communication RP-B in Fig.12 has the following IP masquerade-like processing tables, << Original multicast header>> Destination Address: 224.60.70.80 Destination Port Number: 3400 Source Address: 133.25.15.3 Source Port Number: 2690 << New ID for identifying the above multicast header >> Unique ID: 5500 When RP-B retrieves the original multicast packets received from the upstream RP-A, it changes the source address and source port number for the original multicast header, and sends this multicast packet toward the multicast receivers, as shown in Fig.13. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 25] Internet Draft November 2000 Destination Source +--------------+--------------+ IP | 224.60.70.80 | 192.50.22.8 | +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 3400 | 5500 | (port number) +--------------+--------------+ Figure 13: Header information of the multicast packet *8 in Fig.12 delivered from the RP If the multicast receiver sends a reply back to the sender with unicast, the unicast reply packet is sent to the RP-B with the port number 5500, as shown in Fig.14. This example shows the case where the reply packet is UDP, although other transport protocols are also allowed. Destination Source +--------------+--------------+ IP | 192.50.22.8 | 192.50.48.15 | +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 5500 | 4450 | (port number) +--------------+--------------+ Figure 14: Header information of the unicast reply packet *9 in Fig.12 sent from a receiver In order to deliver this reply packet to 'the actual multicast sender', the RP checks the destination port number of received packets, and converts the reply packet by replacing the destination address and port number with the real value based on the unique ID assigned for the original multicast header. Then, after restoring the destination of the packet to the original address, the RP forwards it toward an actual sender, as shown in Fig.15. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 26] Internet Draft November 2000 Destination Source +--------------+--------------+ IP | 133.25.15.3 | 192.50.48.15 | +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 2690 | 4450 | (port number) +--------------+--------------+ Figure 15: Header information of the unicast reply packet *10 in Fig.12 sent from RP If a UNIX implementation is considered in this scenario, when multicast packets are sent from various sender addresses or port numbers to the same multicast group, it is difficult for the RP to prepare the preassigned port numbers for all possible multicast headers and to wait for the unicast packets sent from multicast receivers. In order to solve this problem, the RP opens a RAW socket and waits for the arrival of a packet in IPPROTO_IP. If the RP receiving the packet gets a destination port number from that UDP header directly, it does not need to open multiple communication ports and wait for packets. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 27] Internet Draft November 2000 7. Packet Formats MSDP-FE messages will be encoded in the same TLV format as MSDP. 7.1 MSDP-FE-JOIN TLV When a RP receives a PIM-JOIN message to the multicast group to which a sender exists in another domain, the RP sends an MSDP-FE-JOIN message to the peer-RPF, in the direction of the originating RP of the multicast packet, along the reverse path of the SA message. After creating a MSDP-FE entry, the RP sends periodically MSDP-FE- JOIN message. 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 | 20 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Origin RP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type MSDP-FE-JOIN TLV is type 11. Reserved Must be transmitted as zero and ignored on receipt. Sequence Number This field is used in order that each RP may discriminate corresponding MSDP-FE-TYPE message. Origin RP Address The originating RP address of the multicast packet is stored. Group Address The group address the MSDP peer is requesting. Source Address The IP address of the active source for above multicast group. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 28] Internet Draft November 2000 7.2 MSDP-FE-TYPE TLV When the originating RP of the SA message received an MSDP-FE-JOIN message, the RP returns the MSDP-FE-TYPE message which specifies the method of establishing a logical multicast path along the reverse path in which the MSDP-FE-JOIN message was sent. The intermediate RPs which received the MSDP-FE-TYPE message add a unicast-type within the message to the MSDP-FE forwarding entry, and return an MSDP-FE- TYPE-ACK message to the peer-RPF which is the transmitting origin of this type message. 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 | x | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Entry Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method Type | Reserved |-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ID | |z +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Origin Group Port | Origin Source Port |-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type MSDP-FE-TYPE TLV is type 12. Length x Is the length of the control information in the message. x is 8 octets (for the first two 32-bit quantities) plus 12 times Entry Count octets (z). Reserved Must be transmitted as zero and ignored on receipt. Sequence Number This field is used in order that each RP may discriminate corresponding MSDP-FE-JOIN and MSDP-FE-TYPE-ACK messages. Method type The following translation types are defined: 0: Reserved 1: IP-in-IP Tunneling Method 2: IP Masquerade-Like Method 3: MPLS Label Switched Path (LSP) Method Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 29] Internet Draft November 2000 ID is unique ID for identifying conversion rule for translated packet. This is used as the source port number in IP masquerade header. Origin Group/Source Port The original group/source port the MSDP peer is requesting. Origin Group Port The original group port the active source has sent data to. Origin Source Port The source number with which the active source has sent data. 7.3 MSDP-FE-TYPE-ACK TLV After a RP receives the MSDP-FE-TYPE message, the RP returns an MSDP- FE-TYPE-ACK message to the peer-RPF which is the transmitting origin of the MSDP-FE-TYPE message. The MSDP-FE-TYPE-ACK message received in the peer-RPF shows rejection of the unicast-type specified in the last MSDP-FE-TYPE message, or specifies the port number in which downstream RP receives the unicast-type data. 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 | 8 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Port | Reject Cause | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type MSDP-FE-TYPE-ACK TLV is type 13. Reserved Must be transmitted as zero and ignored on receipt. Sequence Number This field is used in order that each RP may discriminate corresponding MSDP-FE-TYPE-ACK message. Receive Port The port number in which each RP receives the unicast-type data. Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 30] Internet Draft November 2000 Reject Cause The reason to which downstream RP refuses the specified translation method. 8. MSDP-FE State Machine An MSDP-FE node has the MSDP-FE state for every interface. An MSDP- FE peer starts in the INITIAL state. MSDP-FE peers establish a logical multicast path and transmit unicast packets according to the following state machine: (1) I-IF (Input Interface) state +---------+ +-------->| INITIAL | | +---------+ | | RP receives MSDP-FE-JOIN or PIM-SM-JOIN | v | +-----------+ |<--------| SEND_JOIN |<----------------------+ | Timeout +-----------+ | | | RP receives MSDP-FE-TYPE | | v | | +---------------+ | --------| SEND-TYPE-ACK |---------------------+ Timeout +---------------+ Timeout & RP has active o-if & RP has no o-if (2) O-IF (Output Interface) state RP receives MSDP-FE-JOIN or PIM-SM-JOIN +---------+ & RP has no active i-if +-------->| INITIAL |------------------------------------+ | +---------+ | | | RP receives MSDP-FE-JOIN or PIM-SM-JOIN | | | & RP has active i-if | | v v | +-----------+ +-----------+ |<--------| SEND-TYPE |<--------------------------| RECV-JOIN | | Timeout +-----------+ +-----------+ | | RP receives MSDP-FE-TYPE-ACK Timeout | | v v | +---------------+ INITIAL --------| RECV-TYPE-ACK | Timeout +---------------+ & RP has no o-if Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 31] Internet Draft November 2000 9. References [MSDP] D. Farinacci, et al., "Multicast Source Discovery Protocol (MSDP)," draft-ietf-msdp-spec-06.txt, Apr. 2000, Work in Progress. [BGMP] D. Thaler, D. Estrin, and D. Meyer, "Border Gateway Multicast Protocol (BGMP): Protocol Specification," draft-ietf-bgmp-spec-01.txt, Mar. 2000, Work in Progress. [RFC2362] D. Estrin, et al., "Protocol Independent Multicast- Sparse Mode (PIM-SM): Protocol Specification," RFC 2362, Jun. 1998. [RFC1771] Y. Rekhter, and T. Li, "A Border Gateway Protocol 4 (BGP-4)," RFC 1771, Mar. 1995. [RFC2003] C. Perkins, "IP Encapsulation within IP," RFC2003, Oct. 1996. [MPLS-ARCH] E. C. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol Label Switching Architecture," Aug. 1999, Work in Progress [MPLS-LABEL] E. C. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T. Li, and A. Conta, "MPLS Label Stack Encoding," Sep. 1999, Work in Progress 10. Authors' Addresses Masahiro Jibiki NEC Corporation Networks Development Laboratories 11-5, Shibaura 2-Chome, Minato-ku, Tokyo 108-8557, JAPAN Phone: +81 (3) 5476-1071 Fax: +81 (3) 5476-1005 Email: jibiki@netlab.nec.co.jp Atsushi Iwata NEC Corporation C&C Media Research Laboratories 1-1, Miyazaki, 4-Chome, Miyamae-ku, Kawasaki, Kanagawa, 216-8555, JAPAN Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 32] Internet Draft November 2000 Phone: +81 (44) 856-2123 Fax: +81 (44) 856-2230 Email: iwata@ccm.cl.nec.co.jp Jibiki, Iwata draft-jibiki-iwata-msdp-idmf-01.txt [Page 33]