§1.1 Field of the Invention
The present invention concerns multicasting data. More specifically, the present invention concerns enabling a mobile node to move between foreign access nodes (e.g., routers) while maintaining the ability to source and receive multicast data.
§1.2 Background of the Invention
§1.2.1 Introduction to Communications Networks, Such as Those Supporting the Internet Protocol
Many communications networks are made up of interconnected nodes (referred to as “routers” in the specification below without loss of generality) for forwarding addressed data (referred to as “packets” in the specification below without loss of generality). The routers may be geographically distributed throughout a region and connected by links (e.g., optical fiber, copper cable, wireless transmission channels, etc.). In such a network, each router typically interfaces with (e.g., terminates) multiple input links and multiple output links. Packets traverse the network by being forwarded from router to router until they reach their destinations (as typically specified in so-called layer-3 addresses in the packet headers). Unlike switches, which establish a connection for the duration of a “call” or “session” to send data received on a given input port out on a given output port, routers determine the destination addresses of received (ingress) packets and, based on these destination addresses, determine, in each case, the appropriate output link on which to send them. The address of the next node (layer 2 address) is often referred to as a “next hop” address. The interface terminating the particular output link may be referred to as a “next hop” interface. Since, unlike switches, routers are not connection-based—packets having the same destination address may actually traverse different paths through the network.
§1.2.2 Introduction to Multicasting and IP Multicasting Protocols
Multicasting allows instances (or copies) of data from a single source to be provided to multiple destinations. Such data may be provided as datagrams, and such datagrams may be sent over a network supporting the Internet protocol (“IP”). For example, IP multicast enables a packet addressed to a multicast group destination address to be replicated and delivered within an internet routed infrastructure, to multiple receiving hosts. The multicast enables routers to compare the received multicast packets to a multicast forwarding table and send a copy of the received packet out to all the interfaces named in that multicast forwarding table down which there are presently multicast receivers. Typically, multicast routing protocols build a “dynamic delivery tree” to connect sender(s) to the receivers.
Multicast routers typically employ “reverse path forwarding” (“RPF”) checks to arriving multicast packets. Using the RPF check, a router compares the interface on which a multicast packet arrives to an outgoing interface that would be used, in accordance with unicast routing, were the router to forward data to the multicast sender (as identified by the source address field of the multicast packet). If these interfaces are not the same, then the multicast packet should be dropped (since it presumably arrived on an incorrect interface). This RPF check is used to prevent routing loops.
An example of a multicast routing protocol is described in the document D. Estrin et al., “Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification,” Request for Comments: 2362, (The Internet Society. June 1998) (hereafter referred to as “RFC 2362”, “PIM”, or “PIM-SM”, and incorporated herein by reference). RFC 2362 uses signaling defined in the document W. Fenner, “Internet Group Management Protocol, Version 2”, Request for Comments: 2236, (The Internet Society. November 1997) (hereafter referred to as “RFC 2236” or “IGMP” or “IGMPv2” and incorporated herein by reference). Note that IGMP v2 is being superceded IGMPv3 and other similar multicast membership protocols exist. Basically, under RFC 2362, hosts join and leave multicast groups by first sending IGMP “Group Membership Reports” (“GMRs”) to the access router which is acting as the IGMP Querier which is known in PIM as the “Designated Router”. The access router converts the IGMP messages into “PIM JOIN” messages (or equivalent messages for other multicast protocols). A host that is a member of a multicast group may both send and receive multicast on that group. A non-group member host (that has not sent an IGMP report) may also send to a multicast group, but non-member hosts will not receive multicast packets from other senders to that group.
In PIM, the reception of new IGMP Reception reports for new groups, causes the Designated Router (“DR”) to join towards the new multicast group by joining either to the multicast group via a “shared multicast tree”, or to the sender via a “sender-specific tree”. In a shared multicast tree, the originator first sends the multicast packets to the root of the tree (referred to as the Rendezvous Point (“RP”) in PIM). The root (e.g., RP) then forwards the packets down the tree to the group receivers. In PIM, the receivers join (the multicast group) towards the IP address of the rendezvous point and intermediate routers aggregate the joins up the tree towards the root such that only one join per group per link is generated. On the other hand, in a source specific tree, the receivers simply join (the multicast group) towards the source or originator of the multicast stream (which is identified by the source address of the multicast packets in the stream).
The reverse path forwarding (RPF) check on the PIM source-specific tree is towards the unicast address in the source address of the multicast packet. The RPF check in PIM and other shared trees, between the receiver and the root of the tree, is done towards the address of the root of the shared tree (i.e., the Rendezvous Point) rather than to the source address of the multicast packet. This is because the multicast packets should only be received via the rendezvous point (RP)—not directly from the sender. The RPF check between the sender and the RP is still on the sender address because this part of the tree is sender specific.
Multicast receivers in PIM receive packets down a unidirectional tree from either the rendezvous point (RP) or the sender. In contrast, multicast packets sent to a designated router (DR) are first sent to the top of the unicast receivers tree, this tree being either (a) the DR for a sender tree, requiring no additional action, or (b) the RP which does require additional action. Initially, in case of the packets being sent to the RP, the DR uses a PIM Register message to encapsulate the multicast data, and then sends the Register message to the RP. The RP then de-encapsulates the multicast data and forwards it down the shared tree to the receivers. The RP can then send a source specific PIM JOIN back towards the originator(s) DR, that sent the Register message, based on the contents of the Register message and configuration in the RP, this typically being designed to trigger a PIM JOIN back towards high data rate sources. The PIM JOIN arrives at the DR which causes data packets to be sent both natively and via Register messages to the RP. Consequently, while messages are received natively at the RP, the RP sends Register Stop messages periodically back to the DR to suppress Register messages. Register messages restart if Register Stops are no longer received at the DR for a certain period of time.
§1.2.3 Mobile Nodes and IP Mobility
Although most of the hosts that use the Internet, or some other IP network, access the network at consistent access points during a session, mobile nodes, such as cellular telephones, wireless computing devices and personal assistants for example, may also want to access an IP network while it moves from different access points of the IP network. The document, C. Perkins, “IP Mobility Support for IPv4”, Request for Comments: 3220, (The Internet Society, January 2002) (hereafter referred to as “RFC 3220” or “MIP”, and incorporated herein by reference) describes a protocol for enabling a moving Internet host to connect to an access router in a foreign network, containing a Foreign Agent (“FA”), yet still be contactable on its persistent Host Home Address (HoA) that it uses on its home network and is likely contained in the DNS system. This is possible because the FA gives the host a temporary local address that is either (a) unique to the host—dubbed a “Co-located Care of Address” (CCoA), or (b) unique to the FA and shared by multiple hosts at that FA—dubbed a “Care of Address” (CoA). The CCoA or CoA is registered back on the home network into a Home Agent (“HA”) and the HA tunnels (encapsulation) arriving packets destined for the HoA towards the mobile Host address (CCOA) or the FA address (CoA) which respectively detunnel the packet and deliver the packet to the HoA of the mobile Host. In the case of CcoA, the host itself detunnels the packet. In the case of the FA CoA, the FA detunnels the packet.
MIP mentions two methods for a mobile node (“MN”) to obtain multicast service. The first mobile multicast method uses the multicast routing capabilities of the home agent (HA) and home network multicast system. Thus, this first mobile multicast method is referred to as “home network multicast”. The second mobile multicast method uses the multicast routing capabilities of the foreign agent (FA) and the foreign network multicast system. Thus, this second mobile multicast method is referred to as “foreign network multicast. These mobile multicast methods are described in more detail below.
§1.2.3.1 MIP Home Network Multicast
MIP home network multicast signaling is reviewed in §1.2.3.1.1. Then, MIP home network multicast data transport is reviewed in §1.2.3.1.2.
§1.2.3.1.1 MIP Home Network Multicast—Signaling
With MIP's home network multicast, a multicast router on the home subnet acts as the IGMP Querier and the same or another multicast router acts as the Designated Router (DR). With regard to multicast signaling, the IGMP Querier issues IGMP General and Group Specific Queries onto the subnet using the all-systems multicast group (224.0.0.1). Since the Home Agent (HA) is a member of the all-systems group on the home subnet, it receives the IGMP messages from the IGMP Querier. If a mobile node (MN) has an active registration with the home agent (HA) and that registration has the ‘B’ bit set (meaning forward broadcast traffic), then the HA can forward the IGMP Query to the MN via the registered CoA. If the MN is using a CCoA, then the HA encapsulates the IGMP message from the HA address to the CCoA. This packet is sent directly to the MN which de-encapsulates it to reveal the IGMP message. If the MN is using a foreign agent (FA) CoA, then the HA first encapsulates a packet from the HA address to the HoA of the MN, and then additionally encapsulates from the HA address to the FA CoA. When this double encapsulated packet is received and the outer encapsulation is de-encapsulated by the FA, the inner encapsulation enables the FA to correctly identify the target MN from the HoA and to unicast the encapsulated broadcast packet to the MN over the access subnet.
The mobile node (MN) also originates IGMP Membership Reports and sends these back to the home subnet via the home agent (HA) to be received by both the IGMP Querier, and other members of the all-systems multicast group on the home subnet. More specifically, the IGMP messages are sent from the MN host home address (HoA) to the all-systems or all-multicast routers multicast addresses. They are then encapsulated, by the MN, with the HoA source address and the HA destination address. If the MN has selected “reverse tunneling”, then the MN can alternatively use the Encapsulating Delivery Style (EDS) and instead tunnel to the foreign agent (FA) first, which can then tunnel the packet to the HA identified in the visitor list for the source HoA.
Note that when the mobile node (MN) is either sending or receiving home network IGMP messages, whether tunneled directly or via the foreign agent (FA), the FA does not manage IGMP state for the mobile node (MN). Instead, such IGMP state is fully managed by the home agent (HA) and MN. (There is an opportunity for the FA to track group memberships however by snooping the tunneled IGMP messages.)
Once a MN is undertaking IGMP message exchanges, it can then receive and source multicast traffic. This is described in §1.2.3.1.2 below.
§1.2.3.12 MIP Home Network Multicast—Data Transport
To receive multicast traffic, the mobile node (MN) sends an IGMP Membership report towards the home agent (HA) which forwards it, after de-encapsulation, to the Home subnet and the IGMP Querier on that subnet. This causes multicast traffic for that group to be forwarded onto the subnet (if not already present) and the HA to encapsulate the multicast traffic to all MNs with membership of that group, and specifically to the MN that sent the IGMP Membership Report. When the MN is using a FA CoA, multicast forwarding is achieved by the HA encapsulating the multicast packets, from its HA address to the host home address (HoA) of the MN, and then further encapsulating the result from the HA address to the foreign agent (FA) CoA. The FA then removes the outer encapsulation before forwarding the result to the MN. The MN then removes the inner HoA encapsulation to reveal the multicast datagram. If, on the other hand, the MN is using a CCoA then the HA simply needs to encapsulate the multicast packet from the HA address to the CCoA which avoids the need for the double encapsulation.
To send multicast traffic, the mobile node (MN) can be either a member or a non-member of the destination group. In either case, the MN will send the multicast packet from its host home address (HoA) to the group address and then additionally encapsulate the packet from the HoA to the home agent (HA) address (with EDS or without reverse tunneling), or from the HoA to the foreign agent (FA) CoA (with EDS reverse tunneling). In the latter case, the FA then adds the encapsulation from the FA address to the HA address as is normal with reverse tunneling.
§1.2.3.2 MIP Foreign Network Multicast
MIP foreign network multicast signaling is reviewed in §1.2.3.2.1. Then, MIP foreign network multicast data transport is reviewed in §1.2.3.2.2.
§1.2.3.2.1 MIP Foreign Network Multicast—Signaling
To use foreign network multicast, the mobile node (MN) must be able to receive IGMP Queries sent by the IGMP Querier on the foreign subnet of the MN. In general, there will be more than one access router on the subnet, one of which contains the foreign agent (FA) for this MN. The FA, or another router, acts as a multicast router, and either can act as the IGMP Querier. Typically, the FA, the IGMP Querier and Designated Router will be in the same access router that the MN uses for foreign access services. The IGMP Queries are then sent from the FA address to the all-systems multicast group. The MN responds to Queries by replying from either its CCoA (if it has one) or its host home address (HoA), to the appropriate multicast group.
§1.2.3.2.2 MIP Foreign Network Multicast—Data Transport
To receive multicast traffic, the mobile node (MN) will have sent an IGMP membership report for the required group to the all-systems multicast group. This membership report is received by the IGMP Querier which injects the required group into the multicast routing protocol. Arriving multicast packets for that group are sent onto the foreign subnet and are received by member MNs, including the MN that sent the Membership report.
To send multicast traffic, either as a member or non-member sender, the mobile node (MN) issues multicast packets from its CCoA. If an MN does not have a CCoA, the present MIP foreign network multicast protocols do not allow the MN to originate multicast traffic. More specifically, RFC3220 states that mobile hosts that wish to be multicast senders should use its (CCoA), but may use its host home address (HoA) as the source address in IGMP messages, but must only use a CCoA to originate multicast packets into the foreign multicast routing. RFC 3220 only permits an MN to use CCoA when originating multicast packets for foreign network multicast because the source address of the multicast packet must be topologically correct (i.e., not an address from another part of the Internet) to enable the multicast packet to pass reverse path forwarding (RPF) checks. Since the CCoA is a topologically correct address at the FA, a multicast packet with a CCoA source would pass RPF checks in the foreign multicast routing. If the MN were to use its HoA as a multicast source address in the foreign network, such multicast packets would clearly not pass the RPF check because the multicast routing protocol would expect the multicast packets to arrive on interfaces pointing towards the home agent (HA) and not the MN access links on the foreign agent (FA). Consequently, MIP limits foreign network multicast to only those circumstances where the MN has a CCoA.
§1.2.4 Unmet Needs
Typically, when MIP is used in wireless systems, the mobile node (MN) employs a foreign agent (FA) CoA. Unfortunately, this prevents the MN from generally being a multicast sender on the foreign network. This is disadvantageous because multicast via the foreign network avoids the tunnels to and from the home agent (HA) which occur when home network multicasting is used. Note that the tunnel from the sender to the HA is less important because in typical multicast protocols the sender is on a sender specific tree to the root of the tree and on any specific HA there are typically only a small number of senders and all traffic from the senders is unique. However, the tunnels from multiple HAs to the FA for the same multicast group are of concern because each tunnel will contain copies of the same sequence of packets. The aim of multicast is to ensure only one copy of each packet traverses any link in the internet which can clearly not be achieved when MIP tunnels are involved. The size of the problem, compared to the case of the tunnel to the HA, is also magnified due to the fact that typical multicast groups will have significantly more receivers than senders (much like broadcast TV where one content producer (sender) feeds content to large numbers of TV sets (receivers)). Therefore, the more popular a particular piece of content on a multicast group becomes, the more likely that multiple MN receivers will be on the same FA. Consequently, the possibility of duplication of packets, and the scale of wasted bandwidth resources, will increase. Moreover, and perhaps more problematic, this limitation of MIP also denies the operator of the foreign network the ability to offer multicast services to roaming MNs (which would be particularly useful for operator specific content and for commodity (low value) Internet multicast content).
Even if the mobile node (MN) has a CCoA, using this as the source address for multicast packets from a moving (or roaming) MN is problematic since the CCoA may continuously change as the MN moves from one access node (and FA) to another. As a practical matter, the CCoA can only be used if the MN will be using that address for the entirety of the multicast session. Consequently, if the MN and the foreign multicast routing system aren't certain, in advance, that the MN will not need to change its CCoA during a desired multicast session, the home multicast system must be used.
These problematic limitations of MIP are believed to be due to a lack of foresight when MIP was being designed. More specifically, MIP was originally designed assuming that a mobile host would temporarily move to a foreign network for a period of time, and then return home, as would be the case with a traveling salesman moving between customer premises, or a teleworker moving between the home network and the corporate network. Rapid movement of a mobile host between foreign access routers was not really envisaged. In this ‘limited roaming’ usage assumption, the use of the CCoA is fine because the CCoA, which is allocated and owned by the foreign agent (FA) subnet, is stable for the period of that the mobile host visits the foreign subnet. The source specific multicast routing state in multicast routing protocols is therefore stable—the routing state is always using the same source address for source specific forwarding and the RPF check.
However, apart from its original “limited roaming” usage assumptions, MIP is now being applied to wireless, and specifically cellular, systems. Under such usage scenarios, the CCoA changes at every hand-off (of the mobile host) between foreign agent (FA) access routers. This is because the CCoA must be a topologically correct address at each FA. Each hand-off causes the multicast source address to change, which will confuse the applications at the multicast receivers because the sender address is used during demultiplexing and presentation. Each hand-off will also force the receiving hosts, IGMP and multicast routing to regenerate sender specific multicast join messages for the new source address, and update the associated source specific routing state in the network elements. Finally, receiving applications that are only “listening” to specific senders on a multicast group need to discover sender address change and reconfigure so that they continue to receive only the required packets and do not loose any packets during the address changes. The faster the hand-off, the worse is the confusion, message processing overhead, messaging bandwidth and the overall quality of the multicast packet delivery system. It is believed that the foreign multicast system would effectively be rendered inoperable by these effects. This would effectively force multicast to always be delivered, more expensively, via the home agent (HA) (by using the stable HoA as a source address and tunneling the packets back to the HA where the RPF checks can succeed, and on into the Internet multicast routing system). This tunneling approach could potentially cause multicast intended for local recipients in the foreign domain to have to traverse to the HA at a Home Network on a different continent. Having to send packets via the HA would then also force the MN to also have to receive multicast via the home network and the HA, leading to the significant bandwidth inefficiencies that this entails.
Mobile IP version 6 is a development of Mobile IP for IP version 6 networks and shares many of the design features of MIPv4 and the subsequent multicast problems. In MIPv6, there are no foreign agents (FAs) or FA CoAs, but the access router can contain a mobility attendant. The mobile node (MN) has a CCoA and again this CCoA changes on each hand-off automatically. Therefore, since the CCoA is used as a multicast source address, the problems for the multicast router and sender/receiver applications described above persist. Like MIPv4 which uses the FA to undertake these tasks, MIPv6 uses the mobility attendant to undertake these tasks. Where the MIPv4 solution relies on the state of specific MIP Registration signaling bits so equivalent bits are required and interpreted in MIPv6.
Therefore, there is a need to permit a mobile host to roam in a foreign network, with multiple access node handoffs, while permitting foreign network multicasting.
The present invention permits a mobile host to roam in a foreign network, with multiple access node handoffs, while permitting foreign network multicasting. The present invention may do so by (i) having the mobile node (MN) use a persistent address, for purposes of multicasting, (ii) relaxing or modifying reverse path forwarding checks, and (iii) modifying multicast forwarding rules.
In one embodiment, the persistent address, used in mobile networks as the source address in the IGMP Membership reports and the multicast packets, is the permanent and hence stable host home address (HoA). In such an embodiment, the present invention enables the HoA to be supported as a source address by foreign agents (FAs) and multicast routing protocols in foreign networks.
If the HoA is to be used as a source address for MIP local multicast at the foreign agent (FA) the present invention may change MIP and multicast forwarding in the host and the access router/designated router/foreign agent as follows. With regard to multicast signaling:
The present invention involves novel methods, apparatus and data structures for enabling a mobile host to roam in a foreign network, with multiple access node handoffs, while permitting foreign network multicasting. The following description is presented to enable one skilled in the art to make and use the invention, and is provided in the context of particular applications and their requirements. Various modifications to the disclosed embodiments will be apparent to those skilled in the art, and the general principles set forth below may be applied to other embodiments and applications. Thus, the present invention is not intended to be limited to the embodiments shown and the inventor regards his invention as the following disclosed methods, apparatus and data structures and any other patentable subject matter.
In the following, an exemplary environment in which the invention may operate is described in §4.1. Then, operations that may be performed by various devices in accordance the present invention are introduced in §4.2. Then, exemplary methods and data structures that may be effected by such devices, as well as examples illustrating how such methods operate, are described in §4.3. Finally, some conclusions regarding various aspects of the present invention are provided in §4.4. First, however, some terms are introduced.
Mobile Node: A host or router that changes its point of attachment from one network or sub-network to another. A mobile node may change its location without changing its IP address; it may continue to communicate with other Internet nodes at any location using its (constant or persistent) IP address, assuming link-layer connectivity to a point of attachment is available. A mobile node is given a long-term (or persistent) (e.g., IP) address on a home network. This home address may be administered in the same way as a “permanent” IP address is provided to a stationary host. When away from its home network, a “care-of address” is associated with the mobile node and reflects the mobile node's current point of attachment. The mobile node normally uses its home address as the source address of all IP datagrams that it sends.
Home Agent: A node (such as a router, server or some other forwarding device) on a mobile node's home network which tunnels datagrams for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node.
Foreign Agent: A node (such as an access router or some other forwarding device) on a mobile node's visited network which provides routing services to the mobile node while registered. The foreign agent may de-tunnel and deliver datagrams to the mobile node that were tunneled by the mobile node's home agent. For datagrams sent by a mobile node, the foreign agent may serve as a default router for registered mobile nodes.
Care-of Address: The termination point of a tunnel toward a mobile node, for datagrams forwarded to the mobile node while it is away from home. Two different types of care-of address are: (1) a “foreign agent care-of address” is an address of a foreign agent with which the mobile node is registered, and a (2) “co-located care-of address” is an externally obtained local address which the mobile node has associated with one of its own network interfaces and is topologically correct (i.e., unicast routable by the normal internet routing system) at the FA.
Correspondent Node: A peer with which a mobile node is communicating. A correspondent node may be either mobile or stationary.
Foreign Network Any network other than the mobile node's Home Network.
Host Home Address: An (e.g., IP) address that is assigned for an extended period of time to a mobile node. It remains unchanged regardless of where the node is attached to the Internet. Therefore, it is an example of a “persistent” address.
Home Network: A network, possibly virtual, having a network prefix matching that of a mobile node's home address. Standard IP routing mechanisms will deliver unicast datagrams destined to a mobile node's Home Address to the mobile node's Home Network. The global multicast system will also already accept multicast packets sent via the home network when the packet source address is a home address from that home network.
Link: A facility or medium over which nodes can communicate at the link layer. A link underlies the network layer.
Link-Layer Address: The address used to identify an endpoint of some communication over a physical link. Typically, the Link-Layer address is an interface's Media Access Control (MAC) address.
Mobility Agent Either a home agent or a foreign agent.
Mobility Binding The association of a host home address with a care-of address, along with the remaining lifetime of that association.
Node: A host or a forwarding device, such as a router.
Tunnel: A path followed by a datagram while it is encapsulated. While it is encapsulated, a datagram is forwarded to a knowledgeable de-encapsulating agent, which de-encapsulates the datagram and then correctly delivers it to its ultimate destination. The tunnel source address is the address of the encapsulating agent and the tunnel destination address is the address of the decapsulating agent.
Virtual Network: A network with no physical instantiation beyond a node (e.g., router) (with a physical network interface on another network). The node (e.g., a home agent) generally advertises reachability to the virtual network using conventional routing protocols.
Visited Network: A network other than a mobile node's Home Network, to which the mobile node is currently connected.
If the mobile node (MN) 110 leaves its home network area, as indicated by element 110′, it may access the foreign network multicast system 130 via an access node, such as the access router 139. A wireless access link 138 is provided between the mobile node 110′ and the access node. The access router 139 may include a foreign agent (FA) 135.
Notice that for purposes of multicasting, a multicast group may have a rendezvous point 174 (or 124 or 134) through which multicast packets are disseminated. Each network multicast system may have one or more multicast designated router 122, 132, which are used as multicast access routers through which to send and receive multicast packets for any multicast group supported by the multicast routing system.
The present invention may involve allowing the mobile node 110′ to use foreign network multicasting while roaming (and therefore possibly changing access nodes) in a foreign network by allowing the mobile node 110′ to use a persistent address (e.g., the host home address). In one embodiment, the present invention is realized by modifying the techniques described in RFC 3220 to allow such a persistent address to be used (e.g., without failing reverse path forwarding tests). Exemplary devices and methods that may be employed to this end are now described in §§4.2 and 4.3 below.
The mobility facilities 210 may include mobile reachability operation(s) 212 (such as MIP for example) and forwarding operations 216. Basically, the reachability operation(s) can be used to generate a visitor list 214 that may include entries binding a persistent address (e.g., a home address of a mobile node) with a temporary address (e.g., a CCoA or CoA). The visitor list 214 may also include an indication of whether or not packets are to be broadcast from the home network. A foreign multicast policy 218 may be predetermined or may be used to determine a type of multicasting the visiting mobile node is to use. This can be used to police the state of the ‘B’ bit and also control the forwarding of multicast signaling and data packets to and from the MN.
The multicast facilities 220 may include multicast group management operation(s) (e.g., IGMP) 222, which may include designated router operation(s) 224 and foreign network multicast operations 226, and multicast forwarding operations 232, which may include a modified reverse path forwarding check operation 234. The multicast group management operation(s) 222 may be used to generate group information 228 which may associate a multicast group with receivers registered to that multicast group. (This presumes IP multicasting where senders needn't join multicast groups. Naturally, the concepts of the invention can be extended to instances where senders join multicast groups.) If a designated router operation(s) 224 is provided, it may generate forwarding information 230, such as (a part of) a dynamic delivery tree for example.
Preferably, home or foreign multicasting is a decision controlled by mobility facilities 210 in conjunction with the mobile node 110′ and the home agent 125, not by multicast facilities 220. The multicast facilities 220 in the foreign agent 135′ are purely for foreign multicast. Home multicast may be effected using MIP by tunneling signaling (e.g., IGMP) and data packets to and from the home agent (HA) in either a MN<--> HA tunnel, or MN<--> FA<--> HA tunnels. The access router multicast module does not “see” home multicast signaling since it is encapsulated into a unicast packet and routed via the FA. The mobility facilities 210 can also include configuration information (not shown) to enable or block foreign multicast as well as home multicast. Hybrid multicast operation(s) (not shown) may, for example, allow multicast packets to be sent (tunneled) to the HA, but received via the FA.
The mobility facilities 310 may includes mobile node reachability operation(s) 312, which may be used to generate reachability information 314, as well as forwarding operations 316 that can use such reachability information 314. A home and foreign multicast policy 318 may be predetermined, or used for determinations, especially in conjunction with reachability operations 312 and forwarding operations 316. The reachability information 314 may include a tunnel to a temporary address (e.g., a CoA or CCOA) bound to a persistent (e.g., HoA) address, as well as a broadcast indicator (e.g., a “B” bit).
The multicast facilities 320 may include a multicast group management operation(s) (e.g., IGMP) 322, which may include a designated router operation(s) 324, non-group member sender operation(s) 325, and home network multicast operations 326, and multicast forwarding operations 332, which may include a reverse path forwarding check operation 334. (Note that a modified RPF check is not needed in the home agent because the HoA source address will pass a normal RPF check when injected into the home multicast system from the home agent. This is because the HoA is a local source address at the home agent and will therefore be available within its forwarding or routing tables.) The multicast group management operation(s) 322 may be used to generate group information 328 which may associated a multicast group with receivers registered to that multicast group. (This presumes IP multicasting where senders needn't join multicast groups. Naturally, the concepts of the invention can be extended to instances where senders do join multicast groups.) If a designated router operation(s) 324 is provided, it may generate forwarding information 330, such as (a part of) a dynamic delivery tree for example.
The mobility facilities 410 may include mobile node reachability operation(s) 412, which may be used to generate reachability information 414, as well as forwarding operations 416 that can use such reachability information 414. A home/foreign network multicast policy 418 may be predetermined, or used for determinations, especially in conjunction with reachability 412 and forwarding 416 operations. The reachability information 414 may include a temporary address (e.g., a CoA or CCOA), as well as a home agent broadcast indicator (e.g., a “B” bit) (HA to MN tunnel) and a reverse tunneling indicator (e.g., an “R” bit).
The multicast facilities 420 may include multicast group join/leave operation(s) (e.g., IGMP) 422, which may include home network multicast operation(s) 424 and foreign network multicast operation(s) 426, and multicast send operations 432.
In addition to an IGMP process and information for the foreign network multicast system, for each HoA/HA pair assigned to the mobile node 110″ for which the MIP Registration sent to the HA has the B bit is set, and for which the MN receives IGMP Queries from that HA, the MN has an active home network multicast system. In addition, note that the multicast Send operation is different for home and foreign network multicast because the packet is sent unencapsulated for foreign multicast and encapsulated in home multicast, to either the FA or the HA.
The machine 1200 may be a host, server, router (or some other forwarding device) or a wireless communication device. The processor(s) 1210 may include a microprocessor, a network processor, and/or (e.g., custom) integrated circuit(s). In the exemplary router, the storage device(s) 1220 may include ROM, RAM, SDRAM, SRAM, SSRAM, DRAM, flash drive(s), hard disk drive(s), and/or flash cards. At least some of these storage device(s) 1220 may include program instructions. In a preferred embodiment, the methods of the present invention may be effected by a microprocessor executing stored program instructions (e.g., defining a part of a protocol module). At least a portion of the machine executable instructions may be stored (temporarily or more permanently) on the storage device(s) 1220 and/or may be received from an external source via an input interface unit 1230. Finally, in the exemplary router, the input/output interface unit(s) 1230, input device(s) 1232 and output device(s) 1234 may include interfaces to terminate communications links.
Exemplary methods that may be used to effect the foregoing operations are described in §4.3 below.
As indicated by decision block 630 and blocks 635 and 655, if foreign multicasting is selected, then the signaling message(s) (e.g., as packets) are sent towards the designated router, before the method 422′ is left via RETURN node 660. (See, e.g., message 1320a of
Referring back to decision block 630, if home multicasting is selected, then, referring to decision block 640, it may be determined whether or not multicast signaling is being reverse tunneled. Referring to decision block 640 and blocks 645 and 655, if the multicast signaling is being reverse tunneled, then the signaling messages (e.g., as packets) are encapsulated to the foreign agent from the persistent (e.g., HoA) address of the mobile node, and sent towards the IGMP Querier, before the method 422′ is left via RETURN node 660. (See, e.g., message 1320b of
Referring back to trigger event block 805, if a multicast packet is received from a mobile node, a modified reverse path forwarding check is performed. This is because the persistent address of the mobile node will not be a local address of the access router (e.g., in its unicast forwarding or routing tables). In this modified RPF check, it is determined if the multicast source address matches an address in the visitor list. As indicated by decision block 825 and block 815, if the modified RFP check fails, the multicast packet is dropped, before the method 232′ is left via RETURN node 870. If, on the hand, the modified RPF check passes, an instance (copy) of the multicast packet is forwarded to any “local” receivers that joined the multicast group as indicated by block 830. Then, at decision block 835, it is determined whether or not the multicast forwarding is to be foreign or hybrid. (Note that hybrid multicasting means that multicast packets are sent to the home agent (HA) for the home multicast system and received via the foreign agent (FA) and the foreign multicast system. If it is to be hybrid, an instance (copy) of the multicast packet is tunneled to the home agent of the mobile node (where the mobile node is a non-member sender), as indicated by block 865, before the method 232′ is left via RETURN node 870. (See, e.g., 1460 and 1465 of
Note that modified reverse path forwarding (RPF) checks can be performed in a number of ways. For example, in a first way, the source address is checked to see if it is a local address according to the unicast routing table, or is on the MIP visitor list, before the packet is multicast. In a second way, the source address is checked to see if it is on the visitor list. If so, an indicator is set to bypass the normal RPF multicast check when the packet is passed to the multicast forwarding engine; otherwise the normal RPF multicast check is performed. In a third way, “RPF-like” mobile IP filtering is performed in the multicast forwarding engine and it is determined whether or not the interface that the packet came in on is a wireless interface (or for a mobile service). If not, a normal RPF multicast check is performed. Otherwise, it is only checked to see if the source address is on the visitor list.
Finally, recall from
As can be appreciated from the foregoing, the present invention permits a mobile host to roam in a foreign network, with multiple access node handoffs, while permitting foreign network multicasting. Moreover, using the HoA as the source address for IGMP membership reports and multicast packets unifies, for both unicast and multicast, most of the host processing for both mobile and non-mobile hosts as the source addresses are now always the same.
The present application is a continuation of U.S. patent application Ser. No. 10/172,357, filed on Jun. 14, 2002 U.S. Pat. No. 7,339,903 which claims benefit to the filing date of: (i) provisional patent application Ser. No. 60/298,282, entitled “ENABLING THE MOBILE IP MULTICAST SOURCE ADDRESS TO BE THE HOME ADDRESS THROUGH CONFIGURATION AND/OR MODIFICATION TO PIM SPARSE-MODE MULTICAST ROUTING PROTOCOL”, filed on Jun. 14, 2001 and listing Alan O'Neill as the inventor; (ii) provisional patent application Ser. No. 60/301,069, entitled “METHODS AND APPARATUS FOR PERFORMING RSVP AGGREGATION”, filed on Jun. 26, 2001, and listing Alan O'Neill as the inventor; and (iii) provisional patent application Ser. No. 60/301,122, entitled “METHODS AND APPARATUS FOR SELECTIVE ROUTING AND FORWARDING SUPPORT FOR MOBILE HOSTS”, filed on Jun. 27, 2001 and listing Scott Corson, Alan O'Neill, Matthew Impet, Vincent Park and George Tsirtsis as the inventors, for any inventions disclosed in the manner provided by 35 U.S.C. §112, ¶1. Each of the above listed provisional and utility applications is expressly incorporated herein by reference. However, the invention is not intended to be limited by any statements in the provisional application(s). Rather, the provisional application(s) should be considered to describe exemplary embodiments of the invention.
Number | Name | Date | Kind |
---|---|---|---|
4679244 | Kawasaki et al. | Jul 1987 | A |
4833701 | Comroe et al. | May 1989 | A |
4901307 | Gilhousen et al. | Feb 1990 | A |
5056109 | Gilhousen et al. | Oct 1991 | A |
5095529 | Comroe et al. | Mar 1992 | A |
5128938 | Borras | Jul 1992 | A |
5200952 | Bernstein et al. | Apr 1993 | A |
5210787 | Hayes et al. | May 1993 | A |
5229992 | Jurkevich et al. | Jul 1993 | A |
5247516 | Bernstein et al. | Sep 1993 | A |
5251209 | Jurkevich et al. | Oct 1993 | A |
5267261 | Blakeney, II et al. | Nov 1993 | A |
5325332 | Tagaya | Jun 1994 | A |
5325362 | Aziz | Jun 1994 | A |
5325432 | Gardeck et al. | Jun 1994 | A |
5369781 | Comroe et al. | Nov 1994 | A |
5387905 | Grube et al. | Feb 1995 | A |
5420909 | Ng et al. | May 1995 | A |
5450405 | Maher et al. | Sep 1995 | A |
5461645 | Ishii | Oct 1995 | A |
5463617 | Grube et al. | Oct 1995 | A |
5465391 | Toyryla | Nov 1995 | A |
5473605 | Grube et al. | Dec 1995 | A |
5491835 | Sasuta et al. | Feb 1996 | A |
5511232 | O'Dea et al. | Apr 1996 | A |
5513381 | Sasuta | Apr 1996 | A |
5542108 | Sasuta | Jul 1996 | A |
5566366 | Russo et al. | Oct 1996 | A |
5572528 | Shuen | Nov 1996 | A |
5590396 | Henry | Dec 1996 | A |
5594948 | Talarmo et al. | Jan 1997 | A |
5625882 | Vook et al. | Apr 1997 | A |
5627882 | Chien et al. | May 1997 | A |
5634197 | Paavonen | May 1997 | A |
5806007 | Raith et al. | Sep 1998 | A |
5884196 | Lekven et al. | Mar 1999 | A |
5898922 | Reininghaus | Apr 1999 | A |
5901362 | Cheung et al. | May 1999 | A |
5903559 | Acharya et al. | May 1999 | A |
5987323 | Huotari | Nov 1999 | A |
6011969 | Vargas et al. | Jan 2000 | A |
6021123 | Mimura | Feb 2000 | A |
6021326 | Nguyen | Feb 2000 | A |
6055236 | Nessett et al. | Apr 2000 | A |
6078575 | Dommety et al. | Jun 2000 | A |
6092111 | Scivier et al. | Jul 2000 | A |
6134226 | Reed et al. | Oct 2000 | A |
6144671 | Perinpanathan et al. | Nov 2000 | A |
6160798 | Reed et al. | Dec 2000 | A |
6161008 | Lee et al. | Dec 2000 | A |
6195705 | Leung | Feb 2001 | B1 |
6225888 | Juopperi | May 2001 | B1 |
6240089 | Okanoue et al. | May 2001 | B1 |
6256300 | Ahmed et al. | Jul 2001 | B1 |
6275712 | Gray et al. | Aug 2001 | B1 |
6286052 | McCloghrie et al. | Sep 2001 | B1 |
6298058 | Maher et al. | Oct 2001 | B1 |
6308080 | Burt et al. | Oct 2001 | B1 |
6308267 | Gremmelmaier | Oct 2001 | B1 |
6353616 | Elwalid et al. | Mar 2002 | B1 |
6366561 | Bender | Apr 2002 | B1 |
6366577 | Donovan | Apr 2002 | B1 |
6385174 | Li | May 2002 | B1 |
6400703 | Park et al. | Jun 2002 | B1 |
6400722 | Chuah et al. | Jun 2002 | B1 |
6407988 | Agraharam et al. | Jun 2002 | B1 |
6425352 | Perrone | Jul 2002 | B2 |
6434134 | La Porta et al. | Aug 2002 | B1 |
6445922 | Hiller et al. | Sep 2002 | B1 |
6446127 | Schuster et al. | Sep 2002 | B1 |
6452915 | Jorgensen | Sep 2002 | B1 |
6466964 | Leung et al. | Oct 2002 | B1 |
6477150 | Maggenti et al. | Nov 2002 | B1 |
6487170 | Chen et al. | Nov 2002 | B1 |
6487407 | Goldberg et al. | Nov 2002 | B2 |
6487605 | Leung | Nov 2002 | B1 |
6496505 | La Porta et al. | Dec 2002 | B2 |
6498934 | Muller | Dec 2002 | B1 |
6505047 | Palkisto | Jan 2003 | B1 |
6510144 | Dommety et al. | Jan 2003 | B1 |
6515966 | Bardalai et al. | Feb 2003 | B1 |
6519254 | Chuah et al. | Feb 2003 | B1 |
6538989 | Carter et al. | Mar 2003 | B1 |
6539225 | Lee | Mar 2003 | B1 |
6546252 | Jetzek et al. | Apr 2003 | B1 |
6563919 | Aravamudhan et al. | May 2003 | B1 |
6567416 | Chuah | May 2003 | B1 |
6567664 | Bergenwall et al. | May 2003 | B1 |
6571095 | Koodli | May 2003 | B1 |
6571289 | Montenegro | May 2003 | B1 |
6578085 | Khalil et al. | Jun 2003 | B1 |
6584093 | Salama et al. | Jun 2003 | B1 |
6611506 | Huang et al. | Aug 2003 | B1 |
6611547 | Rauhala | Aug 2003 | B1 |
6615236 | Donovan et al. | Sep 2003 | B2 |
6631122 | Arunachalam et al. | Oct 2003 | B1 |
6636498 | Leung et al. | Oct 2003 | B1 |
6650901 | Schuster et al. | Nov 2003 | B1 |
6654363 | Li et al. | Nov 2003 | B1 |
6678735 | Orton et al. | Jan 2004 | B1 |
6680943 | Gibson et al. | Jan 2004 | B1 |
6687655 | Oosthoek et al. | Feb 2004 | B2 |
6690936 | Lundh | Feb 2004 | B1 |
6711147 | Barnes et al. | Mar 2004 | B1 |
6711172 | Li | Mar 2004 | B1 |
6738362 | Xu et al. | May 2004 | B1 |
6742036 | Das et al. | May 2004 | B1 |
6747961 | Ahmed et al. | Jun 2004 | B1 |
6763007 | La Porta et al. | Jul 2004 | B1 |
6765892 | Leung et al. | Jul 2004 | B1 |
6842462 | Ramjee et al. | Jan 2005 | B1 |
6853639 | Watanuki et al. | Feb 2005 | B1 |
6862622 | Jorgensen | Mar 2005 | B2 |
6876668 | Chawla et al. | Apr 2005 | B1 |
6904110 | Trans et al. | Jun 2005 | B2 |
6910068 | Zintel et al. | Jun 2005 | B2 |
6915325 | Lee et al. | Jul 2005 | B1 |
6937590 | Lee | Aug 2005 | B2 |
6937950 | Cragun et al. | Aug 2005 | B2 |
6963918 | Leung | Nov 2005 | B1 |
6970443 | Dynarski et al. | Nov 2005 | B2 |
6973057 | Forslow | Dec 2005 | B1 |
6999435 | Perras | Feb 2006 | B2 |
7000026 | Beshai et al. | Feb 2006 | B2 |
7002937 | Dispensa et al. | Feb 2006 | B1 |
7006472 | Immonen et al. | Feb 2006 | B1 |
7020082 | Bhagavath et al. | Mar 2006 | B2 |
7027400 | O'neill | Apr 2006 | B2 |
7080127 | Hickman et al. | Jul 2006 | B1 |
7099687 | Makela et al. | Aug 2006 | B1 |
7136388 | Friedrichs et al. | Nov 2006 | B2 |
7161929 | O'neill et al. | Jan 2007 | B1 |
7281043 | Davie | Oct 2007 | B1 |
7295608 | Reynolds et al. | Nov 2007 | B2 |
7339903 | O'neill | Mar 2008 | B2 |
7369522 | Soininen et al. | May 2008 | B1 |
7546376 | Widegren et al. | Jun 2009 | B2 |
20010027490 | Fodor et al. | Oct 2001 | A1 |
20010036164 | Kakemizu et al. | Nov 2001 | A1 |
20010041571 | Yuan et al. | Nov 2001 | A1 |
20010046223 | Malki et al. | Nov 2001 | A1 |
20020015396 | Jung | Feb 2002 | A1 |
20020018456 | Kakemizu et al. | Feb 2002 | A1 |
20020026527 | Das et al. | Feb 2002 | A1 |
20020068565 | Purnadi et al. | Jun 2002 | A1 |
20020071417 | Nakatsugawa et al. | Jun 2002 | A1 |
20020089958 | Feder et al. | Jul 2002 | A1 |
20020114469 | Faccin et al. | Aug 2002 | A1 |
20020136226 | Christoffel et al. | Sep 2002 | A1 |
20020147820 | Yokote | Oct 2002 | A1 |
20020161927 | Inoue et al. | Oct 2002 | A1 |
20020186679 | Nakatsugawa et al. | Dec 2002 | A1 |
20020191593 | O'Neill et al. | Dec 2002 | A1 |
20030012179 | Yano et al. | Jan 2003 | A1 |
20030016655 | Gwon | Jan 2003 | A1 |
20030051140 | Buddhikot et al. | Mar 2003 | A1 |
20030060199 | Khalil et al. | Mar 2003 | A1 |
20030117969 | Koo et al. | Jun 2003 | A1 |
20030137961 | Tsirtsis et al. | Jul 2003 | A1 |
20030137991 | Doshi et al. | Jul 2003 | A1 |
20030176188 | O'Neill | Sep 2003 | A1 |
20030228868 | Turanyi et al. | Dec 2003 | A1 |
20040185777 | Bryson | Sep 2004 | A1 |
20050129019 | Cheriton | Jun 2005 | A1 |
Number | Date | Country |
---|---|---|
1244261 | Jan 2000 | EP |
WO 9512297 | May 1995 | WO |
WO 9627993 | Sep 1996 | WO |
WO 9712475 | Apr 1997 | WO |
PCTUS9847302 | Oct 1998 | WO |
Number | Date | Country | |
---|---|---|---|
20080151808 A1 | Jun 2008 | US |
Number | Date | Country | |
---|---|---|---|
60298282 | Jun 2001 | US | |
60301069 | Jun 2001 | US | |
60301122 | Jun 2001 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 10172357 | Jun 2002 | US |
Child | 12041613 | US |