草案地址: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.