NETLMM Working Group Rajeev. Koodli
Internet-Draft Kuntal. Chowdhury
Intended status: Standards Track Starent Networks
Expires: April 17, 2010 October 14, 2009
Flow Handover for Proxy Mobile IPv6
draft-koodli-netext-flow-handover-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 17, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
With interface multihoming, Mobile Nodes are capable of simultaneous
attachment to multiple radio access networks. This enables a network
node such as the Local Mobility Anchor to distribute the application
Koodli & Chowdhury Expires April 17, 2010 [Page 1]
Internet-Draft Flow Handover October 2009
traffic to interfaces that can best serve them. This document
specifies a network-controlled protocol to handover application flows
from one interface to another. Such control could provide better
experience for end users and better traffic management for network
operators.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Flow Handover Request (FHRQ) . . . . . . . . . . . . . . . 6
4.2. Flow Handover Reply (FHRP) . . . . . . . . . . . . . . . . 7
4.3. Mobility Options . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. IPv6 Address/Prefix . . . . . . . . . . . . . . . . . 8
4.3.2. IPv4 Address . . . . . . . . . . . . . . . . . . . . . 8
4.3.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . 8
4.3.4. QoS Parameters . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Koodli & Chowdhury Expires April 17, 2010 [Page 2]
Internet-Draft Flow Handover October 2009
1. Introduction
Interface multihoming is becoming increasingly common. Mobile Nodes
are being equipped with multiple Wide Area Network (WAN) radios as
well as Local Area Network (LAN) radio (such as WiFi). In a Proxy
Mobile IPv6 domain [RFC5213], a single Local Mobility Anchor (LMA)
could support a Mobile Node (MN) which is simultaneously attached to
multiple Mobility Access Gateways (MAGs) through multiple interfaces.
The PMIP6 protocol provides the mobility support in such an
enviroment when a MN actually changes its network interfaces. This
document specifies a protocol between the LMA and a MAG to handover
one or more application flows from an interface to another even when
the MN does not physically switch its network interface.
Flow handover, in which a network entity induces handover for one or
more application flows, could provide better network experience for
end users by transparently moving an application flow to the network
that can best serve the particular application flow. Flow handover
could also enable a network operator to dynamically balance the load
appropriately depending on the availability of network capacity. For
example, the LMA may induce a handover for "www" application from
cellular radio to WiFi, while retaining the VoIP on the cellular
network.
This document assumes that handover control logic resides at the LMA;
however, the trigger for protocol could initiate from the MAG. The
LMA maintains appropriate policy profiles that describe the
applications and networks that best serve them. The LMA also has
access to MN-specific policy information. Details of such policy
profiles are beyond the scope of this document.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in this
document are to be interpreted as described in RFC 2119 [RFC2119].
The document uses the terminology specified in [RFC5213] and in
[RFC3775]. In addition, this document defines the following:
Flow Handover: Network-initiated handover of one or more
application flows from one network interface to another, without
necessarily requiring the change of network interface at the MN.
Flow Handover Request (FHRQ): A message sent by the LMA requesting
a MAG to establish forwarding for one or more application flows of
a MN.
Koodli & Chowdhury Expires April 17, 2010 [Page 3]
Internet-Draft Flow Handover October 2009
Flow Handover Reply (FHRP): A reply from the MAG to the LMA
containing the resolution of FHRQ message.
Source MAG (S-MAG): The Mobility Access Gateway where a MN
originates its application flow.
Target MAG (T-MAG): The Mobility Access Gateway to which the LMA
relocates one or more application flows (from the S-MAG).
3. Protocol
The protocol specified here assumes that a MN has simultaneous
connectivity with multiple networks which are anchored at the same
LMA. Hence, the LMA maintains multiple PMIP6 session bindings
corresponding to each of the attachments, containing unique IPv6 Home
Network Prefixes and/or IPv4 Home Addresses. A special case for the
protocol specified here is when the same HNP is used across multiple
interfaces; the behavior is the same as described in the following.
When a new application flow is initiated (e.g., either through out of
band signaling or through connection set up as in TCP) the LMA
verifies whether the application flow is "best-mapped" to interfaces
that could serve them. This verification could be based on the
application policy profiles (that could specify the priority ordering
of networks best-suited to support the applications) and the MN-
specific policy profiles (which are dependent on the subscription
records). Both application profiles and MN-specific profiles are
operator-configurable, and are not specified in this document. In
any case, if the application flows are already best-mapped to their
corresponding interfaces, the LMA does nothing. If not, this
verification serves as a flow handover trigger for further protocol
actions described in the following.
As a response to the flow handover trigger, the LMA constructs a Flow
Handover Request (FHRQ) message containing the MN-Identifier and a
flow tuple (including the IPv6 HNP/IPv4 HoA, transport protocol port
numbers and QoS parameters for uplink and downlink) to the target MAG
(T-MAG). Note that such a flow tuple is established on the source
MAG (S-MAG), and hence is likely to have HNP and IPv4 HoA different
from the ones allocated for the MN on the target MAG. The LMA sends
the FHRQ message to the T-MAG.
The T-MAG verifies that it can support the requested flow. It then
creates a Flow Forwarding Entry (FFE) that contains the parameters
provided by the LMA in the FHRQ message. The FFE is in addition to
Koodli & Chowdhury Expires April 17, 2010 [Page 4]
Internet-Draft Flow Handover October 2009
the Binding Update List Entry (BULE) that the MAG may have for the
MN. The FFE is used to forward packets for the specified flow only;
however, wildcard parameters may be used to identify a set of flows.
The flow forwarding is not permanent. For instance, the LMA may send
a FHRQ message with a request to terminate an existing FFE. Such a
message may be generated as a result of termination of an application
flow. The flow forwarding also has a default lifetime, upon the
expiry of which the forwarding reverts to the normal PMIP6-based
tunneling (involving the LMA and the source MAG). When flow
forwarding service ceases, the corresponding FFE entries MUST be
removed.
The T-MAG provides a resolution of the FHRQ processing in the Flow
Handover Reply (FHRP) message. This Mobility Header message includes
the MN-IDentifier and flow tuple (including the IPv6 HNP/IPv4 HoA,
transport protocol port numbers and QoS parameters for uplink and
downlink) as well as an appropriate Status code disposing the outcome
of FHRQ processing. Status code 0 indicates flow forwarding is
offered by the T-MAG. Any other value for Status code indicates the
reason for not offering the flow forwarding service.
When Status code in FHRP is 0, the LMA creates its own Flow
Forwarding Entry (FFE). The FFE over-rides the BCE for the
identified application flow(s). In other words, application traffic
matching the flow tuple is forwarded to T-MAG. Only the subset of
the application traffic that matches the flow parameters is forwarded
to T-MAG; the rest of the traffic is sent to S-MAG according to the
BCE.
At any point in time, the T-MAG may send an Unsolicited FHRP (U-FHRP)
message to indicate events such as FFE lifetime renewal or a MN
moving out of coverage. The LMA sends an FHRQ message to confirm the
renewal of FFE lifetime. When the event indicates a MN moving out of
coverage, the LMA sends FHRQ to cancel an existing flow forwarding
service. In any case, the T-MAG MUST wait for the FHRQ message to
confirm the corresponding action by the LMA before concluding on its
own. When flow forwarding service is cancelled, forwarding takes
place according to the normal PMIP6 tunneling.
The decision to handover the flow from one interface to another may
be conveyed to the MN using access-specific signaling. In the
absence of such signaling, the MN needs to be prepared to accept
packets on an interface other than the one which initiated the
application flow in the first place.
Koodli & Chowdhury Expires April 17, 2010 [Page 5]
Internet-Draft Flow Handover October 2009
4. Message Formats
4.1. Flow Handover Request (FHRQ)
The LMA sends an FHRQ message to a MAG to request flow handover to
one or more application flows of a MN.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|C| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Flow Handover Request (FHRQ) Message
Sequence Number: A monotonically increasing integer. Set by a
sending node in a request message, and used to match a reply to
the request.
'R' flag: Set to 0, indicates it is an FHRQ message.
'C' flag: When set to 1, indicates a request to cease flow
forwarding
Reserved: This field is unused. MUST be set zero.
Lifetime: The requested time in seconds for which the sender
wishes to have flow forwarding.
Mobility Options: MUST contain the MN-ID, followed by one or more
flow tuples. Each flow tuple consists of the following in the
specified order: [IP source address, IP destination address,
source port number, destination port number, QoS parameters for
uplink, QoS parameters for downlink].
Koodli & Chowdhury Expires April 17, 2010 [Page 6]
Internet-Draft Flow Handover October 2009
4.2. Flow Handover Reply (FHRP)
The MAG sends an FHRP message to the LMA as a response to the FHRQ
message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|U| Reserved | Status | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Flow Handover Reply (FHRP) Message
Sequence Number: A monotonically increasing integer. Set by a
sending node in a request message, and used to match a reply to
the request.
'R' flag: Set to 1, indicates it is an FHRP message.
'U' flag: When set to 1, the FHRP message is sent unsolicited.
The Lifetime field indicates a new requested value. Lifetime set
to zero indicates that the MN is no longer attached to the MAG.
The MAG MUST wait for the regular FHRQ message to confirm that the
request is acceptable to the LMA.
Reserved: This field is unused. MUST be set zero.
Status:
0: Success
1: Failure, unable to establish flow forwarding
Lifetime: The time in seconds for which the flow forwarding is
supported. Typically copied from the corresponding field in the
FHRQ message.
Koodli & Chowdhury Expires April 17, 2010 [Page 7]
Internet-Draft Flow Handover October 2009
Mobility Options: When Status code is 0, MUST contain the MN-ID
and flow tuples in the same order as in the FHRQ message.
4.3. Mobility Options
4.3.1. IPv6 Address/Prefix
This option is the same as the Home Network Prefix option specified
in [RFC5213]. An address is specified with Prefix Length set to 128
bits. This option is used as the source or destination IP address
field in the flow tuple.
4.3.2. IPv4 Address
This option is used for an IPv4 flow. It has an alignment
requirement of 4n.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv4 Address
4.3.3. Port Numbers
This option is part of the flow tuple, and has an alignment
requirement of 4n.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source port | destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Port Numbers
Koodli & Chowdhury Expires April 17, 2010 [Page 8]
Internet-Draft Flow Handover October 2009
4.3.4. QoS Parameters
A Per-Hop Behavior (PHB) [RFC3140] Class parameter is defined whose
format is the same as in [dime-qos]. New QoS parameters may be
defined in the future.
5. Security Considerations
The protocol specified in this document uses the same security
association between the LMA and the MAG to protect the FHRQ and FHRP
messages. No new security risks are identified. Support for
integrity protection using IPsec is required, but support for
confidentiality is not necessary.
6. IANA Considerations
The Flow Handover Request, described in Section 4.1 and the Flow
Handover Reply, described in Section 4.2 require a single Mobility
Header Type from the registry at
http://www.iana.org/assignments/mobility-parameters:
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3140] Black, D. and et. al., "Per Hop Behavior Identification
Codes", RFC 3140, June 2001.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[dime-qos]
Korhonen, J. and H. Tschofenig, "Quality of Service
Parameters for Usage with the AAA Framework", May 2008.
7.2. Informative References
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Koodli & Chowdhury Expires April 17, 2010 [Page 9]
Internet-Draft Flow Handover October 2009
Authors' Addresses
Rajeev Koodli
Starent Networks
USA
Email: rkoodli@starentnetworks.com
Kuntal Chowdhury
Starent Networks
USA
Email: kchowdhury@starentnetworks.com
Koodli & Chowdhury Expires April 17, 2010 [Page 10]