PMIP中多接口MN流切换 阅读摘要

草案地址：http://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-flowmob/

在PMIP域中，通过增加信令，让拥有几个接口的MN中的流可以在不同接口中切换

PMIPv6 allows a mobile node to connect to the same PMIPv6 domain through different interfaces.

 

In contrast to a typical handover where connectivity to a physical

medium is relinquished and then re-established, flow mobility assumes

a mobile node can have simultaneous access to more than one network.

In this specification, it is assumed that the local mobility anchor

is aware of the mobile node’s capabilities to have simultaneous

access to both access networks and it can handle the same or a

different set of prefixes on each access. How this is done is

outside the scope of this specification.

 

The MN makes the final IP flow mobility decision, and then

the LMA follows that decision and update its forwarding state

accordingly. Note that this does not prevent network initiated

mobility, the network still could trigger mobility on the MN side via out-of-band 

mechanisms (e.g., 3GPP/ANDSF sends updated routing policies to the MN).

 In a given scenario and mobile node, the decision on IP flow mobility MUST

 be taken either by the MN or the LMA, but not by both.

 

1.MN sharing a common set of prefixes on all MAGs.

If the local mobility anchor assigns a common prefix (or set of prefixes) to the different

 physical interfaces attached to the domain, then every MAG already has all the routing

 knowledge required to forward uplink or downlink packets, and the local mobility anchor 

does not need to send any kind of signaling in order to move flows across the different 

physical interfaces.

 

In this document a new Handoff Indicator (HI) value ("Attachment over a new interface

 sharing prefixes", value {IANA-1}) is defined, to allow the mobile access

gateway indicate to the local mobility anchor that the same set of prefixes 

MUST be assigned to the mobile node.

 

Initially, flow X goes through MAG1 and flow Y through MAG2. At certain point, flow Y can be 

moved to also go through MAG1. As shown in Figure 2, no signaling

between the local mobility anchor and the mobile access gateways is needed.

 

2.MN with different sets of prefixes on each MAG

In this case, additional signaling is required between the local mobility anchor and

 the mobile access gateway to enable relocating flows between the

different attachments, so the MAGs are aware of the prefixes for which the MN is going 

to receive traffic, and local routing entries are configured accordingly. Two different, 

but related, approaches are considered next.

 

Since the local mobility anchor cannot send a PBA message which has not been 

triggered in response to a received PBU message,the solution defined in this 

specification makes use of the Update Notifications for Proxy Mobile IPv6.

 

The trigger for the flow movement can be on the mobile node (e.g., by using layer-2 

signaling with the MAG) or on the network (e.g., based on congestion and

measurements).

 

第一种方案：If the flow is being moved from its default path (which is determined by the destination prefix) 

to a different one, the local mobility anchor constructs an Update Notification (UPN) message,

 of type (2) "UPDATE-SESSION-PARAMETERS" (NOTE from the Editor: a new Notification Reason value might be defined for

 just flow mobility purposes if it proves to be cleaner). This message includes a Home Network Prefix 

for each of the prefixes that requested to be provided with flow mobility support on the new MAG

 (note that these prefixes are not anchored by the target MAG,and therefore the MAG MUST

 NOT advertise Them on the MAG-MN link).

 

第二种方案：the MN obtains a combination of prefix(es) in use and new

prefix(es). Here, the mobile node is already attached to the PMIPv6-

Domain via MAG1. At a certain moment, the mobile node attaches a new

interface (if2) to MAG2. MAG2 sends a PBU which is then used by the

LMA to enable flow mobility. In this case, we consider that flows

are moved with a prefix granularity, meaning that flows are moved by

moving prefixes among the different MAGs the mobile node is attached

to. In this example, flow Y is bound to pref2::/64 and therefore the

flow can be moved by just binding pref2::/64 to MAG2. This is done

by including the prefix in the PBA message.

3.MN with combination of prefix(es) in use and new prefix(es) on each MAG

It requires flow mobility signaling to enable relocating flows for the new prefix(es) 

which are not shared across attachments.

The binding cache structure of the local mobility anchor is extended

to allow multiple proxy care of address (Proxy-CoA) registrations,

and support the mobile node use the same address (prefix) beyond a

single interface and mobile access gateway.

The LMA maintains multiple binding cache entries for an MN. The number of binding

cache entries for a mobile node is equal to the number of the MN’s interfaces attached to any MAGs.

 

Flow Mobility Cache

Each local mobility anchor MUST maintain a flow mobility cache (FMC)

as shown in Figure 8. The flow mobility cache is a conceptual list

of entries that is separate from the binding cache. This conceptual

list contains an entry for each of the registered flows.