Internet DRAFT - draft-koodli-policy-multiaccess-mobility
draft-koodli-policy-multiaccess-mobility
NETEXT Working Group Rajeev. Koodli
Internet-Draft Cisco Systems
Intended status: Standards Track Kuntal. Chowdhury
Expires: September 3, 2012 March 2, 2012
Policy Signaling for Multi-access Mobility
draft-koodli-policy-multiaccess-mobility-02.txt
Abstract
The mobile nodes are increasingly capable of simultaneous multi-radio
connectivity. This allows them to be attached to the Internet
through multiple access technologies at the same time. With such
multi-access, the mobile node (MN) can make use of the best-available
access technology for a particular application at any given time.
And, the network may be able to balance the flow of traffic across
the available access technologies. The Mobile IPv6 flow binding work
provides a mechanism for the MN to signal the Home Agent to balance
the flows based on the MN'e needs. This document specifies a simple
protocol for a mobile IP gateway (such as a Mobile IP Home Agent or a
Proxy Mobile IP Local Mobility Anchor) to signal the MN of gateway's
policy for traffic treatment across access technologies. Based on
the response and the prevailing network conditions, the gateway then
balances the traffic.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 3, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Koodli & Chowdhury Expires September 3, 2012 [Page 1]
Internet-Draft Policy-Based Mobility March 2012
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Flow Policy Request (FPRQ) . . . . . . . . . . . . . . . . 6
4.2. Flow Policy Reply (FPRP) . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Koodli & Chowdhury Expires September 3, 2012 [Page 2]
Internet-Draft Policy-Based Mobility March 2012
1. Introduction
Mobile Nodes are increasingly able to operate multiple radios
simultaneously. This capability allows them to be attached to the
Internet through multiple access technologies simultaneously. Such
multi-access connectivity can provide a Mobile Node (MN) with better
experience by binding flows to the best-available access
technologies. From the network point of view, it can provide a
better traffic balancing across available access technologies.
The design priniciple of existing work on flow binding [RFC6089]
follows the original Mobile IP design in which an MN signals the Home
Agent (HA) when any mobility action is necessary. This design
addresses the problem from the "MN's perspective" and works fine
whenever the MN is able to inform the network of flow mobility. The
corresponding "Network perspective" to traffic balancing across
access technologies is missing. There can be times when the network
may wish to indicate the desired policy to the MN based on the
overall traffic conditions present at the network. The eventual
disposition may still be subject to conditions local to the MN, but
the network's preference of traffic type and access type may need to
be indicated to the MN. For example, consider that a single prefix
is advertised on two different access types. At any given time, how
does the MN choose one access type over another for a particular
flow, and for how long? This is subject to the policy local to the
MN, but the network itself has a role to play in establishing and
enforcing such a policy. The network may want the MN to use, subject
to connectivity conditions, Access Technology Type X (ATTx) for a set
of flows until the next Z seconds, and then revert back to Access
Technology Type Y (ATTy) for those flows.
There is no mechanism in IP mobility that allows the mobile gateway
to express its desired policy for mapping a set of flows to a
particular access technology for a certain configrauble duration of
time. Policy here is a construct that maps flows to access types for
a certain duration of time. This document specifies a protocol that
enables 1) an HA to express its policy to a MN, and 2) an LMA to
express its policy to a Mobility Anchor Gateway (MAG), which may then
relay it to the MN through appropriate L2 signaling. The policy
signaling is a Request - Response procedure in which the recipient
responds to the expressed policy based on the local conditions. This
document specifies the access technology, flow filter and duration
for the policy for a particular MN. New policy attributes may be
defined in the future.
Koodli & Chowdhury Expires September 3, 2012 [Page 3]
Internet-Draft Policy-Based Mobility March 2012
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:
Access Technology Type (ATT): The type of radio access technology
used by the MN. The examples include cellular, WiFi and Femto
networks.
Flow Handover: Network-initiated handover of one or more
application flows from one network interface to another.
Flow Filter: a parameter set that identifies a flow. An example
wildcard Flow Filter is a Prefix.
Flow Policy Request (FPRQ): A message sent by the LMA requesting a
MAG to establish forwarding for one or more application flows of a
MN for the duration specified. It is also a message sent by the
HA to the MN. This message contains one or more flow filters, the
target Access Technology Type (ATT) for those flow filters and the
time in seconds for which the the flow handover is requested to be
valid.
Flow Policy Reply (FPRP): A reply from the MAG to the LMA
containing the resolution of FPRQ message. Prior to accepting the
FPRQ message, the MAG may consult any appropriate entity to ensure
that the MN has suitable connectivity conditions for the desired
flow mobility. The interaction between the MAG and any other
entity is outside the scope of this document. An FPRP is also a
reply message from a MN to the HA.
Flow Forwarding Entry (FFE): A logical data structure used to
store the flow forwarding information as a result of processing
the FPRQ and FPRP messages.
3. Protocol
The session creation at the LMA follows the basic model of RFC 5213.
At the time of attach, one or more prefixes are assigned to the MN
corresponding to the ATT. Those prefixes may be common across the
ATTs the MN is using or they may be unique to each ATT. When the LMA
signals the MAG with an FPRQ message, it is essentially requesting if
Koodli & Chowdhury Expires September 3, 2012 [Page 4]
Internet-Draft Policy-Based Mobility March 2012
the policy for flow mobility is acceptable to the MAG based on the
prevailing network conditions. The policy states that the LMA wants
the identified flows be supported over the ATT indicated for the
duration specified. The target prefix itself may already be valid on
the ATT. However, traffic flow corresponding to that prefix may not
be best-suited under the prevailing network conditions. Hence, the
LMA verfies if the impending flow mobility is acceptable before
actually enforcing it.
The conditions permitting, the MAG responds with a Status indicating
that flow mobility is acceptable in the FPRP message. The MAG may
consult any other network element in order to verify that the access
network conditions are acceptable for flow mobility. The MAG MAY
inform the MN about the network policy through appropriate L2
signaling. When such L2 signaling is unavailable, the MN MUST be
prepared to accept packets on any applicable access technology
interface, and transmit the return packets back on the same interface
[LI-draft]. When conditions are not suitable for flow handover, the
MAG responds with an appropriate Status code in the FPRP message.
The LMA MUST NOT handover the flow to the ATT indicated in the FPRQ
message. The LMA MAY initiate a new FPRQ message at a later time.
The behavior of the protocol for Mobile IPv6 is similar. The HA
sends an FPRQ message to the MN indicating the policy preference for
a flow. The MN responds with its willingness (or not) with the FPRP
message. Once the policy is known, the MN may use the protocol
specified in [RFC6089] to actually bind a flow to an access
technology interface.
The signaling may take place any time. The flow treatment policy is
valid for the duration agreed in the signaling exchange or until the
next round of signaling exchange. The default policy is provided by
the network at the time a mobility session is created using the
(Proxy) Binding Update and (Proxy) Binding Acknowledge signaling.
These messages MUST include one or more Flow Policy Object options
specified in this document.
The flow treatment policy may be rescinded any time. For instance,
the LMA (HA) may send a FPRQ message with a request to terminate an
existing flow policy. Such a message may be generated as a result of
termination of an application flow. The flow forwarding policy has a
default lifetime, upon the expiry of which the forwarding reverts to
the default flow forwarding policy. When flow forwarding service
ceases, the corresponding logical datastructure entries MUST be
removed.
At any point in time, a MAG or a MN may send an Unsolicited FPRP
(U-FPRP) message to indicate events such as FFE lifetime renewal or a
Koodli & Chowdhury Expires September 3, 2012 [Page 5]
Internet-Draft Policy-Based Mobility March 2012
MN moving out of coverage. The LMA (HA) sends an FPRQ message to
confirm the renewal of FFE lifetime. When the event indicates a MN
moving out of coverage, the LMA sends FPRQ to cancel an existing flow
forwarding service. In any case, the MAG MUST wait for the FPRQ
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 (P)MIP6 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.
4. Message Formats
4.1. Flow Policy Request (FPRQ)
The LMA (HA) sends an FPRQ message to a MAG (MN) to request flow
handover of one or more application flows of a MN. The Flow Policy
Object present in the message identifies the flows and their target
ATT.
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 Policy Request (FPRQ) 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.
Koodli & Chowdhury Expires September 3, 2012 [Page 6]
Internet-Draft Policy-Based Mobility March 2012
'R' flag: Set to 0, indicates it is an FPRQ 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 the flow policy.
Mobility Options: MUST contain the Flow Policy Object, which is a
3-tuple containing the {MN Identifier, Access Technology Type,
Traffic Selector} options in that order. The Flow Policy Object
forms the flow policy for the duration specified in Lifetime. The
Flow Policy Object may be repeated more than once.
o Mobile Node Identifier option [RFC5213]
o Access Technology Type option [RFC5213]
o Traffic Selector option [RFC6089]
4.2. Flow Policy Reply (FPRP)
The MAG sends an FPRP message to the LMA as a response to the FPRQ
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 Policy Reply (FPRP) Message
Koodli & Chowdhury Expires September 3, 2012 [Page 7]
Internet-Draft Policy-Based Mobility March 2012
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 FPRP message.
'U' flag: When set to 1, the FPRP 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 FPRQ message to confirm that the
request is acceptable to the LMA.
Reserved: This field is unused. MUST be set zero.
Status: The following codes are currently defined. New codes may
be specified in the future.
0: Success
1: Failure, unable to establish flow policy due to poor
connectivity
2: Failure, unable to establish flow policy due to charging
limitations
Lifetime: The time in seconds for which the flow forwarding is
supported. Typically copied from the corresponding field in the
FPRQ message.
Mobility Options: When Status code is 0, no options may be
present. When the Status code is other than 0, the Flow Policy
Object for which the flow policy could not be applied MUST be
included in the order they were present in the FPRQ message.
5. Security Considerations
The protocol specified in this document uses the same security
association between the LMA and the MAG to protect the FPRQ and FPRP
messages. Similarly, the protocol uses the same security association
between the HA and the MN to protect the FPRQ and FPRP signaling
messages. No new security risks are identified. Support for
integrity protection using IPsec is required, but support for
confidentiality is not necessary.
Koodli & Chowdhury Expires September 3, 2012 [Page 8]
Internet-Draft Policy-Based Mobility March 2012
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.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
Network Mobility (NEMO) Basic Support", RFC 6089,
January 2011.
7.2. Informative References
[LI-draft]
Melia, T. and S. Gundavelli, "Logical Interface Support
for multi-mode IP Hosts",
draft-ietf-netext-logical-interface-support-01.txt,
Oct 2010.
Authors' Addresses
Rajeev Koodli
Cisco Systems
USA
Email: rkoodli@cisco.com
Koodli & Chowdhury Expires September 3, 2012 [Page 9]
Internet-Draft Policy-Based Mobility March 2012
Kuntal Chowdhury
USA
Email:
Koodli & Chowdhury Expires September 3, 2012 [Page 10]
