MEXT Working Group M. Eriksson
Internet-Draft C. Larsson
Intended status: Standards Track Ericsson Research
Expires: December 21, 2008 R. Kuntz
Louis Pasteur University
June 19, 2008
Mobile IPv6 Flow Routing over Multiple Care-of Addresses
draft-eriksson-mext-mipv6-routing-rules-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 December 21, 2008.
Abstract
This document specifies a mechanism to selectively route IP flows to
and from Mobile IPv6 Mobile Nodes and NEMO Mobile Routers which have
registered multiple care-of addresses. It explains how to apply the
generic flow distribution language defined in a companion draft to
Mobile IPv6, defines a transport mechanism to transmit the rules
between Mobile IPv6 nodes, and describes how the rules are sent and
handled upon reception.
Eriksson, et al. Expires December 21, 2008 [Page 1]
Internet-Draft MIPv6 Flow Routing June 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Application of the Flow Rule Language . . . . . . . . . . . . 4
3.1. Identity Tag . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Local Node . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Peer Node . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. The Path Identifier . . . . . . . . . . . . . . . . . . . 4
3.5. Rules and Binding Identifiers . . . . . . . . . . . . . . 4
4. Transmission of Flow Rules . . . . . . . . . . . . . . . . . . 5
4.1. Flow Rules Update Request . . . . . . . . . . . . . . . . 5
4.2. Flow Rules Update Acknowledgement . . . . . . . . . . . . 6
5. Endpoints Operations . . . . . . . . . . . . . . . . . . . . . 7
5.1. Sending Rules . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Receiving Rules . . . . . . . . . . . . . . . . . . . . . 8
6. Mobile Node Routing Controlled By Home Agent . . . . . . . . . 8
7. Rules and Bindings Independence . . . . . . . . . . . . . . . 9
8. Routing Rules Lifetime . . . . . . . . . . . . . . . . . . . . 9
9. Support for dual-stack MIPv6 . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Eriksson, et al. Expires December 21, 2008 [Page 2]
Internet-Draft MIPv6 Flow Routing June 2008
1. Introduction
The Multiple Care-of Registration Mechanism [7] makes it possible for
Mobile IPv6 [3] Mobile Nodes and NEMO [4] Mobile Routers to register
more than one care-of address. The care-of addresses can be from
different network interfaces, then enabling concurrent traffic over
more than one access network. It is also possible to register
multiple care-of addresses from the same network interface
(presumably with different network prefixes), allowing the use of
more than one network path to the same interface. Goals and
motivations to use multiple concurrent paths are further investigated
in [6].
A Mobile Node or Mobile Router can decide for itself what outgoing
interface and care-of address to use for each flow. For incoming
traffic, it has to instruct its Home Agent and Corresponding Nodes
which of its care-of addresses to use for different incoming flows.
In some cases, it might also be useful to have the Home Agent
influence or control what interfaces and care-of addresses that the
Mobile Node or Mobile Router should use for outgoing traffic. It is
thus necessary to be able to transport a set of routing rules between
Mobile IPv6 nodes.
This specification describes a mechanism to control which IP traffic
goes over what path, i.e., to and from what care-of address. It also
describes how the rules are transmitted between the network nodes
(Mobile Node or Router, Home Agent and Correspondent Nodes).
The paths to use for different flows are selected using the Flow
Distribution Rule Language for Multi-Access Nodes [5]. The
application of the rule language to Mobile IPv6 is described in
Section 3.
The rules are transmitted in MIPv6 Generic Notification Messages [2],
see Section 4. How those rules are sent and handled upon reception
is described in Section 5. It is also possible for the Home Agent to
instruct the Mobile Node what care-of address to use for outgoing
traffic, as described in Section 6.
The main advantages of the proposed solution are the separation of
rule updates from the handover management, and the possibility to
send rules in a bidirectional manner.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Eriksson, et al. Expires December 21, 2008 [Page 3]
Internet-Draft MIPv6 Flow Routing June 2008
document are to be interpreted as described in RFC 2119 [1].
3. Application of the Flow Rule Language
The routing of each IP flow is specified with rules written in the
Flow Distribution Rule Language for Multi-Access Nodes [5], which is
a generic language for path selection for multi-access nodes. This
section describes how it is applied to MIPv6.
3.1. Identity Tag
The "Identity Tag" is the Home Address of the Mobile Node or the
prefix of the Mobile Network. It is derived implicitly from the
header of the Flow Rules Update Request message (see Section 4.1),
which is always sent in the context of an existing binding.
3.2. Local Node
The rule language's "Local Node" maps to the MIPv6 Mobile Node. When
a rule refers to "local", it implies checking the selector (port
numbers, etc.) of the Mobile Node.
A Mobile Router MAY specify separate handling for parts of its Mobile
Network by giving an address prefix after the "local" keyword in some
rules. A Mobile Node MUST NOT specify an address prefix after the
"local" keyword.
3.3. Peer Node
"Peer Node" maps to the MIPv6 Correspondent Node. Selectors for the
"peer" side will thus always match the address, port number, etc., of
the Corresponding Node.
3.4. The Path Identifier
The target of the flow distribution rules is a Path Identifier. For
MIPv6, the Path Identifier is identical to the Binding Identifier
[7].
3.5. Rules and Binding Identifiers
A rule that refers to an unknown binding identifier MUST be ignored.
This allows for "opportunistic" rules, which will route some traffic
over a particular binding, when it is available. The rule language's
support for conditional rule sets MAY be used as a more expressive
way to have "adaptive" rules.
Eriksson, et al. Expires December 21, 2008 [Page 4]
Internet-Draft MIPv6 Flow Routing June 2008
A flow that does not match any rule MUST be forwarded over the
care-of address that has the lowest numbered binding identifier.
Rule generators SHOULD NOT rely on this fact, but instead use match-
all rules to explicitly select a path for all flows.
4. Transmission of Flow Rules
Flow routing rules signaling is transmitted in Generic Notification
Messages [2] (GNM). A separate GNM sub-type is used for update
requests, and the regular GNM Acknowledgement sub-type is used for
acknowledgments.
The use of GNM, and thereby the MIPv6 Mobility Header, puts a limit
on the total size of the rules. The Header Len field of the Mobility
Header is only 8 bits wide. As this field represents the message
length in units of 8 octets (excluding the first 8 octets), the
maximum length of an MH message is 2048 octets. After adjusting for
the size of the MH and GNM headers, the maximum size of the rules are
2036 octets. If this shows to be too small, a way to extend the
maximum size of GNM messages should be developed.
4.1. Flow Rules Update Request
The rules for flow routing are transferred as a string of ASCII
characters, according to the syntax in [5]. The string MUST be
padded with spaces (ASCII 32) to have a length that is an even
multiple of 8 octets.
The Flow Rules Update Request uses the sub-type value (TBD). When
this value is indicated in the Sub-Type field, the format of the Sub-
Type specific data field in the Generic Notification message is as
follows:
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 Number |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Flow Distribution Rules .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Eriksson, et al. Expires December 21, 2008 [Page 5]
Internet-Draft MIPv6 Flow Routing June 2008
Sequence Number
A 16-bit unsigned integer used by the receiving node to sequence
requests and by the sending node to match a returned Generic
Notification Acknowledgement with this Flow Rules Update Request.
The Flow Rules Update Request uses the same Sequence Number
counter as the Generic Notification Request sub-type.
Acknowledge (A)
The Acknowledge (A) bit is set by the sender to request a Generic
Notification Acknowledgement (see Section 4.2) be returned upon
receipt of a Flow Rules Update Request.
Reserved
This field is unused. It MUST be initialized to zero by the
sender, and MUST be ignored by the receiver.
Flow Distribution Rules
A string of ASCII characters, containing rules for flow
distribution in the format described in [5].
A Flow Rules Update Request message MUST NOT have any mobility
options.
4.2. Flow Rules Update Acknowledgement
A Flow Rules Update Request is acknowledged with a regular Generic
Notification Acknowledgement sub-type message.
The sequence number in the Generic Notification Acknowledgement is
copied from the sequence number field in the Flow Rules Update
Request. It is used by the receiving node in matching this Generic
Notification Acknowledgement with an outstanding Flow Rules Update
Request.
In addition to the Status values defined for Generic Notification
Acknowledgement in [2], the following Status values are defined for
an acknowledgement of a Flow Rules Update Request:
(TBD) The recipient failed to parse the rules
Eriksson, et al. Expires December 21, 2008 [Page 6]
Internet-Draft MIPv6 Flow Routing June 2008
5. Endpoints Operations
5.1. Sending Rules
The defined rules are sent to a remote node using the Flow Rules
Update Request message defined in Section 4.1.
Each time the rules need to be updated in the remote node, the
originating node sends the whole new set of rules, even if some of
them have already been sent in a previous request message. This is
because the remote node always delete the previously installed rules
and install the whole new set of rules. Though this might seem
redundant, this is a much simpler mechanism than an incremental
solution. Thanks to the conditional rule sets in the rule language
[5], rules updates can often be avoided. Incremental rule updates
may be introduced as a future enhancement, if experience shows that
they would be useful.
The originating node sets the Acknowledge bit if it wishes to receive
a Generic Notification Acknowledgement message from the remote node.
When set, the node MUST follow the retransmission rules defined in
[2]. If a Mobile Node or Mobile Router does not receive any
acknowledgment message from a Home Agent after
MAX_MH_NOTIFICATION_TIMEOUT (defined in [2]), it MAY try to register
to another Home Agent. In any case, it MUST suppose that the rules
were not installed on the remote node.
Upon reception of a Generic Notification Acknowledgement message from
a remote node, the originating node first checks that the sequence
number set in the message matches the one set in the previously sent
request. If it does not match, it silently drops the acknowledgment
message and keep trying to send request messages. If the sequence
number matches, it stops trying to send request messages to the
remote node and processes the message as described hereinafter.
If the status is set to "0 Notification Request accepted" (as defined
in [2]), the originating node assumes that the rules have been
correctly processed and installed by the remote node.
If the status is set to 128, 129, 130, 131, or 132 (as defined in
[2]), it stops sending request messages and MAY try to register to
another Home Agent. In any case, it MUST suppose that the rules were
not installed on the remote node.
If the status is set to one of the error code defined in Section 4.2,
it MAY try to solve the problem according to the corresponding error
and MAY try sending a new request message as explained above.
Eriksson, et al. Expires December 21, 2008 [Page 7]
Internet-Draft MIPv6 Flow Routing June 2008
5.2. Receiving Rules
Upon reception of a Flow Rules Update Request message defined in
Section 4.1, a Home Agent or Correspondent Node first checks if there
is an existing binding for the node that sent the message. If not,
it discards the message and MUST send a Generic Notification
Acknowledgement message with status code set to "132 Not home agent
for this mobile node" [2]. More details about sending acknowledgment
messages are explained later in this section.
A Mobile Node or Mobile Router that receives a Flow Rules Update
Request from its Home Agent MUST send a Generic Notification
Acknowledgement message with the status code set to "129
Administratively prohibited" [2] if it is not accepting the rules.
If the Flow Rules Update Request is accepted, the receiving node
parses the set of rules included in the message. If an error occurs
while processing the rules, the receiving node MUST send an Generic
Notification Acknowledgment message with the status set to the
appropriate error code defined in Section 4.2. In case of failure,
the receiving node MUST NOT alter the active rules.
If the set of rules was correctly parsed, the receiving node install
them by deleting all the previously installed rules, and installing
the whole new set of rules. Implementers may consider optimizing the
installation of the rules by deleting, adding or replacing only the
rules that actually need it. How the rules are setup on the system
is out of scope for this specification and depends on the operating
system that is used.
If, for some reason, the rules cannot be installed on the system, the
node MUST send an Acknowledgment message with the status set to "130
Insufficient resources" as defined in [2].
If the Acknowledge bit was set in the request message, the node MUST
send a Generic Notification Acknowledgement message. It MUST follow
the rules for sending an acknowledgment message defined in [2] by
copying the sequence number from the request message and setting the
proper status message.
6. Mobile Node Routing Controlled By Home Agent
The Home Agent MAY send routing rules to the Mobile Node, to instruct
it how to route its outgoing traffic. If the Mobile Node is not
allowing or supporting this, it MUST send a Generic Notification
Acknowledgement message with a suitable rejection code.
Eriksson, et al. Expires December 21, 2008 [Page 8]
Internet-Draft MIPv6 Flow Routing June 2008
If the Home Agent is controlling the flow routing of the Mobile Node,
it is useful to have a prearranged agreement on the binding
identifiers that the Mobile Node will use. The Home Agent can then
know what access networks are available to the Mobile Node (by
checking the binding identifiers in the Binding Cache entry of the
MN), and make well founded routing decisions. In some cases, the
Home Agent may have better knowledge about the load and other
characteristics of the access networks, and thereby be able to make
better routing decisions than the Mobile Node could do by itself.
7. Rules and Bindings Independence
In general, it is expected that the flow rules will be changed
independently of the care-of address bindings. The rules are used to
select paths (and thereby often access networks) for the flows, and
may change as the active traffic changes. The care-of address
updates will normally reflect handovers after movements, and will not
affect the rules, which refer to binding identifiers and not to
care-of addresses.
8. Routing Rules Lifetime
The lifetime of the flow routing rules is the same as the lifetime of
the Home Address or Home Network Prefix binding that they are used
for. When all bindings are deleted or the last Binding Cache entry
times out, the corresponding rules are removed.
9. Support for dual-stack MIPv6
The Flow Distribution Rule Language for Multi-Access Nodes [5]
currently only supports IPv6. In an upcoming revision, it will
support rules also for IPv4 traffic. With that new revision, this
specification will be updated to support dual-stack MIPv6 operation.
10. IANA Considerations
A new Generic Notification Message sub-type is required, as described
in Section 4.1:
(TBD) Flow Rules Update Request
The acknowledgments to Flow Rules Update Request reuses the Generic
Notification Acknowledgement, see Section 4.2. We suggest that all
new GNM requests reuse the Generic Notification Acknowledgement, if
Eriksson, et al. Expires December 21, 2008 [Page 9]
Internet-Draft MIPv6 Flow Routing June 2008
possible. For this, a part of the rejection code space should be
allocated per request type, for example codes 192-255.
These rejection codes from Section 4.2 need to be allocated for
acknowledgments to a Flow Rules Update Request:
(TBD) The recipient failed to parse the rules
11. Security Considerations
The flow routing mechanism described in this document allows path
selection for Mobile Nodes and Mobile Networks with multiple
registered care-of addresses. It cannot be used to divert traffic,
as the care-of address registrations are done outside this mechanism.
However, it could be used for denial-of-service, if for example rules
to drop all traffic are installed.
The security of routing rule signaling depends on the security of the
Generic Notification Messages [2]. The GNM does not yet specify
protection for MN-CN signaling, and until the GNM specification is
updated to support this, Corresponding Nodes SHOULD NOT allow the use
of path selection rules.
Home Agents for Mobile Networks MUST check any address prefixes used
with the "local" keyword, so that they are entirely inside the Mobile
Network's own prefix.
12. References
12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Haley, B. and S. Gundavelli, "Generic Notification Message for
Mobile IPv6", draft-haley-mext-generic-notification-message-00
(work in progress), April 2008.
12.2. Informative References
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
Eriksson, et al. Expires December 21, 2008 [Page 10]
Internet-Draft MIPv6 Flow Routing June 2008
[5] Larsson, C., Eriksson, M., Mitsuya, K., Tasaka, K., and R.
Kuntz, "Flow Distribution Rule Language for Multi-Access Nodes",
draft-larsson-mext-flow-distribution-rules-00 (work in
progress), November 2007.
[6] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K.
Kuladinithi, "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-03 (work in
progress), May 2008.
[7] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-08 (work in progress), May 2008.
Authors' Addresses
Michael Eriksson
Ericsson Research
Torshamnsgatan 23
Stockholm SE-164 80
Sweden
Phone: +46 8 757 5888
Email: michael.eriksson@ericsson.com
Conny Larsson
Ericsson Research
Torshamnsgatan 23
Stockholm SE-164 80
Sweden
Phone: +46 8 404 8458
Email: conny.larsson@ericsson.com
Romain Kuntz
Louis Pasteur University / LSIIT
Strasbourg
France
Phone: +33 390 244 584
Email: kuntz@lsiit.u-strasbg.fr
URI: http://clarinet.u-strasbg.fr/~kuntz/
Eriksson, et al. Expires December 21, 2008 [Page 11]
Internet-Draft MIPv6 Flow Routing June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Eriksson, et al. Expires December 21, 2008 [Page 12]