Internet Draft MBONED Working Group Masahiro Jibiki Internet Draft Atsushi Iwata Expires in six months NEC Corporation March 2000 Inter-Domain Multicast Forwarding (IDMF) <draft-jibiki-iwata-mboned-idmf-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. 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 new inter-domain multicast forwarding (IDMF) mechanism for PIM-SM multicast routing protocol. Although there have been various inter-domain multicast routing and forwarding protocols, they still have a limitation for handling policy routing, QoS routing, accounting and security, which network administrators are willing to use in their network. In order to solve 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 unicast paths over which multicast packets are forwarded or flooded. The logical unicast paths are created by either IP-in-IP tunneling method , IP masquerade-like method, and MPLS label switched path (LSP) method, which can easily reuse policy routing and QoS routing for unicast routing. These logical unicast paths are established among IDMF capable nodes or proxies, which are located within each PIM-SM domain, either manually or by a dynamic IDMP tree Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 1] Internet Draft March 2000 construction protocol. The IDMP capable nodes can also behave a proxy sender of multicast packets. It can prevent a multicast receiver from changing a RP-tree into a global SP-tree, and also can help to reduce virtually the number of multicast sources for a particular multicast group. This property can be effectively used for accounting, security , and scalability enhancement required for interdomain communication. The proposed mechanism is a general framework for inter-domain multicast forwarding and can be also used as a MSDP based forwarding mechanism. 1. Introduction Various inter-domain multicast routing protocols, such as Multicast Source Discovery Protocol (MSDP) [MSDP] and Border Gateway Multicast Protocol (BGMP) [BGMP], have been proposed and have been being standardized in IETF. Especially, MSDP expected to be a near term promising solution for inter-domain multicast routing due to its protocol simplicity and easiness of deployment. MSDP is a mechanisms 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 address well the issue of the multicast packet forwarding. The 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 of inter-domain multicast forwarding (IDMF) scheme, which can be also used for enhancement of MSDP based inter-domain forwarding. The key elements of the proposed scheme are: (1) Logical unicast path tree built among PIM-SM domains: Multicast traffic across PIM-SM domains can be aggregated in unicast-format packet and transferred along the logical unicast path tree (IDMF tree) among domains. This mechanism allows us to use policies and QoS control to the inter-domain traffic in the same way as the current unicast IP network. (2) Proxy sender of inter-domain multicast packets: IDMP capable nodes or proxy can also be equipped with accounting and security mechanism required for interdomain communication. For one of security enhancements, IDMF capable nodes can also Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 2] Internet Draft March 2000 behave a proxy sender of multicast packets. There are two cases for this proxy sender; (i) the last hop IDMF node toward multicast receivers and (ii) the first hop IDMF node from multicast senders. In case of (i), this capability can prevent multicast receivers from changing the multicast path from shared RP-tree into global source-based shortest-path tree (SP-tree). Since allowance of using the global SP-tree is difficult for ensuring the above accounting and security for inter-domain traffic, it should be restricted as much as possible. In case of (ii), this capability can be used for the same reasons as (i), and also 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 (ii) can be regarded an one of scalability enhancement. (3) Automatic/dynamic maintenance of IDMF tree: IDMF tree is a kind of aggregated path tree that multiple multicast senders and receivers can use. The characteristics of the path (i.e., delay, packet loss, failure and so on) is periodically monitored. If the path cannot satisfy the QoS requirements of inter-domain traffic, IDMF capable nodes automatically reroute the path for establishing a new IDMF tree, so as to reduce the performance influence to the active inter- domain multicast traffic. This draft focuses on the key elements (1) and (2), and additionally the companion draft [IDMF-TREE] will discuss the element (3). This draft also mentions a proxy node implementation as an example, although the proposed IDMF scheme can be basically implemented on other platforms, such as PIM-SM RPs and area border routers. 2. Existing inter-domain forwarding problems PIM-SM protocol uses a PIM-Join message to build a multicast traffic delivery tree, which can be a shared RP tree from RP to multicast receivers or an SP-tree from multicast sources to receivers. Since 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 the shortest path from the receiver point of view. Thus, the Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 3] Internet Draft March 2000 multicast path cannot be chosen by the policy of the source. Therefore, if the same tree construction mechanism is applied within 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 following problems: (1) QoS routing and Traffic engineering for multicast packets: Since a multicast traffic is passed along with the reverse path along which Join message was sent (usually best-effort unicast path to the RP), even if an unicast destination and a multicast receiver is the same, a traffic destined to both may not be able to take the same path. Thus it is difficult for a network administrator to perform a QoS routing and traffic engineering for multicast packets in the same approach as is done in unicast IP network. (2) Policy routing for multicast packets: Due to the same reasons as (1), even if the network administrator wants to specify the policy for multicast routing and to control the multicast path, there has not been yet a good framework for this. (3) Accounting and security enhancement for multicast packets: Currently, there is no mechanism to choose and control the user who is allowed to join the inter-domain multicast tree, and to switch over from the shared RP tree to the SP-tree. There is also no mechanism for managing and controlling the multicast sender to allow to send multicast data to a multicast group. That is, a multicast router must accept Join messages from any receivers, and each node on the SP-tree must forward the multicast data that any senders transmit, in spite of a policy etc. Therefore, it is difficult for ensuring the accounting and security among inter-domain multicast. (4) Heterogenous router capability supports: When there is a network not supporting multicast along the SP- tree, the node located in downstream cannot always participate in the SP-tree. Although it can be usually solved by configuring a static tunneling across such a network, there has not been yet a mechanism to create such a tunnel flexibly and dynamically. Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 4] Internet Draft March 2000 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 an inter-domain multicast forwarding (IDMF) scheme. The overview of the proposed scheme and its detail mechanisms are discussed in following sections. Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 5] Internet Draft March 2000 3. The proposed IDMF scheme 3.1 IDMF Overview This subsection 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 unicast paths, over which multicast packets are forwarded or flooded. The logical unicast paths (IDMF paths) are created by either IP-in-IP tunneling method [RFC2003], IP masquerade-like method, or MPLS label switched path (LSP) method [MPLS-ARCH][MPLS-LABEL], which can be used for aggregating multicast traffic (i.e., reducing the number of multicast flows virtually) toward the same PIM-SM domain along the same IDMF paths. Thus unicast packet and multicast packet destined to the same destination network can follow the same route as the unicast route, which is convenient to perform QoS routing, traffic engineering, and policy routing in the same way as unicast IP network. 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 [IDMF-TREE]. At first, due to the effect of aggregation of multicast traffic along the IDMP paths between IDMF capable nodes, it can be simplified to do accounting of multicast packets and to do filtering of those packets for security purpose. The IDMF capable nodes can also behave 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 accounting and security enhancement required for interdomain communication. The following subsection explains the overview of followings: (1) Construction of IDMF tree (2) Packet delivery between PIM-SM domains using IDMF tree (3) Restriction of global SP-tree construction We explain an example where IDMF is implemented as a proxy node. Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 6] Internet Draft March 2000 3.2 Construction of IDMF Tree An IDMF node provides an IDMF capability as a proxy node. The IDMF node belongs to each PIM-SM domain, and establishes a peering to another IDMF node in another domain as a control channel. This peering can be used for controlling and establishing an IDMF path, which is a logical unicast path between this peer for data forwarding, and also used for configuring the multicast forwarding table at each hop of IDFM node. Establishment of peerings can be performed like a BGP [RFC1771] peering based on the policy of the network administrator. Once IDMF peerings are established among each IDMF nodes, an global inter-domain multicast tree (IDMF tree) can be built up as a control channel tree. Then, the data-forwarding tree is also logically created with the same topology as this control channel tree. Topologies of both trees are either in the form of a flat multicast tree or a hierarchical multicast tree, depending on the total size of the network. Since the control channel tree and the data forwarding tree have the same topologies, we use the same terminology, IDMF tree, for both trees in the following sections. After establishing the IDMF peering, each IDMF node exchanges the following information for configuring the data forwarding path: (1) Information of each IDMF node itself (2) Method for creating the IDMF paths, either IP-in-IP tunneling, IP masquerade-like method, or MPLS label switched path (LSP) method. IP-in-IP tunneling [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 has to be fragmented, and it is likely to a performance bottleneck of this processing. Note that considering that most of the current multicast application is used for real-time application, their packet length is likely short, and the possibility of fragmentation might be less than normal unicast traffic situation. With IP masquerade-like method, IDMF nodes need to convert an original multicast IP packet into a new unicast IP packet 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 IDMF peers in advance. Since this method does not change the packet length, it does not have a Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 7] Internet Draft March 2000 fragmentation problem. Instead the conversion takes more processing power to support the wire-speed forwarding in a short latency. MPLS label switched path (LSP) method [MPLS-ARCH][MPLS-LABEL] is a lower layer tunneling scheme than IP-in-IP tunneling. Although IP-in- IP tunneling uses the layer 3 forwarding capability in IP routing, MPLS LSP uses a MPLS layer forwarding (i.e., layer 2.5) beneath of layer 3 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, and multipath routing and so on. However, the label (shim header) has to be put in font 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 administrator has to choose either one of methods, depending on the network configuration and traffic demand. The detail procedures for constructing and managing the IDMF tree will be explained in [IDMF- TREE]. Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 8] Internet Draft March 2000 3.3 Creation of multicast forwarding entry at each IDMF node As explained in the previous section, once the data-forwarding path is configured, next step is to create the multicast forwarding entry at each hop of IDMF node. Although there are several possible approaches for this, we explain two approaches for an example of the solution. Since the main motivation of this internet draft is to focus on the data forwarding mechanism, this draft simply explains the overview of the approaches, and the detail procedures of these approaches and alternative approaches will be discussed in a separate draft. The first approach simply uses MSDP for advertisement or flooding of multicast source addresses along the IDMF tree. Applying the MSDP along the IDMF tree, MSDP can flood a pair of real multicast source address (real-S) for each multicast sender and multicast group address (G) to the whole IDMF nodes in other domains. Each IDMF node can know whole (real-S,G) pair information within the network. As explained in the following sections, the last hop of IDMF node toward multicast receivers behaves a proxy of real multicast senders (real-S). Assume that there are M multicast groups in the whole network, and the multicast receivers within the same domain are interested in N multicast groups out of M. Then, the last hop of IDMF node sends M PIM-SM-Register packets (each for different multicast group) to the RP in the same PIM-SM domain as a representative of real multicast senders (real-S). The IDMF node receives M PIM-Join messages from RP in the PIM-domain, based on which multicast groups (G) multicast receivers are interested in. Receiving the PIM-Join messages, the IDMF node updates the multicast 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 IDMF-Join message for each multicast source to the upstream IDMF node along the IDMF tree. The intermediate IDMF nodes forward the IDMF-Join message to upstream IDMF nodes, creating a multicast forwarding entry (*,G) pair if such a forwarding entry does not yet exist. Note that this forwarding entry can specify the multicast group address and its outgoing port by either IP-in-IP tunneling path, the IP-masquerade type path, or MPLS LSP type path. With the second approach, we propose Multicast Proxy Source address Advertisement (MPSA) method, as a kind of extension of MSDP. Instead of advertising the real multicast source addresses, a source address of an IDMF node (S) is advertised as a representative of multiple multicast senders within the same domain. This approach can reduce the number of multicast source addresses due to the effect of Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 9] Internet Draft March 2000 aggregation into a small number of IDMF node addresses. The other behavior is the same as the first approach. Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 10] Internet Draft March 2000 3.4 Packet delivery between PIM-SM domains using IDMF tree The IDMF node initially joins to the RP of its own domain and can start to receive the multicast packets sent from multicast senders within its own domain. When receiving the multicast packets, the IDMF node checks the multicast forwarding entry, (*,G) or (S,G), and if such forwarding entry exists, the IDMF node forwards or floods the received multicast packets along the associated outgoing IDMF paths, over which the multicast packets are converted into the unicast-type packets. When the IDMF node receives the unicast-type packet from an IDMF peer, it processes the following: (1) The IDMF node converts the received unicast-type packets into the original multicast packets, and checks the multicast forwarding entry associated with multicast destination group. If the outgoing entry exists toward the 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 be selected either an original multicast packet or an converted multicast packet which the IDMF node behaves a proxy of multicast senders. The latter one is discussed in the following subsection. (2) After checking the multicast forwarding entry, if the outgoing entry exists toward the next hop (downstream) IDMF peers, the original multicast packets are encoded again with the unicast- type packets and are flooded along the associated downstream IDMF peers, except for the IDMF peer from which the unicast- type packet is received. Since the IDMF tree is built with unicast-type logical path, 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 the 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 network. Since multicast communication is emulated along the logical unicast communication, it is also possible to prevent eavesdropping between domains by an unauthorized user's join. Moreover, since a multicast communication beyond the domain boundary can be controlled only by an IDMF node, an accounting model can be easily developed. Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 11] Internet Draft March 2000 3.5 Restriction of global SP-Tree Construction As explained above, the IDMF node forwards multicast packets downstream toward the shared RP tree within the same domain, if the outgoing entry exists toward the 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 the performance, such 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, following two approaches are used for solving this problem. As a straightforward approach against a change of 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 a value of the threshold is defined as operation/implementation dependence in RFC, this is also considered to be a reasonable approach (as well as fixing of a RP) for providing the stable network. Another approach is a scheme where the IDMF node behaves a proxy of multicast senders. The IDMF node converts the original packets into a new multicast packet, which uses IP masquerade-like conversion for supporting this behavior. In this case, the IDMF node 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 IDMF node and the multicast receiver, which means only an intra-domain PIM tree. Thus, the SP-tree is not built across a boundary of the domain. By using both approaches, the inter-domain multicast communication can be performed without adding any modification to the current PIM-SM. Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 12] Internet Draft March 2000 4. Detail procedures for the proposed IDMF scheme The example of an inter-domain multicast communication using IDMF is shown in Fig.1. In this Figure, RP and IDMF capability is collocated within the same physical node as an example. IDMF nodes within three PIM-SM domains A, B, and C establish peerings among them, and the multicast traffic is originated from a sender at the domain A, and delivered across the PIM-SM domain boundary to domains B and C. 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/IDMF-A | *2 | RP/IDMF-B | *3 | RP/IDMF-C | | 133.25.24.10 | ====> | 192.50.22.8 | ==> | 210.14.40.7 | | O--------------------------O----------------------O-------------- | | | IDMF | | | | | | | : | peering | : | | : | | (Register Msg) | | (Multicast) | | (Multicast) | | : | | : | | : | | | *1 | | | *4 | | | *4 | | | <==== | | | ====> | | | ====> | | O-------O | | +-------O | | +-------O | | DR Sender | | Receiver | | Receiver | | 133.25.15.3 | | 192.50.48.15 | | 210.14.72.16 | | | | | | | +----------------+ +----------------+ +----------------+ Figure 1: Example of an inter-domain multicast communication using IDMF In the arrow *1, *2, and *3 drawn in Fig.1, the header of the multicast packet is different. Sec. 4.1, 4.2, 4.3, and 4.4 explain the forwarding table maintained at the IDMF node, and the header structure of each packet for arrow *1, *2, and *3. Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 13] Internet Draft March 2000 4.1 Forwarding table maintained at the IDMF node The IDMF node maintains the inter-domain multicast forwarding table associated with: (1) Multicast-sender-to-IDMF forwarding (2) IDMF-to-IDMF forwarding/flooding (3) IDMF-to-multicast-receiver forwarding Each forwarding table is discussed in following sections. In term of (2), IDMF peerings are established among other IDMF nodes in other domains across the domain boundary. IDMF nodes use TCP connection for updating the multicast forwarding table. In terms of (1) and (3), no special control connections are necessary between IDMF nodes and multicast senders/receivers. 4.2 The behavior of multicast sender to IDMF node Consider the case where the multicast sender (133.25.15.3) sends a multicast packet with the header information shown in Fig.2. Actually until the (S,G) state has been created in all the routers between RP and desginated 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 IDMF-A from the designated router in PIM-SM domain A. Dst Src +--------------+--------------+ IP | 224.60.70.80 | 133.25.15.3 | (IP address) +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 3400 | 2690 | (port number) +--------------+--------------+ Figure 2: Header information of the original multicast packet *1 in Fig.1 Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 14] Internet Draft March 2000 4.3 The behavior of IDMF node to downstream IDMF node As explained above, IP-in-IP tunneling method, IP masquerade-like Methods, or MPLS LSP method are used for creating unicast-type IDMF paths. Before actual transmission of unicast-type data, an IDMF node negotiates with each peer which method is used for packet encoding. IP-in-IP tunneling method is used as a default method, if the IDMF peers fail in negotiation for the encoding method. 4.3.1 IP-in-IP tunneling method When IP-in-IP tunneling is used as an IDMF path, an IDMF node appends an unicast IP header, which is destined to the IDMF peer, in front of an original multicast packet. The IDMF node forwards or floods this unicast packet downstream to associated IDMF peers, based on the multicast forwarding table. We explain the example based on the network topology of Fig.1. IDMF-A creates the following IP-in-IP header, which is appended in front of the IP multicast packet header shown in Fig.2. The entire IP-in-IP tunneling header is shown in Fig.3. IDMF-A forwards or floods this packet to IDMF-B. When The IDMF-B receives this packet, it strips off the IP header to get the original multicast packet. Destination Address: IP address of a downstream IDMF node Source Address: IP address of an IDMF node itself transmitting this encapsulation packet Protocol Number: 4 (protocol number of IP) Dst Src +--------------+--------------+ 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 3: IP-in-IP header information used by packet *2 in Fig.1 Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 15] Internet Draft March 2000 As an UNIX implementation example, each IDMF node opens a RAW socket and waits for arrival of a packet in IPPROTO_IP. Once the IDMF node receives a packet, it compares the source address in the IP header of the packet with its own IDMF peer lists. If the source address is included in the list, the IDMF node looks into the protocol number further, and strip off the IP header to get the original multicast packet. Then, IDMF-B checks the destination address of the received multicast packet with the multicast forwarding entry. If the associated forwarding entry exists, IDMF-B creates another IP-in-IP tunneling header for this packet as shown in Fig.4 and floods this packet to associated downstream IDMF nodes. In this example, IDMF-B forwards the packet again to IDMF-C. Note that the header and PDU of the original multicast packet is not changed along the IDMF-to-IDMF path. Destination Address: IP address to a downstream IDMF node Source Address: IP address of an IDMF node itself, which floods down the IP-in-IP tunneling packet Protocol Number: 4 (protocol number of IP) Dst Src +--------------+--------------+ 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 4: IP-in-IP header information used by packet *3 in Fig.1 Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 16] Internet Draft March 2000 4.3.2 IP masquerade-like method When IP masquerade-like method is used as an IDMF path, an IDMF node converts an original multicast IP packet into a new unicast IP packet 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 (unique ID within the IDMF node) of the new unicast IP packet. The IDMF node exchanges in advance such a conversion rule information by Multicast Sender/Group message (i.e., MSG message), which describes the relationship between the original multicast packet header information and the assigned unique ID (a new source port number), as follows. << MSG 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 headers (i.e., used as the source port number in IP masquerade header) The downstream IDMF node receives the MSG message from an upstream IDMF peer, it checks the multicast forwarding table to see the associated downstream IDMF peers. If such peers exist, the IDMF node assigns another new ID for flooding the packets to further downstream IDMF nodes. After exchanging above information, the IDMF node converts the header of the original multicast packet as follows and transmits to the downstream IDMF nodes. Destination Address: IP address of the downstream IDMF node Destination Port Number: Port number used at the downstream IDMF node Source Address: IP address of an IDMF node itself forwarding the multicast packets Source Port Number: Unique ID for identifying the original multicast packet header. This information is exchanged in advance by MSG message between IDMF peers. Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 17] Internet Draft March 2000 When the downstream IDMF node receives the IP masquerade packets, it converts the packets into the the original multicast packet, by using the source port number information, which can be associated with the original multicast packets. Dst Src +--------------+--------------+ IP | 224.60.70.80 | 133.25.15.3 | (IP address) +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 3400 | 2690 | (port number) +--------------+--------------+ Figure 5: Header information of the original multicast packet *1 in Fig.1 For example, give that the multicast sender (133.25.15.3) sends the multicast packet with the header information shown in Fig.5, IDMF-A sends the MSG message including the following information to IDMF-B: Destination Address: 224.60.70.80 Destination Port Number: 3400 Source Address: 133.25.15.3 Source Port Number: 2690 Unique ID: 4210 IDMF-B returns the MSG-ACK message back to the IDMF-A, indicating 5370 as a receiving port number for example. After such a negotiation is done, IDMF-A performs a conversion of the original multicast header into the value shown in Fig.6, and transmits the IP masquerade-like packet to IDMF-B. Based on the source port number, IDMF-B can recognize that the multicast packet shown in Fig.5 is encoded with IP masquerade-like method. Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 18] Internet Draft March 2000 Dst Src +--------------+--------------+ IP | 192.50.22.8 | 133.25.24.10 | (IP address) +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 5370 | 4210 | (port number) +--------------+--------------+ Figure 6: Header information of the IP masquerade-like packet *2 in Fig.1 When IDMF-B receives the MSG message from IDMF-A, it checks the multicast forwarding entry to see the next downstream IDMF peers, IDMF-C in this example. IDMF-B assigns a new unique ID (for example, 6640) for the logical unicast path between IDMF-B and IDMF-C, and sends MSG message to IDMF-C. IDMF-C sends back MSG-ACK message, indicating 4990 as a receiving port number for example. Then, IDMF-B transmits the IP masquerade-like packet shown in Fig.7 to IDMF-C. Like IDMF-B, after acquiring 6640 from the source port number of the received packets, IDMF-C can restore the original multicast packet. Dst Src +--------------+--------------+ IP | 210.14.40.7 | 192.50.22.8 | +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 4990 | 6640 | (port number) +--------------+--------------+ Figure 7: Header information of the IP masquerade-like packet *3 in Fig.1 4.3.3 MPLS Label Switched Path (LSP) method When MPLS LSP method is used as an IDMF path, an IDMF node appends an MPLS shim header[MPLS-LABEL], which is destined to the IDMF peer, in front of an original multicast packet. The IDMF node forwards or floods this unicast packet downstream to associated peer IDMF nodes, based on the multicast forwarding table. The MPLS shim header is 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 label field. Except the prepended header format, the same behavior as IP-in-IP tunneling is applied for this mode. Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 19] Internet Draft March 2000 4.4 The behavior of IDMF node to multicast receivers As explained in Sec. 3.4, in order to prevent multicast receivers from switching from the shared RP-tree to the global SP-tree, IDMF node behaves a proxy of multicast senders. This also can be done in the same approach as IP masquerade-like method described above. Each IDMF node assigns a new unique ID for the original multicast packet header before forwarding down into own PIM-SM domain. The new unique ID is assigned onto the source port number of forwarding packets, as follows. Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 20] Internet Draft March 2000 Destination Address: Multicast group Destination Port Number: Destination port number Source Address: IP Address of an IDMF node forwarding the multicast packets Source Port Number: Unique ID for identifying the above header address. Fig.8 shows modification of the sender address and port number in Fig.1. Let us consider the case where IDMF-B forwards the multicast packet by changing the source address and the source port number of the original multicast packets. Additionally, consider the case where the multicast receiver also replies back with unicast to the IDMF node, which can be forwarded to the real multicast sender by changing the header of the reply message. PIM-SM Domain B | 192.50.0.0/16 +----|--------------------------------------------------+ | | | | | Receiver | | | *4 ====> 192.50.48.15 | --------------O-----------..................---------O | <==== | RP/IDMF-B <==== *5 | *6 | 192.50.22.8 | | +------+-------------------+------------------+ | | | 5500 | 224.60.70.80:3400 | 133.25.15.3:2690 | | | +------+-------------------+------------------+ | | | | | | | | : : : : | | Multicast Sender/Group Information Table | | | +-------------------------------------------------------+ Figure 8: Example of sender address/port# conversion in intra-domain multicast communication IDMF-B in Fig.8 has the following IP masquerade-like processing tables, << Original multicast header>> Destination Address: 224.60.70.80 Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 21] Internet Draft March 2000 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 IDMF-B retrieves the original multicast packets received from the upstream IDMF-A, it changes source address and source port number for the original multicast header, and sends this multicast packet toward the multicast receivers, as shown in Fig.9. Dst Src +--------------+--------------+ IP | 224.60.70.80 | 192.50.22.8 | +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 3400 | 5500 | (port number) +--------------+--------------+ Figure 9: Header information of the multicast packet *4 in Fig.8 delivered from the IDMF node If the multicast receiver sends a reply back to the sender with unicast, the replied unicast packet is sent to the IDMF-B with the port number 5500, as shown in Fig.10. This example shows the case where the replied packet is UDP, although other transport protocols are also allowed. Dst Src +--------------+--------------+ IP | 192.50.22.8 | 192.50.48.15 | +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 5500 | 4450 | (port number) +--------------+--------------+ Figure 10: Header information of the unicast reply packet *5 in Fig.8 sent from a receiver Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 22] Internet Draft March 2000 In order to deliver this replied packet to "an actual multicast sender", the IDMF node checks the destination port number of received packets, and converts the replied packet such that the destination address and destination port number can be replaced by 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 IDMF node forwards it toward an actual sender, as shown in Fig.11. Dst Src +--------------+--------------+ IP | 133.25.15.3 | 192.50.48.15 | +--------------+--------------+ | 17 | (protocol number) +--------------+--------------+ UDP | 2690 | 4450 | (port number) +--------------+--------------+ Figure 11: Header information of the unicast reply packet *6 in Fig.8 sent from an IDMF node If an 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 an IDMF node 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, an IDMF node opens a RAW socket and waits for arrival of a packet in IPPROTO_IP. If the IDMF node receiving the packet gets a destination port number from that UDP header directly, it does not need to open multiple communication ports and to wait for packets. 5. Packet Formats For further study. Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 23] Internet Draft March 2000 6. References [MSDP] D. Farinacci, et al., "Multicast Source Discovery Protocol (MSDP)," draft-ietf-msdp-spec-05.txt, Feb. 2000, Work in Progress. [BGMP] D. Thaler, D. Estrin, and D. Meyer, "Border Gateway Multicast Protocol (BGMP): Protocol Specification," draft-ietf-bgmp-spec-00.txt, Jan. 2000, Work in Progress. [RFC2362] D. Estrin, et al., "Protocol Independent Multicast- Sparse Mode (PIM-SM): Protocol Specification," RFC 2362, Jun. 1998. [IDMF-TREE] M. Jibiki, and A. Iwata, "IDMF Tree Management," draft-jibiki-idmf-tree-00.txt, (to be appeared in near future) [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 7. Authors' Addresses Masahiro Jibiki NEC Corporation Internet Technology Laboratories 11-5, Shibaura 2-Chome, Minato-ku, Tokyo 108-8557, JAPAN Phone: +81 (3) 5476-1071 Fax: +81 (3) 5476-1005 Email: jibiki@ccs.mt.nec.co.jp Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 24] Internet Draft March 2000 Atsushi Iwata NEC Corporation C&C Media Research Laboratories 1-1, Miyazaki, 4-Chome, Miyamae-ku, Kawasaki, Kanagawa, 216-8555, JAPAN Phone: +81 (44) 856-2123 Fax: +81 (44) 856-2230 Email: iwata@ccm.cl.nec.co.jp Jibiki, Iwata draft-jibiki-iwata-mboned-idmf-00.txt [Page 25]