HK1156178A - Handoffs in a hierarchical mobility label-based network - Google Patents

Description

Handover in a hierarchical mobility tag-based network

Background

In a mobile Internet Protocol (IP) network, a Mobile Node (MN) may enter a foreign subnet, discover a Foreign Agent (FA) node by listening for Internet Control Message Protocol (ICMP) messages, and register itself with the FA node and a Home Agent (HA) node. The FA node may comprise a router coupled to the subnet in which the MN is currently located, and the HA node may comprise a router coupled to the home subnet to which the MN is assigned.

After successful registration of the MN, remote nodes wishing to communicate with the MN can forward messages to the HA node. The HA node may encapsulate and tunnel the message to the FA node, which in turn may relay the message to the MN using the layer 2 network. In the opposite direction, messages from the MN can be sent directly to the remote node.

Drawings

FIG. 1 is a diagram of an exemplary network in which principles described herein may be implemented;

FIG. 2 is a block diagram of the exemplary network device of FIG. 1;

FIG. 3 is a functional block diagram of the exemplary network device of FIG. 2;

FIG. 4 illustrates a diagram of an exemplary Forwarding Information Base (FIB) of the network device of FIG. 3;

FIGS. 5A and 5B illustrate an internal update process and an external update process;

fig. 6 is a flow diagram of an exemplary process for an apparatus in a Label Switched Path (LSP) of fig. 1 when the exemplary mobile node of fig. 1 moves from a Radio Access Network (RAN) cell to another RAN cell in an area;

FIG. 7 illustrates the mobile node of FIG. 1 in communication with a Label Edge Router (LER) of FIG. 1 before and after a handoff;

FIG. 8 is a flow diagram of an exemplary process for updating the LSPs of FIG. 1 as the mobile node of FIG. 1 moves from area to area;

FIG. 9 illustrates the mobile node of FIG. 1 moving from one area to another in a region;

FIGS. 10A and 10B are flow diagrams of an exemplary process for updating the LSPs of FIG. 1 as the mobile node of FIG. 1 moves from one region to another;

FIG. 11 illustrates the mobile node of FIG. 1 moving from within one region to another region;

FIG. 12A is a flow diagram of an exemplary process for managing a zone Identifier (ID) in the mobile node of FIG. 1;

FIG. 12B is a flow diagram of an exemplary process for managing zone IDs in the LER of FIG. 1;

fig. 13A is a flow diagram of an exemplary process for managing zone IDs in the exemplary zone mobility route reflector (AMRR) of fig. 1; and

fig. 13B is a flow diagram of another exemplary process for managing area IDs at the AMRR of fig. 1.

Detailed Description

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention.

The term "edge router" as used herein may refer to a router located at an edge of a network. The term "mobility label" as used herein may refer to a label for multiprotocol label switching (MPLS) that assigns a mobile node or mobile router.

Fig. 1 is a diagram of an exemplary network 100 in which principles described herein may be implemented. As shown, network 100 may include a network 102 and a hierarchical Mobility Label Based Network (MLBN) 104. Network 102 may include the internet, an intranet, a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a cellular network, the Public Switched Telephone Network (PSTN), an ad hoc network, any other network, or a combination of one or more networks.

As further shown, hierarchical MLBN 104 may include mobile nodes 106-1 and 106-2 (collectively referred to herein as "mobile nodes 106" and individually referred to as "mobile nodes 106-x"), Label Edge Routers (LERs) 108-1 through 108-4 (collectively referred to herein as "LER 108" and individually referred to as "LER 108-x"), layer 2(L2) breakout networks 110-1 through 110-4 (collectively referred to herein as "L2 breakout network 110" and individually referred to as "L2 breakout network 110-x"), regional LERs (ALERs) 112-2 and 112-2 (collectively referred to herein as "ALERs 112" and individually referred to as "ALERs 112-x"), regional mobility routing reflectors (AMRRs) 114-1 and 114-2 (collectively referred to herein as "AMRR 114" and individually referred to as "AMRR 114-x"), and Internet Protocol (IP)/multiprotocol label switching (MPLS) ) A network 116. Depending on the implementation, the hierarchical MLBN 104 may include additional, fewer, or different components than those illustrated in fig. 1. For example, the hierarchical MLBN 104 may include additional mobile nodes, L2 grooming networks, ALERs, and so forth.

Mobile node 106-x may comprise any one of the following devices: a mobile router; a mobile computer; an electronic notebook or laptop computer; mobile phones, such as radiotelephones; an IP telephone; a Personal Communication System (PCS) terminal; personal Digital Assistants (PDAs); a pager; and/or any other type of communication device that may participate in wireless or wired network communications. In fig. 1, mobile node 106-1 may communicate with mobile node 106-2 via network elements (e.g., LERs 108, ale 112, etc.) in hierarchical MLBN 104.

The LERs 108-x may include equipment (e.g., edge routers, gateways, switches, etc.) that provide for ingress to the hierarchical MLBN 104 and/or egress from the hierarchical MLBN 104. LERs 108-x may provide signaling and/or forwarding functions associated with edge routers of the MPLS network. Additionally, LERs 108-x may be associated with geographic area 118-x and may provide communication services known as Mobile Support Function (MSF) to mobile nodes 106 within area 118-x. For example, LER 108-1 may provide an MSF to mobile node 106-1 while mobile node 106-1 is located within area 118-1.

The L2 breakout network 110-x may include one or more Radio Access Networks (RANs). L2 grooming network 110-x may aggregate signals from one or more wireless access points and may send the aggregated signals to LERs 108-x. For example, the L2 breakout network 110-1 may aggregate (aggregate) signals from wireless access points in the area 118-1 and may then send them to the LER 108-1.

Ale 112-x may include a device (e.g., an edge router, gateway, switch, etc.) for performing label edge router functions on behalf of LERs 108. For example, ALER 112-1 may represent LERs 108-1 and 108-2 to perform LER functions. The ALER 112-x, which performs the label edge routing function for LERs 108, may be referred to as a "converging" LER 108. In FIG. 1, for example, ALER 112-2 may pool LERs 108-3 and LERs 108-4. In aggregating one or more LERs 108, ALERs 112-x may perform signaling functions (e.g., exchange routing information), forwarding functions (e.g., relaying packets to/from LERs 108), and MSFs.

AMRR 114-x may include devices (e.g., reflectors) that peer with the ale 106, LER 108, and other AMRRs 114. AMRR 114-x may receive routing information from a peer and distribute the routing information to other peers in network 100. When AMRR 114-x communicates the same routing information that AMRR 114-x has received, it can be said that AMRR 114-x "reflects" the routing information.

In some implementations, AMRR 114-x may distribute or reflect routing information based on demand following an explicit request from a peer. In these embodiments, AMRR 114-x may not forward the packet. In other embodiments, the functionality of AMRR 114-x may be included in ALER 112-x. Such an implementation may avoid signaling between the AMRRs 114 and/or other devices while increasing the processing load on the ale 112.

IP/MPLS network 116 may include devices and/or systems that provide for the routing/switching of packets based on a routing identifier and/or IP address, which may be referred to as a label.

The areas 118-1 through 118-4 (collectively referred to herein as "areas 118" and individually referred to herein as "areas 118-x") may comprise geographic areas or physical areas. Each area 118-x may include RAN cells, each of which may be associated with a particular RAN.

As shown in fig. 1, the ale 112-x may cover a geographic region referred to as a mobility region or simply a region, which may include a union of the areas covered by LERs 108 aggregated by the ale 112. For example, ALER 112-1 may correspond to region 112-1, region 122-1 may include regions 118-1 and 118-2, and ALER 112-2 may correspond to region 122-2, and region 122-2 may include regions 118-3 and 118-4. In addition, each ALER 112-x may correspond to an AMRR 114-x, which AMRR 114-x may cover the same area covered by the corresponding ALER 112-x. For example, ALERs 112-1 and 112-2 may correspond to AMRRs 114-1 and 114-2, respectively. Additionally, AMRR 114-1 and 114-2 may cover regions 122-1 and 122-2, respectively. Region 122-x (e.g., region 122-1) and the network devices covering region 122-x (e.g., ALER 112-1 and AMRR 114-1) may be associated with an identifier (e.g., region ID) that uniquely identifies region 122-x.

In fig. 1, mobile node 106-x may perform a search for devices/routers that provide an MSF when mobile node 106-x moves to a particular geographic location, as will be described in more detail below. Mobile node 106-x may register itself with LER 108-x if it is assumed that LER 108-x provides MSF and mobile node 106-x is able to locate LER 108-x.

Once registration is complete, the LER 108-x may signal routing information for the mobile node 106-x to other devices in the hierarchical MLBN 104 based on a routing protocol. More specifically, LER 108 may exchange an IP address and mobility label associated with mobile node 106-x with ale 112 and AMRR 114, and ale 112 and AMRR 114 may exchange routing information with each other. Once the signaling is complete, the mobile node 106-x may communicate with one or more mobile nodes through the hierarchical MLBN 104.

The hierarchical MLBN 104 may provide scalability and efficiency in mobile communications. In the case of LERs 108 and AMRRs 114 where the ale 112 aggregates the reflected signaling information, the LERs 108 may not be fully-efficient-fit (mesh), and thus, may not exchange as many signaling messages as, for example, some non-hierarchical networks (e.g., mobile Internet Protocol (IP) networks) when establishing routes between mobile nodes 106.

In certain cases, LSP 120 may be updated during the occurrence of a switchover. The term "handoff" as used herein may refer to transferring an ongoing communication session from one network to another. The handover may occur during the following situations: when mobile node 106-1 moves within area 118-1, when mobile node 106-1 moves from moving within area 118-1 to a different area 118-x within the same region, or when mobile node 106-1 moves from region 122-1 to another region 122-x.

During a switchover, because each LSP 120-x may be relatively independent of other LSPs 120, when a particular LSP 120-x is modified due to the switchover, it may not be necessary to use the routing/path information to update the nodes involved in establishing other LSPs 120. This may allow the hierarchy MLBN 104 to further reduce the number of signaling messages used to modify LSPs and, thus, may enable the hierarchy MLBN 104 to be scalable and efficient.

FIG. 2 is a block diagram of a network device 200, where network device 200 may correspond to LER 108-x, ALER 112-x, and/or AMRR 114-x. As shown, network device 200 may include a processor 202, a memory 204, line interfaces 206 and 208, an interconnect 210, and a communication path 212. In different embodiments, network device 200 may include additional, fewer, or different components than those illustrated in fig. 2. For example, in one embodiment, network device 200 may include additional line interfaces.

Processor 202 may include one or more processors, microprocessors, and/or processing logic optimized for networking and communication. Processor 202 may process packets and/or network path related information.

Memory 204 may include static memory, such as Read Only Memory (ROM), dynamic memory, such as Random Access Memory (RAM), and/or on-board cache for storing data and machine-readable instructions. In some implementations, the memory 204 may also include storage devices such as hard disks, as well as other types of storage devices.

The line interfaces 206 and 208 may include components for receiving incoming packets from devices and/or elements in the hierarchy MLBN 104 and components for transmitting packets to other devices/elements in the hierarchy MLBN 104. Interconnect 210 may include a switch for passing packets from line interface 206 to line interface 208, and vice versa. Examples of interconnect 210 may include a communications bus or a switch fabric. Communication path 212 may provide an interface through which components of network device 200 may communicate with one another.

Fig. 3 is a functional block diagram of an exemplary network device 200. As shown, network device 200 may include forwarding logic 302, routing logic 304, and Mobility Support Function (MSF) logic 306. Depending on the embodiment, network device 200 may include fewer, additional, or different functional components than those illustrated in fig. 3. For example, if network device 200 is implemented as AMRR 114-x, network device 200 may not necessarily include forwarding logic 302.

The forwarding logic 302 may include hardware and/or software for routing packets through the hierarchical MLBN 104 to its destination devices. In the hierarchical MLBN 104, the network routes followed by packets as a result of being forwarded by the forwarding logic 302 in the various routers may be referred to as Label Switched Paths (LSPs). To route packets along an LSP, forwarding logic 302 may direct the packet to the appropriate output port on the line interface of network device 200 based on the packet header.

In addition to forwarding packets, the forwarding logic 302 may perform various processes on packet headers according to its primary router being implemented as LER 108-x, ALER 112-x, and/or a Label Switch Router (LSR) (not shown). If the primary router is implemented as a LER 108-x, the forwarding logic 302 may convert packets entering the hierarchical MLBN 104 into MPLS packets by adding an MPLS header to the packet and/or an MPLS label (e.g., mobility label) identifying the mobile node registered at the originating LER 108-x. Instead, the forwarding logic 302 may translate the MPLS packet exiting the hierarchical MLBN network 106 by stripping its MPLS header, which includes an outer label and a mobility label.

If the primary router operates as an LSR or ale 112-x, the forwarding logic 302 may perform operations on the MPLS header (e.g., mobility label) of the received packet. The operations may include: creating another MPLS label and inserting it after the original MPLS label, swapping the MPLS label with another MPLS label, and/or removing the MPLS label and/or MPLS header. Because the outermost MPLS label in the MPLS header may assign a next hop router, operations affecting that label may also modify the identity and LSP of the next hop router.

Routing logic 304 may include hardware and/or software for communicating with other routers to collect and store routing information. Routing logic 304 may force a particular set of procedures to transmit routing messages (e.g., Label Distribution Protocol (LDP) messages, constraint-based routing LDP messages, Multiprotocol (MP) Border Gateway Protocol (BGP) messages, etc.). Through the exchange of routing messages, network device 200 may manage routing information.

In managing routing information, the routing logic 304 may provide a function that may include an inter-domain control plane that overlaps with the MPLS control plane of the hierarchical MLBN 104. The inter-domain control plane may be responsible for inter-domain network distribution and/or withdrawal of MPLS labels (e.g., mobility labels) assigned to mobile nodes. The distribution of MPLS labels may establish/remove network routes/paths (e.g., LSPs) within the hierarchical MLBN 104.

In providing inter-domain control plane functionality, routing logic 304 may employ inter-domain routing/signaling protocols to exchange messages with other devices such as LERs 108-x, ALERs 112-x, and AMRRs 114-x. For example, routing logic 304 may use MP-BGP to propagate mobility labels from AMRR 114-x to other AMRRs 114.

MSF logic 306 may include hardware and/or software to support mobile node 106-x. MSF logic 306 may allow network device 200 (e.g., mobile node 106-x) to discover another device (e.g., another network device 200) that includes MSF logic 306 and register mobile node 106-x at the other device. Mobile node 106-x may initiate discovery by sending a layer 2 multicast discovery signal or solicitation (solicitation) message. After discovering another network device 200 having MSF logic 306, mobile node 106-x may register itself with another network device 200 by sending a message string to another network device 200. The message may convey various networking parameters such as an identifier of mobile node 106-x, an IP address, a priority of transport service, a zone ID, and so forth.

MSF logic 306 may associate/disassociate the IP address or prefix of mobile node 106-x with the mobility label. For example, MSF logic 306 may associate and disassociate (e.g., bind/unbind) the mobility tag with an identifier of a line interface (e.g., line interface 208) via which the packet from mobile node 106-1 was received, an IP address of mobile node 106-1, and/or a prefix of a range of IP addresses of mobile node 106-x. The association may include information that may be specific to layer 2 (e.g., layer 2 header information) in addition to layer 3 information (e.g., IP address).

The MSF logic 306 may participate in propagating routing information for the mobile node 106-x through the interdomain routers. In one embodiment, the MSF logic 306 may employ the routing logic 304, which in turn the routing logic 304 may employ MP-BGP to propagate routing information.

In the foregoing, network device 200 may exchange and manage routing information for mobile node 106 via routing logic 304 and MSF logic 306. The network device 200 may store routing information for the mobile node in a Forwarding Information Base (FIB).

Fig. 4 illustrates an example FIB 402 that may be included and/or managed (e.g., in memory 204) by the network appliance 200. FIB 402 may include one or more FIB records, one of which is shown in fig. 4 as FIB record 404. When a packet arrives at network device 200 (e.g., ale 112-x), network device 200 may retrieve FIB record 404 by matching one or more fields in FIB record 404 with a portion of the MPLS header of the packet. Also, the network appliance 200 may forward the packet using information provided in the retrieved FIB record 404.

As shown in fig. 4, FIB record 404 may include a mobile prefix field 406, an original router Identifier (ID) field 408, an inside top (in top) label field 410, a local mobility label field 412, a current mobility label field 414, an outside top (out top) label field 416, and an output interface field 418. According to this embodiment, FIB record 404 may include fewer, additional, or different fields than those illustrated in fig. 4.

The mobile prefix field 406 may include an address prefix (e.g., "10.1.1.1/32") that may be associated with a Forwarding Equivalence Class (FEC). When a packet arrives at the network device 200 and the packet belongs to the FEC specified by the mobile prefix field 406 in the FIB record 404, the network device 200 may forward the packet according to the FIB record 404, as described further below.

The original router ID field 408 may include an identifier associated with the edge router from which the packet may have been sent. For example, the original router ID field 408 may include a value (e.g., "20.1.1.12") that provides an address of an edge router from which mobility binding updates for the mobile prefix may have been sent.

The inner top label field 410 may include the top or outermost MPLS label of the packet. For example, the inner top label field 410 may include a value (e.g., "16") associated with the top or outermost MPLS label of the packet.

Local mobility tag field 412 may include a mobility tag. For example, local mobility tag field 412 may include a value (e.g., "216") associated with the mobility tag. To retrieve the FIB record 404 in the FIB 402, the network appliance 200 may match the mobility label in the packet to the value of the local mobility label field 412.

Current mobility label field 414 may include a mobility label that may replace the mobility label on the packet as the packet enters a new LSP at network device 20. For example, current mobility tag field 414 may include a value (e.g., "116") associated with an alternate mobility tag. In general, a mobility label on a packet may override another mobility label when the packet enters or exits an LSP, such as LSP 120-1, LSP 120-2, or LSP 120-3, at an edge router (e.g., LER 108-1, ALER 112-1, etc.) at the beginning or end of the LSP.

The outer top label field 416 may include a label that may replace the top label of the packet by the forwarding logic 302. For example, the outer top label field 416 may include a value (e.g., "17") associated with the exchanged label.

The external interface field 418 may include the name of the line interface via which the packet may exit the network device 200. For example, the external interface field 418 may include a value (e.g., "GIG 1/0/3") that provides an address for the line interface.

In FIB record 404, an inner top label field 410 and an outer top label field 416 may contain MPLS labels that may be associated with routers (e.g., LERs 108, ale 112, etc.). The local mobility label field 412 and the current mobility label field 414 may contain mobility labels that may have been used in signaling routing information for the mobile node 106 and used to forward packets to/from the mobile node 106.

The above paragraphs describe system elements that may be related to devices and/or components in the hierarchical MLBN 104. Fig. 5A-10B illustrate or illustrate example processes that may be performed by one or more of these devices and/or components. This process may be related to modifying and/or updating LSP 120 and sending packets through LSP 120.

Fig. 5A and 5B illustrate exemplary processes, which are also referred to herein as "internal update" processes and "external update" processes. As described below, the internal update process and the external update process may be performed within the exemplary processes in fig. 6, 7, and/or 8. Internal and external update processes may occur when the apparatus 200 initiates an update in routing information at a network device of the hierarchical MLBN 104. The update may be required to establish the LSP and accommodate route changes that occur as a result of switching mobile node 106-x between different RANs or as a result of terminating a communication session between mobile nodes 106.

As shown in FIG. 5A, LER 108-1 may initiate an internal update procedure by sending an internal update message 502 to AMRR 114-1. The internal update message 502 may include a mobility binding (e.g., an association between a mobility label and the mobile node 106-x, a router ID of the LER 118-x, a zone ID, etc.). After receiving internal update message 502, AMRR 114-1 may perform an update on its routing information base and may issue internal update message 504 to ALER 112-1. The internal update message 504 may include the same or similar information as the internal update message 502.

In response to internal update message 504, ALER 112-1 may update its routing/forwarding information base (e.g., FIB 402) and may send external update message 506 to AMRR 114-1. External update message 506 may include an identifier of ale 112-1 and a mobility tag, referred to as a local mobility tag. For devices covering areas/regions outside of region 122-1, the local mobility label may be used as a proxy label that represents the original mobility label in region 122-1. For example, assume that the mobility label for mobile node 106-1 is "24". If the local mobility label is "36" at AMRR 114-1, then local mobility label "36" may serve as a proxy for label "24" for AMRR 114-2 or ALER 112-2.

Fig. 5B illustrates an external update process. As shown, the external update process may begin with AMRR 114-1 issuing an external update message 512 to other AMRRs, such as AMRR 114-2. External update message 512 may include the mobility binding created by ale 112-1. Mobility bindings, in turn, may include information local to ALER 112-1, such as a router ID of ALER 112-1 (e.g., ALER 112-x that initiated the external update) and a mobility label (e.g., a local mobility label) assigned by ALER 112-1 to mobile node 106-1.

Upon receiving external update message 512, AMRR 114-2 may provide the mobility binding included in external update message 512 to ale 112-2 via external update message 514. The external update message 514 may include the same or similar information as the external update message 512.

In response to external update message 514, ALER 112-2 may update its routing/forwarding information base (e.g., FIB 402) and may send internal update message 516 to AMRR 114-2. Internal update message 516 may include an identifier of ale 112-2 and a local mobility tag.

In FIG. 5A, the internal update process is illustrated as starting at LER 108-1 and propagating towards AMRR 114-1 and then ALER 112-1. In general, the internal update process starting at the LER for a given area can be propagated to the AMRRs and ALERs covering the area that includes the area. Similarly, in FIG. 5B, the external update process is illustrated as beginning at AMRR 114-1 and propagating to AMRR 114-2 and ALER 112-2. In general, an external update process starting at an AMRR for a region may be propagated to other AMRRs and ALERs that do not cover the region.

Internal and/or external updates may occur when a device in the hierarchical MLBN 104 establishes an LSP 120 and/or updates the LSP 120. In certain cases, LSP 120 may be updated during the occurrence of a switchover. In the hierarchical MLBN 104, handovers may occur during the following cases: when mobile node 106-1 moves within area 118-1, when mobile node 106-1 moves from within area 118-1 to a different area 118-x within the same region, or when mobile node 106-1 moves from region 122-1 to another region 122-x. Fig. 6-11 show or illustrate exemplary procedures for updating LSP 120 when a switchover occurs during each of the above-described scenarios.

Fig. 6 is a flow diagram of an exemplary process 600 for updating devices in LSP 120 when mobile node 106-1 moves from within a RAN cell in area 118-1 to another RAN cell in area 118-1. The update may support service continuity during a handover of mobile node 106-1 from the RAN to another RAN during the movement.

Process 600 may begin with a mobile node moving from a RAN cell within an area to another RAN cell within the area (block 602). As shown in fig. 7, mobile node 106-1 may move from one RAN cell to another RAN cell. Mobile node 106-1 may be within RAN cell 702 at one time. At the next time, mobile node 106-1 may move into RAN cell 704 as indicated by arrow 706. When the mobile node 106-1 moves from the RAN cell 702 to the RAN cell 704, the RAN in the L2 breakout network 110-1 may complete a radio handover of the mobile node 106-1 to another RAN L2 breakout network.

An association between the mobility tag and an identifier of a line interface via which the packet from the mobile node is received may be updated (block 604). After a radio handover, MSF logic 306 in LER 108-1 may complete the handover by looking up the association between the mobility tag, the line interface ID and the IP address (see description of MSF logic 306), and by updating the association using the identifier of the line interface via which the packet arrived after the handover. Alternatively, MSF logic 306 may update the association based on a keep-alive message from mobile node 106-1. If mobile node 106-1 moves from the original RAN cell into a RAN cell with different layer 2 characteristics prior to the handover, MSF logic 306 may update the association with the new layer 2 information.

Fig. 7 illustrates mobile node 106-1 communicating with LER 108-1 before and after a handoff. As shown, prior to handoff, mobile node 106-1 may communicate with LER 108-1 via line interface 708-1. After the handoff, mobile node 106-1 may communicate with LER 108-1 via line interface 708-2. The switch from line interface 708-1 to line interface 708-2 is indicated by arrow 710.

After the handoff, mobile node 106-1 may continue to send packets addressed to mobile node 106-2 to LER 108-1. If there are no such packets to send, mobile node 106-1 may send a keep-alive message to the virtual link layer address of LER 108-1 (see description of block 602). The keep-alive message may carry the zone ID for zone 122-1. Once LER 108-1 has updated the information for mobile node 106-1, packets sent from mobile node 106-1 to mobile node 106-1 may follow LSP 120.

In some embodiments, to maintain traffic continuity between mobile node 106-1 and mobile node 106-2 during handoff, packets for mobile node 106-1 may be replicated at LER 108-1 and may be sent via two line interfaces on LER 108-1. In such a case, LER 108-1 may temporarily maintain a registration record with both layer 3 interface IDs until no activity is detected on any of the layer 3 interfaces.

Fig. 8 is a flow diagram of an exemplary process 800 for updating LSP 120 when mobile node 106-1 moves from within area 118-1 to within area 118-2 in region 122-1. It may be assumed that mobile node 106-1 is in communication with mobile node 106-2.

Process 800 may begin with moving a mobile node from within a first RAN cell in a first area to within a second RAN cell in a second area (block 802). As shown in fig. 9, mobile node 106-1 may move from within region 122-1 within region 118-1 to within region 118-2. Mobile node 106-1 may be within RAN cell 902 before mobile node 106-1 moves. Mobile node 106-1 may then move into RAN cell 904 as indicated by arrow 906.

A new registration may be initiated at the first LER (block 804). Upon arrival in area 118-2, mobile node 106-1 may discover LER 108-2 and may register itself with MSF logic 306 in LER 108-2. During registration, LER 108-2 may receive the zone ID from mobile node 106-1. In some embodiments, if the same RAN technology is used in areas 902 and 904, mobile node 106-1 may use the same virtual addressing scheme through the network when using virtual addresses in Virtual Router Redundancy Protocol (VRRP) or Hot Standby Routing Protocol (HSRP).

A new mobility binding may be sent to update the AMRR (block 806). When mobile node 106-1 registers with LER 108-2, LER 108-2 may create a new mobility binding based on the zone ID received from mobile node 106-1 (e.g., the zone ID associated with the previous zone in which the mobile node was located) and the new mobility label. Additionally, LER 108-2 may send a zone ID for the zone including area 118-2 to mobile node 106-1 and may send a new mobility binding to update AMRR 114-1.

Mobility bindings may be propagated from the AMRR to peer AMRR (block 808). Upon receiving the mobility binding, the AMRR 114-1 may compare the zone ID of the mobility binding to the last recorded zone ID of the mobile node 106-1. If the locale ID in the mobility binding and the last recorded locale ID are the same, AMRR 114-1 may determine that AMRR 114-1 already has an LRL associated with mobile node 106-1. Otherwise, AMRR 114-1 may send a request for an LRL to other AMRRs. Because mobile node 106-1 moves within region 122-1, the mobility-bound region ID and the last recorded region ID of mobile node 106-1 may be the same, and AMRR 114-1 may conclude that AMRR 114-1 already has an LRL. Additionally, the AMRR 114-1 may reflect the new mobility binding to its peers, which may include ALER 112-1 and LER 108-1, to install LSP 908 in the hierarchical MLBN 104.

The FIB record may be updated (block 810). As a result of AMRR 114-1 reflecting the new mobility binding, ALER 112-1 may exchange, within its mobility binding and FIB record 404, a router ID associated with the termination point of LSP 120-1 (e.g., the router ID of LER 108-1) and a router ID associated with the termination point of LSP 908 (e.g., the router ID of LER 108-2), as shown in FIG. 9. For example, ALER 112-1 may replace the value of original router ID field 408 with the router ID of LER 108-2. In addition, ALER 112-1 may update the inner top label field 410, the current mobility label field 414, the outer top label field 416, and the outer interface ID field 418. Because ALER 112-1 has already assigned a local mobility label, ALER 112-1 may not perform an external update after receiving a new mobility binding.

A packet may be received at the second LER (block 812). For example, mobile node 106-2 may groom network 110-3 to send packets to LER 108-3 via L2. The packet may be routed to the first ale via the first LSP (block 814). For example, LER 108-2 may relay packets to ale 112-2 via LSP 120-3.

The packet may be routed to the second ALER via the second LSP (block 816). For example, ALER 112-2 may relay packets from LER 108-2 to ALER 112-1 via LSP 120-2.

The packet may be routed to the first LER via the third LSP (block 818). ALER 112-1 may pop out an outer tag (e.g., a tag associated with ALER 112-1) when ALER 112-1 receives a packet from ALER 112-2. Additionally, ale 112-1 may read the mobility label of the packet and locate FIB record 404, the local mobility label field 412 value of which FIB record 404 matches the mobility label of the packet. Once FIB record 404 is found, ale 112-1 may replace the mobility label of the packet with the value of the current mobility label field 414 of FIB record 404. Ale 112-1 may push the value of outer top label field 416 onto the packet's label stack and send the packet to LER 108-2.

A packet may be received at a first LER (block 820). When LER 108-2 receives the packet, LER 108-2 may forward the packet to mobile node 106-1.

In process 800, packets may be delivered over LSP 120-1 while maintaining traffic continuity between mobile node 106-1 and mobile node 106-2 while updating the mobility binding of mobile node 106-1 in a different device. When the ALER 112-1 is updated with a mobility binding (e.g., updated current mobility label field 414, inner top label field 410, original router ID field 408, outer top label field 416 of FIB record 404, etc.), the packet may be delivered over LSP 908 instead of LSP 120-1. In various embodiments, for traffic continuity, packets directed to mobile node 106-1 may be replicated at ALER 112-1 and sent over LSP 908 and LSP 120-1 until one of the LSPs no longer carries any packets from mobile node 106-1.

Fig. 10A and 10B illustrate a flow chart of an exemplary process 1000 for updating LSP 120 as mobile node 106-1 moves from within region 122-1 to within another region. Assume that mobile node 106-1 is in communication with mobile node 106-2.

Process 1000 may begin by moving a first mobile node from within a first region to within a second region (block 1002). As shown in fig. 11, mobile node 106-1 may move from within region 122-1 to within region 1112. In addition to some of the devices shown in fig. 1, network 100 (shown in fig. 11) may include LER 1102, L2 grooming network 1104, ale 1106, and AMRR 1108. LER 1102, L2 grooming network 1104, ale 1106 and AMRR 1108 may be arranged and may operate similarly to the devices of region 122-1 (or region 122-2) in fig. 1. For simplicity, many of the elements shown in FIG. 1 are omitted from FIG. 11.

Returning to fig. 10A, a new registration for the first LER may be initiated (block 1004). For example, as shown in fig. 11, upon arrival in area 1110 within region 1112, mobile node 106-1 may discover LER 1102 and may register itself with MSF logic 306 in LER 1102. During registration, LER 1102 may receive a zone ID from zone 122-1 of mobile node 106-1 (e.g., a zone in which mobile node 106-1 has been previously located within zone 1112) and send the zone ID of zone 1112 to mobile node 106-1.

The first AMRR may be updated with the new mobility binding (block 1006). When mobile node 106-1 registers with LER 1102, LER 1102 may create a new mobility binding based on the new mobility label of mobile node 106-1 and the zone ID received from mobile node 106-1. LER 1102 may cause a new mobility binding to update AMRR 1108.

Mobility bindings may be propagated to peer AMRRs (block 1008). After receiving the mobility binding, if no record for mobile node 106-1 exists, AMRR 1108 may compare the mobility binding's zone ID with the last recorded zone ID of mobile node 106-1 and/or its own zone ID. If the zone ID in the mobility binding and the compared zone ID are different, AMRR 1108 may decide to send a request for the LRL to the other AMRR. In process 1000, because mobile node 106-1 moved from within region 122-1 to within region 1112, the mobility-bound region ID and the compared region ID of mobile node 106-1 may be different, and AMRR 1108 may determine to send a request for an LRL to AMRR 114-2. In addition, the AMRR 1108 may replace the zone ID in the mobility binding with its own zone ID.

The first ale may be updated with the mobility binding (block 1010). For example, as shown in fig. 11, AMRR 1108 may update ale 1106 with mobility binding via an internal update. Ale 1106 may assign a local mobility label and create FIB record 404 based on the mobility binding.

The first AMRR may be updated with the mobility binding via an external update (block 11012). As shown in fig. 11, to update AMRR 1108, ale 1106 may provide an external update message that includes the IP address of mobile node 106-1, the local mobility label assigned by ale 1106 at block 1010, and the router ID of ale 1106.

A request for an LRL may be sent from the first AMRR (block 1014). For example, along with the request for the LRL, AMRR 1108 may send a mobility binding that may include the IP address of mobile node 106-1, the local mobility label assigned by ale 1106, the router ID of ale 1108, and the zone ID of zone 1110.

A reply to the request for the LRL may be sent from the second AMRR (block 1016). In response to the request for the LRL by AMRR 1108, AMRR 114-1 may send a reply that may be received at AMRR 1108. The reply may include an LRL, which may include the locale ID for the locale 122-2. AMRR 1108 may update its LRL based on the reply.

As shown in fig. 10B, the second ale may be updated with the mobility binding (block 1018). To update ale 112-2, AMRR 114-1 may send an external update message that includes the mobility binding received from AMRR 1108. In response to the external update message, the ale 112-1 may update the original router ID field 408, the inner top label field 410, the current mobility label field 414, and the outer top label field 416 of the FIB record 404 in its own FIB 402. Because a local mobility label already exists for mobile node 106-1, ale 112-1 may not initiate an internal update based on an external update message.

A mobility binding may be sent to the third AMRR (block 1020). AMRR 1108 may send the mobility binding for mobile node 106-1 to AMRR 114-2. The mobility binding may provide a local mobility label assigned by the ale 1106 and a router ID identifying the originating router from which the packet may arrive (e.g., router termination/start LSP 1116).

A mobility binding may be sent from the third AMRR to the second ale (block 1022). When AMRR 114-2 receives a mobility binding from AMRR 114-1, AMRR 114-2 may reflect the mobility binding to ale 112-2.

The FIB record in the second ale may be updated (block 1024). When ALER 112-2 receives a mobility binding from AMRR 114-2, ALER 112-2 may insert a new value into current mobility label field 414 and original router ID field 408 in FIB record 404 with the value obtained from the mobility binding. Additionally, ALER 112-2 may update the value of a tag field (e.g., inner top tag field 410) in FIB record 404.

A packet may be received at the second LER from the second mobile node (block 1026). When LER 108-2 receives a packet, LER 108-3 may insert a label stack in the packet. A label stack has been constructed at LER 108-3 during the previous exchange of packets between mobile node 106-1 and mobile node 106-2.

A packet may be received at a second ALER (block 1028). When ale 112-2 receives a packet from LER 108-3, ale 112-2 may pop the top label and may look up FIB record 404 whose local mobility label field 412 value matches the mobility label of the packet. After retrieving FIB record 404, ale 112-2 may exchange the mobility label of the packet with the value of the current mobility label field 414 in FIB record 404. Additionally, ALER 112-2 may push the value of the outer top label field 416 of FIB record 404 onto the packet's label stack.

The packet may be forwarded to the first mobile node (block 1030). Once the label stack is set in the packet, ale 112-2 may forward the packet to mobile node 106-1. The packet forwarding process may involve performing a series of actions for forwarding packets through LSPs 1116 and 1114.

In process 1000, traffic continuity between mobile node 106-1 and mobile node 106-2 may be maintained while mobility bindings are updated in different devices. More specifically, after LSP 1114 is established but before LSP 1116 is established, packets from mobile node 106-2 may be routed to ALER 112-1 via LSP 120-2. ALER 112-1, in turn, may reroute packets to ALER 1106 via a temporary LSP (not shown in FIG. 11). Once LSP 1116 is established, packets may be delivered to mobile node 106-1 via LSPs 120-3, 1116 and 1114.

Fig. 6, 8, 10A, and 10B illustrate or illustrate example processes 600, 800, and 1000. Part of processes 600, 800, and/or 1000 may involve managing locale IDs. Fig. 12A-13B illustrate flow diagrams of exemplary processes for managing zone IDs within one or more of processes 600, 800, and 1000.

Fig. 12A is a flow diagram of a process 1200 for managing a zone ID at mobile node 106-x. Process 1200 may begin by determining whether mobile node 106-x is in an active state (block 1202).

If mobile node 106-x is in the active state (block 1202-YES), mobile node 106-x may use the active zone ID (block 1204). The activation region ID may comprise a predetermined ID that mobile node 106-1 may communicate to LER 108-x upon its activation. The starting region ID may not include the ID of the region in which the mobile node 106-x is located or any other region ID used in the hierarchical MLBN.

If mobile node 106-x is not in the activated state (block 1202-no), mobile node 106-x may use the zone ID of the last visited zone (block 1206). That is, in interaction with LER 108-x, mobile node 106-x may provide LER 108-x with the zone ID of the last visited zone.

Fig. 12B is a flow diagram of a process 1210 for managing zone IDs at LER 108-x. Process 1210 may begin by determining at LER 108-x whether the geographic ID received from mobile node 106-x is a starting geographic ID (block 1212). If the received geographic ID is a starting geographic ID (block 1212 — YES), the geographic ID may be updated at mobile node 106-x (block 1214). LER 108-x may send to mobile node 106-x a region ID of the region in which the region associated with LER 108-x is located. Mobile node 106-x may update the zone ID in the memory of mobile node 106-x and may use the zone ID in subsequent communications with LER 108-x.

If the received locale ID is not a start locale ID (block 1212 — NO), the locale ID may be sent from the LER 108-x to the AMRR 114-x (block 1216). For example, LER 108-x may send a region ID to AMRR 114-x during an internal update.

FIG. 13A is a flow diagram of a process 1300 for managing a locale ID at an AMRR 114-x. Process 1300 may begin by determining whether a zone ID is received in an internal update message (block 1302). If a zone ID is received in the external update message (block 1304-NO), the zone ID may be stored as part of a record associated with the mobility binding (block 1304). If a locale ID is received in the internal message (block 1304-YES), a determination may be made as to whether the received locale ID is equal to the locale ID of AMRR 114-x (block 1306).

If the zone ID is equal to the zone ID of AMRR 114-x (block 1306-YES), AMRR 114-x may update ALER 112-x with the received mobility binding (block 1308). Otherwise (block 1306-No), the LRL may be obtained at AMRR 114-x (block 1310). To obtain the LRL, AMRR 114-x may send a request for the LRL to the AMRR associated with the locale ID in the received internal update message.

The AMRR 114-x may replace the region ID in the internal update message with its own region ID (block 1312). In addition, AMRR 114-x may send an internal update message to ALER 112-x. The peer AMRR may be updated according to the LRL (block 1314). When AMRR 114-x receives an LRL from an AMRR to which AMRR-x sends a request for an LRL, AMRR 114-x may send a mobility binding to update the peer AMRR corresponding to the locale ID listed in the LRL.

FIG. 13B is a flow diagram of another process 1320 for managing zone IDs at AMRR 114-x. Process 1320 may begin with the receipt of a request for a mobility binding from a peer AMRR at AMRR 114-x (block 1322).

It may be determined whether the zone ID of the requested mobility binding is the zone ID of the AMRR 114-x itself (block 1324). When AMRR 114-x receives the request for a mobility binding, AMRR 114-x may compare the zone ID of the requested mobility binding at AMRR 114-x with the zone ID of AMRR 114-x. If the zone IDs are the same (block 1324 — yes), the AMRR 114-x may transmit a positive reply (e.g., a reply with a mobility binding). Otherwise (block 1324 — no), a negative reply (e.g., a reply that does not include a mobility binding) may be sent to the peer AMRR (block 1328).

The above paragraphs describe exemplary procedures that may be performed by one or more devices in the hierarchical MLBN 104 to establish, modify, remove, and/or use LSPs. Because the apparatus illustrated in fig. 1 and/or 11 may be capable of distributing processing load across many apparatuses, the exemplary process in the hierarchical MLBN 104 may be adjustable. In part, such capabilities in the hierarchical MLBN 104 may be attributed to the AMRRs 114, each AMRR 114 may serve as a control plane node at the center of the coverage area. As described above, in acting as a control plane node, AMRR 114-x may reflect internal updates from LER 108 to ale 112-x, external updates from outside the mobility zone to ale 112-x, process internal updates from ale 112-x, and generate mobility bindings and LRL requests/replies.

The ability to distribute the processing load may also be attributed to the segmentation of the LSPs. For example, if there is a change in LSP 120-x due to a switchover, it may be necessary to update the devices in hierarchical MLBN 104 with information only to the extent necessary to modify LSP 120 affected by the change. For example, in FIG. 11, slave LSP 908 may replace LSP 120-1 when mobile node 106-1 moves from area 118-1 to area 118-2. LSPs 120-2 and 120-3 may not be affected and the devices in hierarchical MLBN 104 may not be updated with unnecessary information (e.g., information related to LSPs 120-2 and 120-3).

For each of LSPs 120 that is relatively independent of other LSPs 120, packets traversing LSP 120-x may carry local mobility labels that are unaffected by the assignment of mobility labels in other LSPs 120. That is, the local mobility label may be made to fall within a (scope) LSP segment (e.g., LSP 120-1, 120-2, etc.).

The foregoing description of the embodiments provides illustration, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the teachings.

For example, while a series of blocks has been described with respect to the exemplary processes illustrated in fig. 6, 8, 10A, 10B, 12A, 12B, 13A, and 13B, the order of the blocks may be modified in other implementations. Additionally, non-dependent blocks may represent acts that may be performed in parallel with other blocks.

It should be apparent that aspects described herein may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement aspects does not limit the invention. Thus, the operation and behavior of the aspects were described without reference to the specific software code — it being understood that software and control hardware could be designed to implement the aspects based on the description herein.

In addition, certain portions of the embodiments have been described as "logic" that performs one or more functions. This logic may include hardware, such as a processor, an application specific integrated circuit, or a field programmable gate array; software or a combination of hardware and software.

Even though specific combinations of features are described in the claims and/or disclosed in the specification, these combinations are not intended to limit the invention. Indeed, a plurality of these features may be combined in the manner specifically described in the claims and/or specifically disclosed in the specification.

No element, act, or instruction used in the present application should be construed as critical or essential to the embodiments described herein unless explicitly described as such. Also, as used herein, the article "a" is intended to include one or more items. When an item is desired, the words "a" or similar language is used. Moreover, the phrase "based on" is intended to mean "based, at least in part, on" unless explicitly described otherwise.

Claims (22)

1. A method, comprising:

establishing a communication path between the mobile node and the first label edge router;

establishing a first label switched path between the first label edge router and a first zone label edge router;

establishing a second label switched path between the second label edge router and the second region label edge router;

establishing a third label switched path between the first zone label edge router and the second zone label edge router;

establishing communication between the mobile node and a corresponding node over the first label switched path, the second label switched path and the third label switched path; and

maintaining communications between the mobile node and the corresponding node as the mobile node moves from one physical location to another physical location.

2. The method of claim 1, wherein maintaining the communication comprises:

performing a handover when the mobile node moves from within a first cell to within a second single cell, the first cell and the second cell both being in an area covered by the first label edge router.

3. The method of claim 2, wherein performing a handover comprises:

upon completion of a layer 2 handover of the mobile node, updating, at the first label edge router, an identifier of a line interface via which packets from the mobile node are received.

4. The method of claim 1, wherein maintaining the communication comprises:

performing a handover when the mobile node moves from within a first cell in a first area to within a second cell in a second area, the first area and the second area both being in a region covered by the first region label edge router.

5. The method of claim 4, wherein performing a handover comprises:

establishing a fourth label switching path between a third label edge router covering the second area and the first zone label edge router, wherein the first zone label edge router converges the first label edge router and the third label edge router.

6. The method of claim 5, wherein establishing a fourth label switched path comprises:

registering the mobile node at the third label edge router;

creating a new mobility binding for the mobile node at the third label edge router; and

updating the first zone label edge router with the new mobility binding from the third label edge router via an internal update.

7. The method of claim 6, further comprising:

passing packets from the first area label edge router to the mobile node over the first label switched path after registering the mobile node at the third label edge router and before updating the first area label edge router with the new mobility binding via the internal update.

8. The method of claim 1, wherein maintaining the communication comprises:

performing a handover when the mobile node moves from within a first region covered by the first region label edge router to within a second region covered by a third region label edge router.

9. The method of claim 8, wherein performing a handover comprises:

registering the mobile node at a third label edge router;

establishing a fourth label switched path between the third label edge router and the third zone label edge router; and

establishing a fifth label switched path between the third zone label edge router and the second zone label edge router.

10. The method of claim 9, wherein registering the mobile node at a third label edge router comprises:

receiving, at the third label edge router from the mobile node, a region identifier associated with a previous region in which the mobile node was located.

11. The method of claim 9, wherein establishing a fourth label switched path comprises:

updating the third zone label edge router with the new mobility binding created at the third label edge router.

12. The method of claim 9, further comprising:

establishing a temporary label switched path between the first zone label edge router and the third zone label edge router after establishing the fourth label switched path and before establishing the fifth label switched path; and

routing packets from the corresponding node to the mobile node via the second label switched path, the third label switched path, the temporary label switched path, and the fourth label switched path until the fifth label switched path is established.

13. The method of claim 9, wherein establishing a fifth label switched path comprises:

sending a new mobility binding from the third zone label edge router to a first route reflector;

obtaining a list of one or more route reflectors to be updated by the first route reflector; and

propagating the mobility binding from the first route reflector to the one or more route reflectors, each of the one or more route reflectors updating a corresponding zone label edge router.

14. The method of claim 13, wherein obtaining a list of one or more route reflectors comprises:

comparing, at the first routing reflector, a region identifier associated with the first routing reflector to a region identifier associated with the first region; and

sending a request to a second routing reflector for a last requester list when a zone identifier associated with the first routing reflector and a zone identifier associated with the first zone are different, wherein the zone identifier of the second routing reflector is the same as the zone identifier associated with the first zone, the last requester list including a list of zone identifiers associated with routing reflectors requesting the mobility binding from the second routing reflector.

15. The method of claim 9, further comprising:

receiving, at a first routing reflector, a request for a mobility binding from a second routing reflector; and

sending the mobility binding from the first routing reflector to the second routing reflector when the request includes a zone identifier equivalent to a zone identifier associated with the first routing reflector.

16. A system, comprising:

a first label edge router covering a first area, the first label edge router configured to:

registers the mobile node, and

updating an identifier of a line card via which packets are received from the mobile node in a registration record when the mobile node moves from one cell within the first area to another cell in the first area;

a second label edge router;

a first zone label edge router configured to:

aggregating the first label edge router; and is

Establishing a first label switched path between the first zone label edge router and the first label edge router; and

a second region label edge router configured to:

aggregating the second label edge router,

establishing a second label switched path between the second region label edge router and the second label edge router; and is

Establishing a third label switched path between the second zone label edge router and the first zone label edge router.

17. The system of claim 16, further comprising:

a third label edge router covering a second area and configured to:

registering the mobile node when the mobile node moves from one cell in the first area to another cell in the second area, and

notifying the first zone label edge router to establish a fourth label switched path between a third label edge router and the first zone label edge router.

18. The system of claim 16, further comprising:

a third label edge router configured to:

registering the mobile node when the mobile node moves from the first area to a second area covered by the third label edge router, and

sending an update message to the route reflector; and

a third zone label edge router configured to:

aggregating the third label edge router,

receiving the update message reflected by the route reflector,

establishing a fourth label switched path between the third label edge router and the third zone label edge router in response to the update message, and

establishing a fifth label switched path between the third zone label edge router and the second zone label edge router.

19. The system of claim 16, further comprising:

a route reflector associated with the first zone label edge router, the second zone label edge router, and the third label edge router, each route reflector configured to:

the corresponding zone label edge routers and other route reflectors are updated.

20. An apparatus, comprising:

one or more processors configured to:

the aggregated label edge router is a router that is,

receiving an update message reflected by a route reflector;

establishing a first label switched path between the label edge router and the device in response to the update message, an

A second label switched path is established between the device and another regional label edge router.

21. The device of claim 20, wherein the label edge router is configured to:

registering a mobile node at the label edge router; and is

Establishing a third label switched path between the label edge router and the device.

22. The device of claim 20, wherein the one or more processors are further configured to:

transmitting packets over a temporary label switched path between the device and another label edge router, the temporary label switched path being created after the first label switched path is established.