Network Working Group Vasaka Visoottiviseth INTERNET-DRAFT Hiroyuki Kido Expiration Date: September 2003 NAIST / WIDE Project Yosuke Takahashi Noritoshi Demizu WaterSprings.ORG March, 2003 Sender Initiated Multicast (SIM) Status of this Memo This document is an Internet-Draft and is subject to 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 Sender Initiated Multicast (SIM) is a point-to-multipoint multicast mechanism. SIM will not replace the existing multicast protocol, but will be a subset of entire multicast protocol suite. Its design goals are to gain more simplicity than the traditional IP multicast and to gain less header-processing overhead than the Xcast protocol. It eliminates the cost of allocating global multicast address, by routing packets according to receiver unicast addresses attached to packet headers. Access control can be introduced before, members of a receiving group are explicitly specified by the sender. A group is identified by the combination of sender's unicast address and a Vasaka, et al. [Page 1] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 multicast group address. The key feature of SIM is in its Preset mode, which can lessen the costs of route lookups and provides cost- efficient packet forwarding by using a SIM Forwarding Information Base (FIB) maintained on routers. Moreover, a SIM tunnel will be automatically created between two routers that act as multicast branching points. Therefore, SIM can gain scalability by maintaining FIB entries only on the branching routers. In this document, we describe SIM including its delivery models, SIM FIB operations, the formats, and security considerations. Table of Contents 1. Introduction 2. Acronyms and Terminology 3. Overview 4. Characteristics of SIM 5. Creating a multicast session 6. SIM Forwarding Procedure 7. SIM Basic Rules 8. SIM Forwarding Information Base (FIB) 9. SIM FIB Operations 10. SIM Tunnel 11. SIM Routers 12. Header Format 13. Interoperability with Existing Protocols 14. Security Considerations Changes 00 -> 01 : - delete checksum from SIM header for IPv4 - fix length of bitmap field in SIM header to 64 bits - change SIM redirect header fields - editorial change 1. Introduction Since multicast efficiently sends data to a group of receivers, it has been considered important for multi-party applications such as video conferencing and data distribution. The ordinary IP Multicast mechanism is based on "Host Group Model". Receivers are responsible for joining/leaving a multicast group. Control messages are passed among upstream routers to establish or tear down multicast paths according to receivers' requests. As a Vasaka, et al. [Page 2] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 result, a sender can send packets to all the joining receivers without any knowledge of the receivers. The advantages of "Host Group Model" are: - Receivers can start receiving data without disturbing senders. - Any nodes can send data to all nodes that has a particular role without any knowledge except a group address. The drawbacks of "Host Group Model" are: - Routers on multicast trees have to maintain states for each multicast group to forward packets. - Control messages have to be exchanged among routers on multicast trees to establish, keep or tear down multicast paths. - It is necessary to deploy a global multicast address space administration mechanism. [MALLOC] To avoid allocating a global multicast address, Perlman has proposed Simple Multicast (SM) [SM]. SM identifies a group by using both C (the core router address) and M (the multicast address). This eliminates the need to have unique multicast addresses and coordinate multicast addresses across the Internet. That means that every core router in the Internet can assign the full 28 bits worth of multicast addresses. Recently, Source Specific Multicast (SSM) [SSM] is proposed. SSM uses a similar technique as in SM. However, instead of using core router address, it identifies a group by the combination of source address and destination multicast address. For IPv4, the address range of 232/8 has been assigned by IANA for SSM. That means that every source can have 2^24 multicast groups. For IPv6, a source- specific multicast address can be specified by setting both the prefix length field and the prefix field to zero. Thus IPv6 allows for 2^32 SSM addresses per scope for every source. On the contrary, Explicit Multicast (Xcast) mechanism is proposed [SDBM][CLM][MDO6][SGM][DCM][ERM]. In this mechanism, instead of using a multicast address, a receiver list is attached to each packet and no additional control message is exchanged among routers. Routers on multicast trees just forward packets to all downstream routers for all receivers in receiver lists. The advantages of Xcast are: - Routers on multicast trees basically do not need to maintain states for each multicast group. - Basically, no control message is exchanged among routers. The drawbacks of Xcast are: - It is relatively heavy to forward Xcast packets compared to Vasaka, et al. [Page 3] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 ordinary multicast packets. Xcast packets might go through slow paths in high speed routers. - Data area in each packet becomes slightly smaller, especially in the IPv6 case, since a receiver list is attached. Sender Initiated Multicast (SIM) is a point-to-multipoint (p2mp) multicast mechanism. The members of a receiver group are specified by a sender, instead of receivers, similarly to Xcast. A group is identified by the combination of sender's unicast address in the source address field and a multicast address in the destination address field similar to SM and SSM. Therefore, each source can assign full 28 bits of group address. A sender always (in list mode) or periodically (in preset mode) attaches a receiver list to packets in order to specify the members of a receiver group. Each packet is forwarded along unicast paths to each receiver and is duplicated at the branching router. Routers on the paths maintain SIM Forwarding Information Base (FIB) as specified by the flags in the receiver list. In this document, we describe SIM including its delivery models, SIM FIB operations, the formats, and security considerations. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Acronyms and Terminology Acronyms and Abbreviations mp2mp = Multi-Point to Multi-Point p2mp = Point to Multi-Point SIM = Sender Initiated Multicast SIM FIB = SIM Forwarding Information Base Terminology SIM = Sender Initiated Multicast SIM Basic Rules = SIM Delivery Models SIM FIB = SIM forwarding information base SIM Hello = SIM control message SIM Host = SIM capable host SIM Node = SIM capable node SIM router = SIM capable router SIM branching router = a SIM router that acts as a multicast branching point SIM Packet = packet that has SIM related headers SIM related headers = IPPROTO_SIM in the IPv4 SIM Redirect = SIM control message to make a SIM Tunnel Vasaka, et al. [Page 4] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 SIM Router = SIM capable router SIM Tunnel = a tunnel between two SIM branching routers list mode = SIM mode that the sender attaches the receiver list to all packets preset mode = SIM mode that the sender periodically attaches the receiver list to packets 3. Overview SIM is a point-to-multipoint (p2mp) multicast mechanism for small groups. SIM is designed to aim the following. - Less cost in maintaining states information - Simple and less-costly packet forwarding mechanism - Simple to deploy and support existing applications on receiver side SIM is not intended to be replaced with the existing multicast protocols, but it is more like a subset of other protocols. Contrary to the traditional multicast model which supports many-to-many group communications, SIM is designed to support mostly a one-to-many small group communications like other Xcast protocols. To avoid collision of group addresses, a group is identified by the combination of sender's unicast address in the source address field and a multicast address in the destination address field. Multipoint-to-multipoint (mp2mp) multicast can be achieved by combining multiple p2mp multicast. The members of a receiver group are explicitly specified by a sender, instead of receivers. SIM has two modes, "list mode" and "preset mode", according to how it maintains the forwarding table. In list mode, the sender always attaches a receiver list to all packets, and the forwarding table can be cached and discarded at any time. Contrary, in preset mode, it only periodically attaches a receiver list to packets and the forwarding table will be registered for forwarding the following packets. List mode is designed for a short data flow. On the other hand, preset mode is designed for a long data flow. Switching between these two modes can be done by changing a "preset flag" in SIM header. Each packet is forwarded along unicast paths to each receiver. When a router receives a packet with a receiver list, the router groups receivers by their next hop nodes. Then, the router duplicates the packets, changes flags in the bit map field according to each next hop node, and then sends the packets for each next hop node. Each duplicated packet contains the same receiver list, while the router forwards packets according to the flags in the bit map field. By Vasaka, et al. [Page 5] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 performing this procedure on the routers on unicast paths, a packet with a receiver list can be delivered to all receivers in the receiver list. Because a packet is duplicated only at branching routers, bandwidth can be used efficiently. Routers on the paths register the next hop nodes for each multicast group in SIM Forwarding Table (FIB) in the following form: ( src(UC), dst(MC), gen_count ) --> ( coming-from, next-hop-list ) In the case of "list mode", a receiver list is attached to all packets in a flow. A SIM FIB entry can be registered as a cache to decrease the number of lookups. Caches can be discarded any time, for example, when memory is full. In the case of "preset mode", a receiver list is periodically attached to packets in a flow. A registered SIM FIB entry is used to forward following packets that do not have receiver lists. Except packets with receiver lists, the forwarding processing cost for SIM might be close to the cost for SM and SSM. In both modes, a SIM FIB entry will be removed if a router does not observe a corresponding receiver list for a certain period of time (i.e. soft state). If the procedure briefly described above was performed at every router on paths, all routers on multicast trees had to maintain states for each multicast group. To decrease the number of routers that need to maintain states, following optimization mechanisms are introduced. First, if the receiver list for a next hop node consists of only one receiver, SIM header will be detached and the destination address field of the packet forwarded to the next hop node is filled with the receiver's address. The source address field is filled with the sender's address. By this mechanisms, routers beyond last branching point of a multicast tree do not have to maintain states for the multicast group. Second, if an AS has high speed backbone links, the ingress routers of the AS may group the receivers in a receiver list by the egress routers of the AS instead of next hop routers, and send duplicated packets to each egress router by using a mechanism like tunneling called "SIM Tunnel". By this mechanism, the core routers of the AS do not need to maintain states for multicast groups nor to process SIM packets. In other words, multicast trees are made simple by allowing duplicated packets to be flow over the same high speed links. Third, only in the case of preset mode, branching routers exchange redirect messages in order to skip non-branching router by using SIM Tunnel. By this mechanism, only branching routers of a multicast tree need to maintain states for the multicast group and to process Vasaka, et al. [Page 6] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 SIM packets. By combining all optimization mechanisms described in this paragraph, both the number of routers that need to maintain states and the average number of states in each router can be decreased. In order to increase the number of existing unicast and multicast applications that can be used as receivers of SIM mechanism, SIM has the following features. First, the destination address field of a SIM packet will be replaced with receiver's unicast address when the packet reaches at each receiver. When this feature is used in list mode, SIM routers act like Xcast routers. Second, SIM related headers can be stripped off from a SIM packet when the packet reaches at each receiver. Third, any part of upper-layer protocols, such as checksums and port numbers, can be substituted with specified data for each receiver when the packet reaches at receivers. 4. Characteristics of SIM We now discuss some characteristics of Sender Initiated Multicast. (1) Only branching routers maintain states in preset mode In the case of preset mode, only branching routers of a multicast tree need to maintain states for the multicast group and to process SIM packets. This is accomplished by redirect message exchanges exchanged among SIM routers in order to skip non-branching router by using SIM Tunnel. (2) Conversion to Unicast Packet SIM related headers of a SIM packet MUST be stripped off at the last SIM branching router before the packet reaches the destination host. The destination address field of a SIM packet MUST be replaced with receiver's address when the packet reaches at each receiver. (3) Partial Substitution of Upper Layer Protocol Any part of upper-layer protocols, such as checksums and port numbers, MUST be substituted with specified data for each receiver when the packet reaches at receivers. Substitution rules are specified with the offset from the top of upper-layer protocol, the length of substitution data and substitution data for each receiver. Substitution data are stored in a SIM option header in the order of a receiver list. Substitution data for invalidated receivers in the bitmap MUST also be appeared. The fields that will be substituted in the upper-layer protocol MUST be zero. Vasaka, et al. [Page 7] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 5. Creating a multicast session Now we describe the design of SIM and its basic operations in detail. 5.1 Allocating a multicast address SIM uses the two tuple of (sender unicast address, multicast address) to identify a multicast session. Therefore, the multicast address does not need to be unique. That means every senders can assign the full 28 bits worth of multicast addresses. Each sender may assign the multicast group address randomly. A multicast session will contain of one sender and multiple receivers. For many-to-many communication such as video conferencing can be achieved by creating multiple multicast sessions. 5.2 Membership Because each sender control the access separately, senders need to notify the receivers about the multicast session. That is, they have to notify the sender unicast address and the multicast address. These can be deployed through several possible membership management system depending on the communication models. For one-to-many group communication such as file distributing, the sender itself can hold the membership management system. It may send a Join-Invitation message to each receivers. And after receiving Join-Acceptance message from receivers, it can begin sending multicast data. On the other hand, for many-to-many group communication such as video conferencing, it is not convenient to maintain the same receiver list on all nodes. It would be better to have only one node acts as a group membership management server that will centrally maintain the receiver list. This node may be one of a group member or the third part node. Each member has to register to this membership management server, and share the list before beginning the conference. Multicast membership management can be implemented in application layer. 6. SIM Forwarding Procedure SIM forwards the packet as the following. (1) The sender sends SIM packets to the nearest SIM router. (2) The SIM router will find out the receiver list from packet header, Vasaka, et al. [Page 8] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 and look up unicast routing table to find out the next hop nodes for each receiver. (3) If the packet for all receiver in the list is going to be forwarded to the same next hope node, and that node is also a SIM router, the packet will be forwarded to the next SIM router without any modification. (4) Else if the packet is going to be forwarded to multiple next hop nodes, the packet will be duplicated. Flag in the bit map field in SIM header will be rewritten according to the receivers. - If there is only one receiver on the list, the packet header will be rewritten as if it is a unicast packets. - If the next hope router is not SIM-aware router, and it is assumed that there is no SIM-aware router on the network path to the receivers, the packet will be send separately to each receiver. The source and destination field in packet header will be rewritten as if they are unicast packets. (5) The packets will be forwarded by using rules 2-4 as described above until they reach all the receivers. 7. Delivery Models Several delivery models are taken into account in SIM. Three intra- AS models are described in 7.1, 7.2 and 7.3. Administrators may choose any model for their networks. One inter-AS model and one last-hop model are described in 7.4 and 7.5, respectively. 7.1 Island Model - Assumptions - SIM capable routers and hosts are placed only around and behind slow links in order to save bandwidth. This model may be widely chosen at the first stage of SIM deployment. - Behaviors - At first, before sending or forwarding a SIM packet with a receiver list, a SIM capable node determines the "next hop nodes" for each receiver in a receiver list by looking up the unicast routing table. - If a "next hop node" is SIM capable, the SIM capable node sends or forwards the SIM packet to the "next hop node" by using SIM Basic Rules. - If a "next hop node" is not SIM capable, the packet is duplicated and sent to each receiver by filling the destination address field with each receiver's address. 7.2 Continent Model Vasaka, et al. [Page 9] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 - Assumptions - In an AS or in user networks, all routers and hosts are SIM capable. This model may be applied to campuses, LANs, small ISPs, etc. - Behaviors - The "next hop node" for each receiver is determined by looking up in the unicast routing table at each router. - All routers except egress routers forward SIM packets by using SIM Basic Rules. All hosts send and receive SIM packets by using SIM Basic Rules. - Behaviors of egress routers SHOULD follow an inter-AS model. - Notes - SIM packets are forwarded along optimal paths and are duplicated only at branching routers. - All routers on multicast trees need to maintain states for each multicast group and have to process all SIM packets unless optimization mechanisms run. 7.3 Edge-Core Model - Assumptions - In an AS, ingress and egress routers are SIM capable but core routers are not SIM capable. All SIM packets come in through ingress routers. This model may be applied to large ISPs, etc. - Behaviors - If a NOC is also a branching point in the topology of an AS, a designated branching router for the NOC may be chosen to save bandwidth. - Procedure at ingress routers are: 1. Determine "next hop nodes" by looking egress routers up for all receivers in a receiver list. If a designated branching router exists on a path from the ingress router to an egress router for a receiver, the receiver's "next hop node" can be the designated branching router in order to save bandwidth. 2. Duplicate the SIM packet for each "next hop node", and modify flags in the bit map field according to the receiver list for each packet. 3. If there is only one receiver for a "next hop node", send the packet by filling its destination address field with the receiver's address. Otherwise, if a next hop node is a neighbor, send the packet by using SIM Basic Rules. If a next hop node is not a neighbor, send the packet to the "next hop node" by using SIM tunnel. - Egress routers SHOULD follow an inter-AS model. - Notes Vasaka, et al. [Page 10] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 - In this model, routing table entries of both ingress routers and designated branching routers need to contain both egress routers and next designated branching routers in addition to next hop routers for each destination. - Core routers do not have to maintain states for each multicast group nor to process SIM packets. However, there is a possibility that packets are duplicated before real branching points. 7.4 Inter-AS Model - Assumptions - An egress router of an AS is SIM capable and forwards SIM packets to another ASes or user networks. - Behaviors - An egress router determines the "next hop node" for each receiver of an SIM packet as an ingress router for the downstream AS or user networks. An ingress router may have a designated ingress router. In such case, the "next hop node" is the designated ingress router. - If the "next hop node" is SIM capable, the egress router forwards the SIM packet by using SIM Basic Rules. - If the "next hop node" is not SIM capable, the egress router duplicates and sends to each receiver by filling the destination address with each receiver's address. 7.5 Last hop Model - Assumptions - A SIM capable node is sending or forwarding a SIM packet to a receiver. - Behaviors - If the receiver is not SIM capable, the node removes SIM related headers and sends the packet as an ordinary multicast or unicast packet. 7.6 How to adapt SIM Basic Rules To support all models described in this section, SIM forwarding rules is defined as following: 1. In the case where a receiver list needs to be parsed, a SIM node looks "next hop nodes" up according to its delivery model. Otherwise, a SIM node looks "next hop nodes" up in SIM FIB. 2. The SIM node sends/forwards the SIM packet to each "next hop Vasaka, et al. [Page 11] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 node" by using the following rules: 1. If a "next hop node" is a neighboring SIM router, the SIM node sends/forwards the SIM packet by using SIM Basic Rules. (e.g. island model, continent model, inter-AS model) 2. If a "next hop node" is a non-neighboring SIM router, the SIM node sends/forwards the SIM packet by using SIM tunnel. (e.g. ingress routers of edge-core model) 3. Otherwise, the SIM node duplicates and sends to each "next hop node" by filling the destination address with each receiver's address. (e.g. inter-AS model, edge node) 8. SIM Forwarding Information Base (FIB) Basically, many Xcast protocols also attach the receiver list to each packet, and forward the packets along the unicast paths. However, because these protocols maintain forwarding state on per-receiver basis at routers that can handle these protocols, the number of look- ups on forwarding table is usually more than once. It is relatively heavy to forward the packets compared to the ordinary IP multicast mechanism. In contrast, this problem is alleviated with SIM. Each group is identified by a two-tuple, the sender's unicast address and a multicast address. When the router received a SIM packet, it will use this two-tuple as a key to look up the SIM forwarding table or SIM FIB. This technique will reduce the number of look-ups to once, and gracefully cut off the overhead on forwarding packets. A SIM FIB entry is recorded as following. ( src(UC), dst(MC), gen_count ) --> ( coming-from, next-hop-list ) "gen_count" is generation counter of SIM FIB. "coming-from" are one of: incoming-I/F previous branching router (when SIM tunnel is used) each "next hop" is associated with: forwarding mode: direct-unicast / direct-multicast / sim-tunnel - direct-unicast .... last hop addr + ptr to routing entry - direct-multicast .. ptr to outgoing-I/F - sim-tunnel ........ tunnel egress addr + ptr to routing entry Coming-from field at right hand side is to detect changes of unicast routing. If a packet comes from a different incoming-I/F or a different previous branching router, the SIM FIB entry SHOULD be discarded and a new SIM FIB entry SHOULD be created. Vasaka, et al. [Page 12] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 9. SIM FIB Operations SIM routers maintain SIM FIB entries for each multicast group as specified by three flags in receiver lists. "Preset flag" specifies the operation mode: list mode or preset mode. A receiver list is attached to all packets of a flow in list mode, while a receiver list is attached periodically in preset mode. The other two flags are "Temporary flag" and "Delete flag". "Temporary flag" is set when a flow consists of only a few packets, or the members of a receiver list of a flow are temporary changed only for a few packets. If "Temporary flag" is set for a SIM packet, SIM routers MUST use the attached receiver list to forward the packet even if a corresponding SIM FIB entry exists. SIM routers MUST NOT create nor update a corresponding SIM FIB entry. If a corresponding SIM FIB entry already exists for this flow, the entry SHOULD be kept. "Delete flag" SHOULD be set for the last packet of a flow in order to ask SIM routers to remove a corresponding SIM FIB entry. If a SIM router receives such SIM packet, the SIM router SHOULD remove the entry after SIM_FIB_AGING time. If "Temporary flag" is not set on the packet and a SIM FIB entry exists for the flow, the router MAY use the entry to forward the packet. For some reasons, a sender may happen to have to change the members of receivers of a flow. Since a multicast group is identified by the combination of sender's address and multicast address in SIM, SIM has generation count field in order to enable routers on a multicast tree to detect member changes. When members are changed, generation count MUST be incremented by random value. Initial value of generation count SHOULD be random. A receiver list MUST NOT be changed for the same combination of source address, destination address and generation count for SIM_FIB_TIMEOUT time. A SIM FIB entry of old generation count SHOULD be kept for SIM_FIB_AGING time. If a SIM router does not receive a receiver list for a flow for SIM_FIB_TIMEOUT time, the corresponding SIM FIB entry MUST be removed. The details of SIM FIB operations are described in this section. 9.1 SIM FIB Operation for List Mode List mode is designed for relatively short flows. In this mode, a receiver list is attached to all packets in a flow. "Preset flags" are not set for any packets. If the members of a receiver list of a flow are not fixed at all, or Vasaka, et al. [Page 13] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 if a flow consists of only a limited number of packets, "Temporary flag" of SIM packets SHOULD be set. In this case, routers on paths MUST NOT create a SIM FIB entry as a cache. If the members of receivers of a flow are almost constant and a flow consists of numbers of packets, neither "Temporary flag" nor "Delete flag" is set for packets with regular members, except the last packet of the flow. Routers on the multicast tree MAY create a SIM FIB entry as a cache to optimize forwarding processing. When the sender sends a SIM packet temporary to different members, "Temporary flag" MUST be set. When the sender sends the last packet of a flow, "Delete flag" SHOULD be set. 9.2 SIM FIB Operation for Preset Mode Preset mode is designed for relatively long flows, such as real time traffic. In this mode, a receiver list is periodically attached to packets in a flow. "Preset flags" are set for all packets. When a sender sends initial SIM packets of a flow, a receiver list is attached to the packet and neither "Temporary flag" nor "Delete flag" is set. SIM routers on paths SHOULD create an SIM FIB entry for the flow and forward the packet. This entry SHOULD be used to forward following SIM packets whose number of receivers is zero. A sender SHOULD periodically attach a receiver list to SIM packets in order to refresh SIM FIB entries on SIM routers on the multicast tree. The interval time of sending such packets is SIM_FIB_INTERVAL time. If there is no appropriate packet to attach a receiver list at the time just before the timer expiration, a SIM packet without upper-layer protocol MAY be sent. When a sender wants to change the members of a receiver list, the new receiver list MUST be attached to a SIM packet and generation count MUST be incremented by random value. A SIM router receives such packet, the SIM router MUST create a new SIM FIB entry for the multicast group of the new generation count. A SIM FIB entry of the old generation count SHOULD be kept for SIM_FIB_AGING time. A sender SHOULD set "Delete flag" for the last packet of a flow. SIM routers on a multicast tree MUST remove the corresponding SIM FIB entry after SIM_FIB_AGING time. If a SIM FIB entry exists for the flow on a router, the router SHOULD use the entry to forward the packet. In preset mode, a multicast tree is simplified by removing all non- branching routers from the tree by using following procedure: When a sender sends a SIM packet, previous-hop field MUST be filled with Vasaka, et al. [Page 14] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 sender's address and skip count field MUST be set to zero. If a non- branching router receives a SIM packet, the router MUST increment the skip count by one and forward to next hop router. A SIM FIB entry for this flow SHOULD be created and kept for SIM_FIB_AGING time as a fallback for losses of SIM Redirect messages. If a branching-router receives a SIM packet and skip count is not zero, the router sends an SIM Redirect message to the previous branching router. Before the branching router forwards the packet, previous-hop field MUST be filled with the address of branching router and skip count field MUST be set to zero. When a branching router finds that a multicast tree has been changed due to member changes, the router SHOULD send a SIM packet with "Delete flag" to remove unused downstream branching routers. 10. SIM Tunnel In preset mode, SIM can automatically create a SIM Tunnel between a two branching router in order to decrease the number of routers that need to maintain states, i.e. SIM FIB. SIM Tunnel will be used to skip non-branching router. This automatic SIM tunnel is one of the significant features of SIM. It can be created by using Jump flag on SIM header. Whenever the packets forwarded to non-branching router, the jump flag will be set. When the packets reach the next SIM branching router and the Jump flag is set, that SIM router will send a "Redirect Message" to the previous SIM branching router. Because the source address of outer IP header will be changed only when the packets forwarded from the SIM branching router, SIM router can know the previous SIM branching router from this source address of the packets. When the SIM router received the redirect message, it will put the next SIM branching router to the destination address field instead of the neighbor SIM non-branching router. And, this will create a SIM Tunnel during two SIM branching routers. The non- branching routers have no need to maintain the SIM FIB entries. This mechanism accelerates the forwarding process, and also reduces the number of FIB maintained on SIM routers. 11. SIM Routers A SIM router advertises its state to neighboring SIM routers by multicasting SIM Hello message to local links. The interval time of sending SIM Hello message is defined as SIM_HELLO_INTERVAL time. The destination multicast address of a SIM Hello message is the assigned class D address for all SIM routers (not yet assigned). A SIM Vasaka, et al. [Page 15] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 capable host also listens to SIM Hello messages to recognize SIM routers. In Edge-Core Model described in 7.3, edge SIM routers advertise their states to each other by using interior gateway protocol or some other protocols. If a branching router has a designated branching router, the branching router advertises its designated branching router with its state to edge SIM routers. In Inter-AS Model described in 7.4, an ingress SIM router may advertise its designated ingress router to the edge routers of neighboring ASes by using exterior gateway protocol or some other protocols. All SIM routers maintain following states for neighboring SIM routers or egress SIM routers in the same AS. - RUNNING: - This state means the SIM router is running perfectly. - Any packet both in list mode and in preset mode can be forwarded to this SIM router. - FULL: - This state means the SIM FIB table is full and no more SIM FIB entry can be added for a while. - Packets in list mode can be forwarded to this SIM router. - Packets in preset mode cannot be forwarded to this SIM router. So packets have to be duplicated for each receiver. - DOWN: - This state means the SIM router is down now. - No packet can be forwarded to this SIM router. Packets have to be duplicated for each receiver if possible. 12. Header Format In the case of IPv4 packet, a SIM header (IPPROTO_SIM) is inserted between the outer IPv4 header and the inner IPv4 header as in Figure 1. For the outer IPv4 header, the source address field is filled with the sender address or the previous SIM branching router (the ingress router of SIM tunnel), and the destination address field filled with the next hop SIM router or the egress router of SIM tunnel. On the other hand, for the inner IPv4 header, the source address field is filled with the original sender address, and the destination field is filled with the group identification. When some fields of the upper-layer protocol such as port number and checksum are different for each receivers, the SIM option header will be used. Vasaka, et al. [Page 16] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 SIM option header will come just after the SIM header. SIM routers that act as the last branching point will use the information in SIM option header to convert SIM packet to unicast packet, and send to each receiver as described above. +----------+-------------+-------------------+----------+------------+ | Outer_IP | IPPROTO_SIM | SIM_OPTS (if any) | Inner_IP | Upper Layer| +----------+-------------+-------------------+----------+------------+ Figure 1 In the case of IPv6 packet, SIM information is embedded in Routing Header. Here, we do not use IP tunnel as in IPv4, because it will cause a big packet overhead. Instead of specifying sender address and IP multicast address in the inner IP header, we put them in SIM header. While forwarding along SIM routers, the source address field and the destination address field in IPv6 Header will be rewritten in the same way as the outer IP header in IPv4. +--------------+-------------+-------------------+--------------+ | IPv6 Header | IPPROTO_SIM | SIM_OPTS (if any) | Upper Layer | +--------------+-------------+-------------------+--------------+ Figure 2 The details of SIM header for both IPv4 and IPv6 packets are described in Appendix A. 13. Interoperability with Existing Protocols In the case where SIM is used with RSVP and IPv4, the order of headers is: IPv4, RSVP, SIM, upper-layer headers. RSVP identifies a flow by source address and multicast address of a SIM packet. If port numbers are not zero, i.e. not substituted, they are also used to identify a flow. If a SIM related headers are stripped off, a flow is identified with normal RSVP rules. In the case where SIM is used with Diffserv in an AS, if DSCPs for receivers of a SIM packet are the same, just use the DSCP in the AS. Otherwise, there are two options: Option A) chose the best DSCP if "the best" can be defined. Option B) duplicate the SIM packet for each DSCP. To use SIM with Header Compression [RFC2507] mechanism, compression method for SIM related headers has to be defined. 14. Security Considerations Vasaka, et al. [Page 17] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 14.1 SIM FIB Attacks It is possible for malicious nodes to send a SIM packet with a bad receiver list in order to make confusion of SIM FIB management. It is possible for malicious nodes to send a SIM packet with "Delete flag" in order to schedule to remove a valid SIM FIB entry. Because the malicious nodes may be able to receive packets or may be disturb valid receivers to receive packets, some protection mechanisms need to be deployed to protect valid SIM FIB entries from malicious nodes. Strict update rules for SIM FIB entry might be a candidate. An example of such rules is to prohibit updating a SIM FIB entry except when routing change is detected. However, this rule might make things worse because malicious nodes could send illegal SIM packets with various generation counts before valid SIM packets are sent. Another solution can be held in the same way that TCP generates the initial sequence number, that is to generate the initial generation counter randomly. 14.2 Using SIM as DoS attacks As discussed in "Security Framework for Explicit Multicast" [SFEM] some forms of DoS attackers can take advantage of the multicast characteristics to increase their effects. Such an attack is the smurfing attack, which uses ICMP Echo request (ping) sending to a multicast address with a source address that is the target of the attack. The traditional multicast, which uses multicast address for the destination address, deals with this problem by setting up a router or a host not to reply ICMP requests with a multicast address. In Xcast model, the DoS effect is greatly diminished because of the small number of members in a multicast group. However, the attacker can use multiple multicast groups in order to create a DoS attack as effectively as in the traditional multicast model. It will be more difficult to deal with this problem, because the destination may not recognize that it is the Xcast traffic. One strategy they proposed in "Security Framework for Explicit Multicast", is to use IPsec for securing explicit multicast traffic. However, it only provides confidentiality and/or authentication between sender and receivers. It cannot restrict nodes that can forward packets to Xcast routers. Thus, it may not be a good solution to stop smurfing DoS attacks. In the case of SIM, the same smurfing DoS attacks may be occurred. The attacker may attack a host by using SIM packets to send ICMP Echo request. However, similar to Xcast protocols, SIM supports only small group multicast, so we also can say that the smurfing DoS attacks may not be effective. Even though, detection for this DoS attack will Vasaka, et al. [Page 18] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 probably be provided on SIM routers. Basically, at the last SIM branching router, the source and destination fields of the packets will be replaced with the sender unicast address and the receiver address. Therefore, a receiver cannot distinguish the receiving ICMP Echo request, whether it was originally SIM packet or was traditional unicast packet. However, the last SIM branching router should know the answer. Thus, the detection of this type of DoS attack should be deployed on the SIM routers. When the last branching SIM router duplicates a packet for each receiver, it should check "Protocol" field of IP header for IP version 4. This "Protocol" field indicates the next level protocol type. Moreover, as assigned in RFC1700, ICMP has the protocol number "2". Thus, SIM router should not forward the packet and should discard it, if it detects that protocol field is "2". In this strategy, all SIM branching routers have to check all of the SIM packets. Thus it may generate more overheads on SIM router. Moreover, this strategy can only alleviate the effect of smurfing DoS attack, the strategy to deal with other kinds of DoS attack needs more consideration. 14.3 Using IPsec with SIM In this section, we focus on the possibility to providing secure multicast traffic by using IPsec with SIM. To use IPsec [RFC2401], we have to consider two issues: key distributing and packet encoding. First we discuss about key distributing issue. Normally in case of unicast traffic, the destination side of Security Association (SA) is in charge of choosing a Security Parameter Index (SPI) for each connection. However, in traditional multicast model, there are multiple destination nodes and probably are multiple sources per multicast group. As discussing in "Security Architecture for the Internet Protocol" [RFC 2401] and in "Secure IP Multicast: Problem are as, Framework, and Building Blocks" [SMUG], some mechanisms are required to select an unique SPI for each multicast group. They may be a Group Controller (GC) and Key Controller (KC) to create key parameters, such as an SPI for a multicast group. In the case of SIM, the size of group is small, the receivers can set their own SA and choose a SPI, and send it the sender. However, they can have a special node that will act as the SA and KC, and distribute the key to each receivers in the group. For packet encoding, IPsec uses two protocols to provide traffic security, Authentication Header (AH) [RFC2402] and Encapsulating Security Payload (ESP) [RFC2406]. AH is used to provide connectionless integrity and data origin authentication for IP datagrams, and to provide protection against replays. ESP is used to provide confidentiality, data origin authentication, connectionless Vasaka, et al. [Page 19] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 integrity, an anti-replay service, and limited traffic flow confidentiality. Each protocol supports two modes of use: transport mode and tunnel mode. In transport mode the protocols provide protection primarily for upper layer protocols, while in tunnel mode, the protocols are applied to whole tunneled IP packets. Moreover, the primary difference between the authentication provided by ESP and AH is that ESP does not protect any IP header fields unless those fields are encapsulated by ESP in tunnel mode. Now we discuss using AH and ESP respectively in both transport mode and tunnel mode. In transport mode, AH is applicable only to host implementations and provides protection for upper layer protocols, and some selected IP header fields. It is specified in RFC2402 that AH has to be inserted after the IP header and before an upper layer protocol. If we apply AH in transport mode to SIM, the packet header will be as following. [Outer IP] [AH] [SIM Header] [Inner IP] [ Payload ] In this way, SIM header will be covered by AH and cannot be modified at each branching points. Therefore, SIM cannot be used with AH in transport mode. Contrary, in tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. In this way, we still can modify SIM packet header without giving bad effect to the original AH. However, the receiver list in SIM header cannot be protected by AH. [Outer IP] [SIM Header] [AH] [Inner IP] [ Payload ] Now we consider about applying SP to SIM. It is specified in RFC2406 that the ESP header is inserted after the IP header and before the upper layer protocol header while in transport mode, or before an encapsulated IP header in tunnel mode. If we applied ESP to SIM in transport mode, ESP will be inserted to packet header as following. [Outer IP] [ESP] [SIM Header] [Inner IP] [ Payload ] In this way, SIM header will be encrypted, and SIM routers has to decrypted it in order to access and modify the receiver list. Thus, this ESP transport mode is infeasible. Contrary, in tunnel mode, ESP will be located between SIM header and inner IP header, therefore SIM routers still can access the receiver list and modified it. Vasaka, et al. [Page 20] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 [OuterIP] [SIM Hdr] [ESP] [InnerIP] [Payload] [ESP Trailer][ESP Auth] In concluding, SIM can be used with IPsec only in tunnel mode. That means we have to deploy AH or ESP, encrypt and decrypt the packets on every SIM routers. These procedure will cause more overhead and should not work well. Moreover, even we can use IPsec to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service, and limited traffic flow confidentiality, we still cannot unrevealed the receiver list and the bitmap field in the SIM header. Some attacks still can be done by spoofing the receiver list and modify flags in the bit map field for malicious use. Acknowledgments The authors would like to thank Takuya Mogami and Yoshikuni Taki for their valuable technical discussions. And, also Prof. Youki Kadobayashi and Prof. Suguru Yamaguchi for his encouragement and insightful remarks. References [CLM] D. Ooms, W. Livens, "Connectionless Multicast", , Apr 2000 [DCM] L. Blazevic, J. Le Boudec, "Distributed Core Multicast (DCM): a routing protocol for many small groups with application to mobile IP telephony", , Jun 2000 [DCM99] L. Blazevic, J. Le Boudec, "Distributed Core Multicast (DCM): a multicast routing protocol for many groups with few receivers", ACM CCR Vol.29, No.5, Oct 1999 [ERM] J. Bion, D. Farinacci, M. Shand, A. Tweedly, "Explicit Route Multicast (ERM)", , Jun 2000 [EXPRESS99] H.W. Holbrook, D.R. Cheriton, "IP Multicast Channels: EXPRESS Support for Large-Scale Single-Source Applications", SIGCOMM'99 [MALLOC] D. Thaler, M. Handley, D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC2908, Sep 2000 [MDO6] Y. Imai, "Multiple Destination option on IPv6(MDO6)", , Sep 2000 [RFC1700] J. Postel, "Assigned Numbers J. Reynolds", Oct 1994 [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", Nov 1998 [RFC2402] S. Kent, R. Atkinson, "IP Authentication Header", Nov 1998 [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload Vasaka, et al. [Page 21] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 (ESP)", Nov 1998 [RFC2507] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression", RFC2507, Feb 1999 [SDBM] C. Graff, "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC1770, Mar 1995 [SFEM] O. Paridaens, et. al., "Security Framework for Explicit Multicast", , Nov 2000 [SGM] R. Boivie, N. Feldman, "Small Group Multicast", , Feb 2001 [SM] R. Perlman, et. al., "Simple Multicast: A Design for Simple, Low-Overhead Multicast", , Oct 1999 [SMUG] T. Hardjono, et. al., "Secure IP Multicast: Problem areas, Framework, and Building Blocks", , Sep 2000 [SSM] S. Bhattacharyya, et. al., An Overview of Source-Specific Multicast (SSM) Deployment, , May 2001 Authors Information Vasaka Visoottiviseth WIDE Project c/o Graduate School of Information Science, Nara Institute of Science and Technology (NAIST) 8916-5 Takayama, Ikoma, Nara 630-0192, Japan E-mail: vasaka@wide.ad.jp, visoo-va@is.aist-nara.ac.jp Hiroyuki Kido WIDE Project c/o Graduate School of Information Science, Nara Institute of Science and Technology (NAIST) 8916-5 Takayama, Ikoma, Nara 630-0192, Japan E-mail: hiro-kid@is.aist-nara.ac.jp Yosuke Takahashi WaterSprings.ORG / WIDE Project 1-6-11-501, Honjo, Sumida-ku, Tokyo, 130-0004, Japan E-mail: t-yosuke@mtj.biglobe.ne.jp Noritoshi Demizu WaterSprings.ORG 1-6-11-501, Honjo, Sumida-ku, Tokyo, 130-0004, Japan EMail: demizu@dd.iij4u.or.jp Vasaka, et al. [Page 22] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 Appendix A: Format A-1. IPv4 receiver list - IPv4 header: - Destination address field = multicast address - Protocol field = IPPROTO_SIM (to be assigned) - DF bit = on - IPPROTO_SIM: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P|T|D|J|S|O|R|A| Protocol | Length | ndest | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | gen_count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bitmap | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Receiver's Addresses // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // (Options if any) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - flags - P: Preset flag 0: list mode 1: preset mode - T: Temporary flag 1: members are temporary - D: Delete flag 1: schedule to delete the SIM FIB entry - J: Jump flag 1: the packet has passed non-branching routers - S: SIM flag 1: there is only one receiver in the list - 0: Options flag 1: this packet comes with SIM option header - R: Redirect flag 1: this packet is SIM redirect message - A: Address flag 1: this packet has receiver list attached - Protocol: Upper layer protocol number - Length: Length of SIM header / 4 Vasaka, et al. [Page 23] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 - ndest Number of receivers - gen_count: In the case where the members of receiver list has been changed for the same combination of source address and destination multicast address, gen_count MUST be incremented by random value. Initial value SHOULD be random. - Bitmap: Valid receiver's bit is set to 1 - Receiver's Addresses List of receivers - options See A-3. A-2. IPv6 receiver list - IPv6 header: - Destination address field = multicast address - Routing Header - The difference between IPPROTO_SIM is that Protocol, Length and Checksum fields are not in this header. Other fields have the same meaning with IPPROTO_SIM. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Type=SIM | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P|T|D|J|1| Res | gen_count | ndest | Bitmap | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Bitmap // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Receiver's Addresses // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sender Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous hop (if P-flag is set set) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // (Options if any) // Vasaka, et al. [Page 24] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A-3. Options - Partial Substitution Option: - The fields that will be substituted in the upper-layer protocol MUST be zero. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option type | Option length | Offset | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Data // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Option type: Type of option - Option length: Total length of SIM option header - Offset: The beginning position (bit) of the field need to be replaced in conversion-to-unicast process - Length: Length of field to be replaced in conversion-to-unicast process - Data: Data used to replace A-4. Control messages - SIM Hello 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Status | (Padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Message Type: Type of SIM control message - SIM HELLO: 0 - SIM Redirect: 1 Vasaka, et al. [Page 25] Internet Draft draft-vasaka-xcast-sim-01.txt March 2003 - Status: Status of SIM router - RUNNING: 0 - FULL: 1 - DOWN: 2 - SIM Redirect 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | pad | length | ndest | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | gen_count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bitmap | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Appendix B: Constants SIM_FIB_INTERVAL: 10 seconds SIM_FIB_AGING: 10 seconds SIM_FIB_TIMEOUT: 60 seconds SIM_HELLO_INTERVAL: 30 seconds Vasaka, et al. [Page 26]