The following abbreviations and terms are herewith defined, at least some of which are referred to within the following description of the state of the art and the present invention.
3GPP 3rd Generation Partnership Project
ACL Access Control List
BFD Bidirectional Forwarding Detection
CS Circuit Switch
DA Destination Address
ICMP Internet Control Message Protocol
IMS IP Multimedia Subsystem
IM-MGW IP Multimedia Media Gateway Function
IP Internet Protocol
IPLx IP Level x
IPv4 IP version 4
IPv6 IP version 6
ISO International Organization for Standardization
LSP Label Switch Path
MGW Media Gateway
MPLS Multi-Protocol Label Switching
MSCS Mobile-Services Switching Center
NHR Next Hop Router
NUD Network Unreachability Detection
OSI Open System Interconnect
RFC Request for Comment
SA Source Address
TS Technical Specification
TTL Time To Live
Next Hop Router (NHR): The first router in the path from the host to the destination network.
IMS Network—IPv4 and IPv6
The IP Multimedia Subsystem (IMS) originally specified the use of the new IP version 6 (IPv6) technology and later allowed the legacy IP version 4 (IPv4), but the intent is to move forward with IPv6 communications. Hence, the network providers are requiring IPv6 interfaces with their IMS networks. However, the access nodes from the previous non-IMS technologies, e.g.:                Call Server, e.g., Mobile-Services Switching Center (MSCS)        Media Gateway (MGW)may or may not support native IPv6, and often do not. Thus, the CS's MSCS is having capabilities shown as MGCF added so it can interface with the IMS network. Likewise, the CS's MGW is having capabilities shown as IM MGW added so it can support the IMS Mn and Mb interfaces. FIG. 1 (PRIOR ART) is a diagram that illustrates the logical interfaces CS 102a and 102b respectively between the IMS network's IMS-MGW 104 and MGCF 106 and the CS network's MGW 108 and MSCS 110—this diagram is part of TS 23.228 3GPP; TS Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 11), 2011-12 (the contents of which are incorporated herein by reference). In this case, IMS components, such as the Serving-Call Session Control Functions (S-CSCF) 112 and the Media Resource Function Processor (MRFP) 114 respectively communicate with the MGCF 106 and the IMS-MGW 104 using the IPv4 and/or IPv6 (preferred) protocols. These IP capable host devices—S-CSCF 112/MGCF 106 and MRFP 114/IMS-MGW 104—will communicate with each other over an IP capable network infrastructure composed of IP routers which are not shown in FIG. 1 because they are associated with physical connections rather than logical connections.        
The IMS-MGW 104 and the MGCF 106 both require IPv4 and IPv6 capabilities and so that these devices can utilize the existing direct-connected IPv4 infrastructure they both implement an IPv4 to IPv6 transition technique known as tunneling. FIG. 2 (PRIOR ART) illustrates the IMS-MGW 104 and MGCF 106 which function as hosts interacting with their next hop routers 202 and 204 which are associated with the IMS subsystem IPv6 206 utilizing tunneling where IPv6 is tunneled over IPv4 so that the existing host IPv4 infrastructure does not change and the IPv6 is managed at the host's application end point. The next hop routers 202 and 204 are part of the aforementioned IP network infrastructure. The next hop routers 202 and 204 are capable of tunneling over IPv4 the native IPv6 traffic between the IMS components—S-CSCF 112/MGCF 106 and MRFP 114/IMS-MGW 104.
The Internet Protocol (IP) may utilize tunneling techniques to transport information for various reasons:                Security        IPv4 to IPv6 Transition        IPv6 to IPv4 TransitionPacket Encapsulation        
FIG. 3 (PRIOR ART) illustrates how tunneling is realized by encapsulating a packet 300 with its original IP header 302 and data 304 within a new IP header 306 to form an encapsulated packet 308. The IP headers 302 and 306 may be any combination of IPv4 or IPv6. For instance, the original IP header 302 is an IPv6 IP header and the new IP header 306 is an IPv4 IP header, or the original IP header 302 is an IPv4 IP header and the new IP header 306 is an IPv6 IP header, or the original IP header 302 is an IPv4 IP header and the new IP header 306 is an IPv4 IP header, or the original IP header 302 is an IPv6 IP header and the new IP header 306 is an IPv6 IP header
Tunnel Endpoints
FIG. 4 (PRIOR ART) illustrates a tunnel 400 (which includes the encapsulated packet 308) with two tunnel end points 402a and 402b each represented by an IP address associated with each IP layer. For example, an IPv6 over IPv4 tunnel 400 would have both an IPv6 address (IP Level 2) 404a and 404b and an IPv4 address (IP Level 1) 406a and 406b at each tunnel endpoint 402a and 402b. In particular, the tunnel endpoint 402a would have an IP address L2a 404a and an IP address L1a 406a while the tunnel endpoint 404b would have IP address L2b 404b and IP address L1b 406b. The IP addresses 406a and 406b are used to route between a host (e.g., MGCF 106) and a router (e.g., router 204) as they are used in the outside new IP header 306 And, the IP addresses 404a and 404b are used to route between the host and the far end device (see FIG. 6). The word “level” is used herein to distinguish the different stacked IP headers and is not to be confused with the term “layer” which is used in the International Organization for Standardization (ISO) Open System Interconnect (OSI) 7-layer Reference Model.
Tunnels vs. Links
Tunnels may exist between a host and routers (host-routers) or between the routers themselves (router-router). An algorithm for tunneling IPv6 over IPv4 between a host-and-routers and between routers-and-routers is described in RFC 4213 “Basic Transition Mechanisms for IPv6 Hosts and Routers” October 2005 (the contents of which are incorporated by reference herein). The IP protocol operates at the Network Layer, or Layer 3, of the ISO OSI Reference Model. This implies that the tunnel operation is also at Layer 3.
As shown in FIG. 5 (PRIOR ART), the host 500 when connecting to next hop routers 5021 and 5022 (only two shown) usually utilizes redundant paths 5061 and 5062 to the adjacent routers 5021 and 5022 to ensure connectivity even if there is a single point of failure (see also FIG. 2). The host 500 has an algorithm 510 which determines which link or links are utilized when communicating via its adjacent routers 5021 and 5022 to the far end device 504. This algorithm 510 will therefore determine the physical path(s) 5061 and 5062 used for communicating via the adjacent router(s) 5021 and 5022 to the far end device 504. Note: the physical paths 5061 and 5062 along with their associated data link protocol operate at the Data Link (Layer 2) and the Physical (Layer 1) of the OSI model and are therefore segregated from the tunneling which operates at Layer 3.
The host 500 to survive a single point of failure needs a minimum of two paths 5061 and 5062 connected to the two routers 5021 and 5022. Although more paths and routers may be utilized, the two-path algorithm is generally deployed. The adjacent routers 5021 and 5022 generally have an inter-router link 512 (the link inter-connecting each of the adjacent routers 5021 and 5022) to provide alternative path routing for both ingress traffic and egress traffic with respect to the host 500 and the network (far end device 504).
As shown in FIG. 6 (PRIOR ART), there is a host-router configuration in which the host 500 inter-connects to its adjacent or next hop router 5021 (for example) using one network protocol “A”, e.g., IPv4, while an application 602 on the host 500 needs to communicate with another application 606 on the far end device 504 using a different network protocol B, e.g., IPv6. Thus, to allow the host 500 to communicate with the far end device 504 there is established a host-router tunnel 6041 which uses network protocol “A” with network protocol “B” embedded therein.
As shown in FIG. 7 (PRIOR ART), if a host-router tunnel is utilized, then the host 500 will need a tunnel 6041, 6042 . . . 604n to each of its adjacent routers 5021, 5022 . . . 502n. Note: that a tunnel, and its traffic, between two end points may utilize different physical paths over time.
Tunneling and Routing
Host-to-Router Direction
In the host 500 to router 5021 (for example) packet flow direction, the original IP header contains:                Destination IP Address—Far end device's address        Source IP Address—Host's address        
The host 500 will encapsulate the original IP packet with a new IP header. The new IP header contains:                Destination IP Address—Router's Tunnel Endpoint Address        Source IP Address—Host's Tunnel Endpoint Address        
Once the packet is removed from the tunnel by the router 5021, the external IP header is removed and the original IP header is then used to route the packet.
Router-to-Host Direction
In the router 5021 (for example) to host 500 packet flow direction, the original IP header contains:                Destination IP Address—Host address        Source IP Address—Originator of the IP packet (far end device 504)        
The router 5021 will encapsulate the original packet with the tunnel header. The new IP header contains:                Destination IP Address—Host's Tunnel Endpoint Address        Source IP Address—Router's Tunnel Endpoint AddressTunnel Integrity Check        
Tunnels 6041, 6042, 604n (for example) are effectively managed by software and are therefore subject to failure. The host 500 (for example) could check the tunnel's integrity by running heartbeat messages at the tunnel level. Examples of such a heartbeat mechanism 608 include:
Bidirectional Forwarding Detection (BFD):
                RFC 5880—Bidirectional Forwarding Detection (BFD), Standard, June 2010.        RFC 5881—Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop), June 2010.        RFC 5883—Bidirectional Forwarding Detection (BFD) for Multihop Paths, June 2010.        RFC 5884—Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs), June 2010.        RFC 5882—Generic Application of Bidirectional Forwarding Detection (BFD), June 2010.Internet Control Message Protocol (ICMP):        RFC 792—Internet Control Message Protocol, September 1981.        RFC 4443—Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, March 2006.Network Unreachability Detection (NUD):        RFC 4861—Neighbor Discovery for IP version 6 (IPv6), September 2007.Note: The contents of these eight documents are hereby incorporated by reference herein.Time To Live (TTL) and Hop Limit        
There is a field in the IPv4 header, Time To Live (TTL), and in the IPv6 header, Hop Limit, which ensures that a packet caught in a routing loop will eventually be discarded. Plus, when a router 5021, 5022 . . . 502n (for example) receives an IP packet, the router 502k, 5022 . . . 502n decrements the TTL/Hop Limit field. If the result is zero (0), then the packet is discarded.
Problems
The host 500 (for example) which has multiple tunnels 6041, 6042 . . . 604n one to each of its adjunct routers 502k, 5022 . . . 502n must know the operational status of each and every tunnel 6041, 6042 . . . 604n. Furthermore, the tunnels 6041, 6042 . . . 604n which are utilized for communications would depend on the Layer 1/2 active path(s) 5061, 5062 . . . 506n to gain the most efficient routing. This implies that the host's Layer 3 function would need to be cognizant of the Layer 1/2 functions which is not the intent of the ISO OSI Reference Model. This situation can be problematic because some tunnels 6041, 6042 . . . 604n may be intended to be active while others are standby, while some links 5061, 5062 . . . 506n may be intended to be active while other links are standby. And, if the active tunnels 6041, 6042 . . . 604n and the active links 5061, 5062 . . . 506n do not align, then less efficient routing will occur. Referring to FIGS. 8A-8D (PRIOR ART), there are shown two cases—FIGS. 8A and 8B—which lead to efficient routing and two cases—FIGS. 8C and 8D—which lead to less efficient routing. In FIG. 8A, the host 500 and routers 5021 and 5022 have active tunnels 6041 and 6042 and active links 5061 and 5062 which are synchronized resulting in efficient routing of packets. In FIG. 8B, the host 500 and router 5021 have an active tunnel 6041 and an active link 5061 which are synchronized resulting in efficient routing of packets. In FIG. 8C, the host 500 has an active tunnel 6041 and an active link 5061 with router 5021 and the host 500 has an active tunnel 802 but no active link with router 5022 which results in less efficient routing. In FIG. 8C, assuming that one tunnel is all that is needed by the host 500, then the active tunnel 6041 associated with the active link 8001 should be used which avoids the extra hop between the pair of routers 5021 and 5022. In FIG. 8D, the host 500 has an active link 5061 but no active tunnel with router 5021 and at the same time the host 500 has an active tunnel 802 but no active link with router 5022 which results in less efficient routing. Accordingly, there is a need to address these shortcomings and other shortcoming associated with the state-of-the-art.