📄 rfc1075.txt
字号:
RFC 1075 Distance Vector Multicast Routing Protocol November 1988 tunnel. The routing messages should be sent as unicast datagrams directly to the remote tunnel end-point; they should not use an IP loose source route. Justification for using the loose source route and record option for tunneling: We considered defining our own IP option to handle tunneling, but we are worried that intermediate gateways do not transparently pass IP options that are unknown to them. Datagrams using a new option would not traverse the Internet. It would be better for us if we could create a new IP option, but it won't work presently. Recall that this is a transition design to allow us to experiment in the current environment. The tunneled packet containing the LSRR option has the following features: Field Value ----- -------------------- src address = src gateway address dst address = dst gateway address LSRR pointer = points to LSRR address 2 LSRR address 1 = src host LSRR address 2 = multicast destination Two questions raised about using the LSRR option for tunnels are "Can intermediate gateways ignore the option?", and "Can the destination gateway properly detect that the LSRR is used for a tunnel?". When an intermediate gateway receives a datagram, it examines the destination address. For a tunneled datagram, the destination address will not match an address of the receiving gateway. Therefore, the LSRR option will not be examined, and the intermediate gateway will forward the datagram on to its next hop for the destination address. When the destination gateway receives a datagram, it notes that the datagram destination address matches one of its own address. It will then look at the next LSRR option address, since the source route is not exhausted. That address is a multicast address. Since hosts are forbidden from putting multicast addresses into source routes, the gateway can infer that the LSRR is for tunneling. The weakness here is that perhaps there is some other meaning for the multicast address in the LSRR. No other meaning is currently defined.Waitzman, Partridge & Deering [Page 13] RFC 1075 Distance Vector Multicast Routing Protocol November 1988 If a tunneled datagram is by error addressed to a destination gateway that does not support multicasting, then the destination gateway will try to find a route to the multicast address. This will fail, and an ICMP destination unreachable error message will be sent to the tunneled datagram's source. Since the source address in the tunneled datagram has been adjusted to be the address of the source multicast gateway, the ICMP errors will not go to the originating host, which has no knowledge of tunnels.5. Routing Algorithm This section provides a terse description of the distance-vector routing algorithm. See [1] for more information. While DVMRP can express routes to individual hosts, the forwarding and routing algorithms only support network and subnetwork routing. In the discussion below, the term "virtual interface" is used to refer to a physical interface or a tunnel local end-point. A physical interface is a network interface, for instance, an Ethernet card. A route to a destination will be through a virtual interface. The term "virtual network" is used to refer to a physical network or a tunnel, with the qualification that routes only reference physical networks. The TRPB algorithm forwards multicast datagrams by computing the shortest (reverse) path tree from the source (physical) network to all possible recipients of the datagram. Each multicast router must determine its place in the tree, relative to the particular source, and then determine which of its virtual interfaces are in the shortest path tree. The datagram is forwarded out these virtual interfaces. The process of excluding virtual interfaces not in the shortest path tree is called "pruning." Consider a virtual network. Using Deering's terminology [3], a router is called the "parent" of the virtual network if that router is responsible for forwarding datagrams onto that virtual network through its connecting virtual interface. The virtual network can also be considered a "child" virtual network of the router. Using the child information, routers can do Reverse Path Broadcasting (RPB). Unnecessary datagrams may still be sent onto some networks, because there might not be any recipients for those datagrams on the networks. There are two kinds of recipients: hosts that are members of a particular multicast group, and multicast routers. If no multicast routers on a virtual network consider that virtual network uptree to a given source, then that virtual network is a "leaf"Waitzman, Partridge & Deering [Page 14] RFC 1075 Distance Vector Multicast Routing Protocol November 1988 network. If a network is a leaf for a given source, and there are no members of a particular group on the network, then there are no recipients for datagrams from the source to the group on that network. That network's parent router can forgo sending those datagrams on that network, or "truncate" the shortest path tree. The algorithm that tracks and uses this information is the Truncated Reverse Path Broadcasting (TRPB) algorithm. Determining which virtual networks are leaves is not simple. If any neighboring router considers a given virtual network in the path to a given destination, then the virtual network is not a leaf. Otherwise, it is a leaf. This is a voting function. If a route, with a metric poisoned by split horizon processing, is sent by some router, then that router uses that virtual network as the uptree path for that route (i.e. that router votes that the virtual network is not a leaf relative to the route's destination). Since the number of routers on a virtual network is dynamic, and since all received routing updates are not kept by routers, a heuristic is needed to determine when a network is a leaf. DVMRP samples the routing updates on a virtual interface while a hold down timer is running, which is for a time period of LEAF_TIMEOUT seconds. There is one hold down timer per virtual interface. If a route is received with a metric poisoned by split horizon processing while the hold down timer is running, or at any other time, then the appropriate virtual interface for that route is "spoiled"-- it is not a leaf. For every route, any virtual interface that was not spoiled by the time the hold down timer expires is considered a leaf. For a description of an even better forwarding algorithm, the Reverse Path Multicasting algorithm, see [3]. A route entry should have the following in it: - Destination address (a source of multicast datagrams) * - Subnet mask of the destination address * - Next-hop router to the destination address - Virtual interface to the next-hop router * - List of child virtual interfaces * - List of leaf virtual interfaces * - A dominant router address for each virtual interface - A subordinate router address for each virtual interface - Timer - Set of flags that indicate the state of the entry - Metric - Infinity The lines that are marked with '*' indicate fields that are directly used by the forwarding algorithm.Waitzman, Partridge & Deering [Page 15] RFC 1075 Distance Vector Multicast Routing Protocol November 1988 The lists of child and leaf interfaces can be implemented as bitmaps.5.1 Sending Routing Messages DVMRP routing messages can be used for three basic purposes: to periodically supply all routing information, to gratuitously supply routing information for recently changed routes, or supply some or all routes in response to a request. Routing messages sent to physical interfaces should have an IP TTL of 1. A number of timeouts and rates are used by the routing and forwarding algorithms. See section 6 for their values. Rules for when to send routing messages: - Every FULL_UPDATE_RATE seconds a router should send out DVMRP messages with all of its routing information to all of its virtual interfaces. To prevent routers from synchronizing when they send updates, a real-time timer must be used. - Whenever a route is changed, a routing update should be sent for that route. Some delay must occur between triggered updates to avoid flooding the network with triggered updates; intervals of TRIGGERED_UPDATE_RATE seconds is suggested. - A request for all routes should be sent on all virtual interfaces when an DVMRP router is restarted. - If possible, when a DVMRP router is about to terminate execution, it should send out DVMRP messages with metrics equal to infinity for all of its routes, on all virtual interfaces. When sending to routers connected via networks that support multicasting, the messages should be multicast to address 224.0.0.4. Therefore, routers must listen to multicast address 224.0.0.4 on every physical interface that supports multicasting. If multicasting isn't supported, broadcasting can be used. As already mentioned, routing updates to tunnels should be sent as unicast datagrams to the remote end-point of the tunnel. When sending routing messages, except in response to a specific route request (via RDA command with a non-zero count), poisoned split horizon processing must be done. This means that given a route that uses network X, routing updates sent to network X must include that route with the metric equal to the infinity and should include theWaitzman, Partridge & Deering [Page 16] RFC 1075 Distance Vector Multicast Routing Protocol November 1988 appropriate flag set in a FLAGS0 command. Poisoned split horizon is one way to reduce the likelihood of routing loops. Another method, not available in RIP, is to choose a better infinity in a route. For routes propagated in a small, but well connected, network an infinity smaller than 16 might be better. The smaller the infinity, the less time a counting-to-infinity event will take. In traversing a wide internet, an infinity of 16 might be too small. At the cost of a longer counting-to-infinity event, the infinity can be increased. One concept in Internet Multicasting is to use "thresholds" to restrict which multicast datagrams exit a network. Multicast routers on the edge of a subnetted network or autonomous system may require a datagram to have large TTL to exit a network. This mechanism keeps most multicast datagrams within the network, reducing external traffic. An application that wants to multicast outside of its network would need to give its multicast datagrams at least a TTL of the sum of the threshold and the distance to the edge of the network (assuming TTL is used as a hop count within the network). A configuration option should allow specifying the threshold for both physical interfaces and tunnels. When a router is started, it must send out a request for all routes on each of its virtual interfaces. The request is a message that has an RDA command with a count equal to 0 in it.5.2 Receiving Routing Messages A router must know the virtual interface that a routing message arrived on. Because the routing message may be addressed to the all-multicast-routers IP address, and because of tunnels, the incoming interface can not be identified merely by examining the message's IP destination address For each route expressed in a routing message, the following must occur: IF a metric was given for the route: THEN add in the metric of the virtual interface that the message arrived on. Lookup the route's destination address in the routing tables. IF the route doesn't exist in the tables: THEN try to find a route to the same network in the routing tables. IF that route exists in the tables:Waitzman, Partridge & Deering [Page 17] RFC 1075 Distance Vector Multicast Routing Protocol November 1988 THEN IF this route came from the same router as the router that the found route came from: THEN CONTINUE with next route. IF route doesn't have a metric of infinity: THEN add the route to the routing tables. CONTINUE with next route. IF this route came from the same router as the router that the found route came from: THEN clear the route timer. IF a metric was received, and it is different than the found route's metric: THEN change the found route to use the new metric and infinity. IF the metric is equal to the infinity: THEN set the route timer to the EXPIRATION_TIMEOUT. CONTINUE with next route. IF the received infinity does not equal the found route's infinity: THEN change the found route's infinity to be the received infinity. change the found route's metric to be the minimum of the received infinity and the found route's metric. ELSE IF a metric was received, and (it is less than the found route's metric or (the route timer is at least halfway to the EXPIRATION_TIMEOUT and the found route's metric equals the received metric, and the metric is less than the received infinity)): THEN change the routing tables to use the received route. clear the route timer. CONTINUE with next route.5.3 Neighbors A list should be kept of the neighboring multicast routers on every attached network. The information can be derived by the DVMRP routing messages that are received. A neighbor that has not been heard from in NEIGHBOR_TIMEOUT seconds should be considered to be down.5.4 Local Group Memberships As required by [2], a multicast router must keep track of group memberships on the multicast-capable networks attached to it. Every QUERY_RATE seconds an IGMP membership request should be sent to the All Hosts multicast address (224.0.0.1) on each network by a designated router on that network. The IGMP membership request willWaitzman, Partridge & Deering [Page 18] ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -