One document matched: draft-tsirtsis-mip4-flowmove-01.txt
Differences from draft-tsirtsis-mip4-flowmove-00.txt
Network Working Group G. Tsirtsis
Internet-Draft V. Park
Intended status: Standards Track Qualcomm
Expires: November 5, 2007 H. Soliman
Elevate Technologies
May 4, 2007
Flow Movement for Mobile IPv4
draft-tsirtsis-mip4-flowmove-01.txt
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 November 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Tsirtsis, et al. Expires November 5, 2007 [Page 1]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
Abstract
Mobile IPv4 allows Mobile Nodes (MN) to create mobility bindings
between their Home Address (HoA) and their current Care-of Address
(CoA) in a Home Agent (HA) so that the HA can redirect traffic for
the MN to its current location. This draft extends MIPv4 so that the
binding granularity is on a per flow basis. Extensions are defined
to allow the registration of multiple CoAs and the definition of
individual flows. Individual flows can then be pointed to the
registered CoAs.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Flow Movement Extensions . . . . . . . . . . . . . . . . . . . 5
3.1. Alternate-CoA Extension . . . . . . . . . . . . . . . . . 5
3.2. Flow Identification Extension . . . . . . . . . . . . . . 6
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 16
4.1.1. Using the Alternate-CoA extension . . . . . . . . . . 17
4.1.2. Using the Flow Identification Extension . . . . . . . 17
4.2. Home Agent Considerations . . . . . . . . . . . . . . . . 19
4.2.1. Handling Alternate-CoA extensions . . . . . . . . . . 19
4.2.2. Handling Flow Identification Extensions . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Aknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
7. Normative References . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. ANNEX A: Illustrative examples . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
Tsirtsis, et al. Expires November 5, 2007 [Page 2]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
1. Requirements notation
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 [RFC2119].
Tsirtsis, et al. Expires November 5, 2007 [Page 3]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
2. Introduction
Mobile IPv4 allows mobile nodes to create bindings between their HoA
and their current CoA in the HA so that the HA can redirect traffic
for the MN to its current location. This draft extends MIPv4 so that
the binding granularity is on a per flow basis. Extensions are
defined to allow the registration of multiple CoAs and the definition
of individual flows. Individual flows can then be pointed to the
registered CoAs, in other words individual flows can be movent
between registered CoA (flow movement). In the context of this
document a "flow" is defined as a collection of packets that match a
set of fields in their network and transport header.
In [RFC3344] a binding is defined as the association between a home
address and a care-of address. This specification defines an
alternate CoA extension which allows a mobile node to register
multiple CoAs over which it is reachable, while each registered CoA
will be identified by a unique Binding Identifier (BID).
This specification also defines a Flow Identification extension which
associates a given flow to one or more of the registered care-of
addresses by pointing to the corresponding BID(s). The association
between flows and BIDs, together with the action field in the flow
identification extension, fully define how traffic should be handled
at the home agent.
Tsirtsis, et al. Expires November 5, 2007 [Page 4]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
3. Flow Movement Extensions
The following extensions are defined according to this specification.
3.1. Alternate-CoA Extension
A new skippable extension to the Mobile IPv4 header in accordance to
the short extension format of [RFC3344] is defined here.
The Alternate-CoA extension defines a mobile node's CoA each of which
is functionaly equivalent to the CoA field in the Mobile IP message
header [RFC3344]. Multiple Alternate-CoA extensions MAY be included
in the same Registration Request.
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 | BID |Priority/Status|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CoA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Alternate-CoA Extension
Type
Alternate-CoA Extension (skippable type range to be assigned by
IANA)
Length
Indicates the length (in bytes) of the extension. The length does
NOT include the Type and Length bytes. The Length of the
extension MUST be either 2 or 6 depending on whether the CoA field
is present.
BID (Binding ID)
The BID field in an 8-bit unsigned integer that identifies the
binding to the CoA included in this extension and it can be used
to point to an Alternate-CoA that was registered earlier.
Priority/Status
When this extension is in a registration request this field
specifies the priority field assigned to the care-of address. The
Priority field is an 8-bit unsigned integer. The receiver can
utilize this priority to determine the preference of the CoA used
Tsirtsis, et al. Expires November 5, 2007 [Page 5]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
to deliver packets. The lower the value the higher priority. A
value of 255 indicates that the CoA indicated should be
deregistered.
When this extension is in a registration reply this field
indicates the status of the CoA. The Status field is an 8-bit
unsigned integer. The possible status codes are listed in
Table 1.
CoA
The CoA field is an 32-bit ipaddr. Set to an alternative care-of
address to the one included in the registration request header.
This field MAY NOT be included if the extension is included in a
registration request and if the BID field is set to the BID of CoA
registered earlier. In addition this field MAY NOT be included if
the extension is included in a registration reply message.
For the Status field values 0-127 indicate success and values between
128 and 255 indicate failure. The following values are defined for
the Status field:
+-------------------+--------+--------------------------------------+
| Status | Value | Comments |
+-------------------+--------+--------------------------------------+
| Accepted | 0 | The CoA is registered |
| | | |
| BID Changed | 1 | The BID associated with an existing |
| | | CoA was changed to the new value |
| | | |
| Reject | 128 | The CoA is rejected |
| | | |
| Unknown BID | 129 | The BID was not recognized |
+-------------------+--------+--------------------------------------+
Table 1: Values for the Alternate-CoA Status field
3.2. Flow Identification Extension
The Flow identification extension is included in the Registration
Request and Reply messages. This extension contains information that
allows the HA to identify a traffic flow and route it to a given
address. Multiple such extension MAY exist within the same message.
A Flow Identification extension is designed to populate and edit a
mobile node classifier in the home agent. A classifier selects
packets based on the content of packet headers according to defined
rules. The Flow Identification extension defines a line in such a
Tsirtsis, et al. Expires November 5, 2007 [Page 6]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
classifier. See Appendix A for an example of such a classifier.
The Flow Identification extension has a flexible format that allows
different fields to appear in the extension based on the way the
mobile node chooses to represent the flow. The flags following the
length field indicate which of the fields used to identify the flow
are present in the extension. As a result, there is no fixed format
for the flow identification extension. This may result in slight
complexity in the implementation; however, this extension will
minimize the total length of the extension sent, which is
particularly important for bandwidth-limited wireless links.
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 | FID |Priority/Status|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | F-Type | Filter Descriptor...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIDs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Flow Identification Extension
Type
Flow Identification Extension (skippable type range. Two values
to be assigned for IPv4 and IPv6 by IANA)
Length
Indicates the length (in bytes) of the extension. The length does
NOT include the Type and Length bytes.
FID
The Flow Identifier field is an 8-bit unsigned integer identifying
a flow. This field is used to refer to an existing flow or to
identify a new flow.
Priority/Status
The Priority field is an 8-bit unsigned integer. When this
extension is in a registration request this field specifies the
priority field assigned to the filter rule defined by this
extension. The receiver can utilize this priority to determine
the order of application of the filter rules defined by the
sender. The lower the value the higher priority (i.e., it is
Tsirtsis, et al. Expires November 5, 2007 [Page 7]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
checked earlier against each packet). A value of 255 indicates
that the filter rule indicated should be deregistered.
The Status field is an 8-bit unsigned integer. When this
extension is in a registration reply this field indicates the
status of the filter rule. The possible status codes are listed
in Table 2.
For the Status field values 0-127 indicate success and values
between 128 and 255 indicate failure. The following values are
defined for the Status field:
+-------------------+--------+--------------------------------------+
| Status | Value | Comments |
+-------------------+--------+--------------------------------------+
| Accepted | 0 | Flow binding successful |
| | | |
| Reject | 128 | Flow binding rejected, reason |
| | | unspecified. |
| | | |
| Poorly Formed | 129 | Flow Identification extension poorly |
| | | formed |
| | | |
| Admin Prohibited | 130 | Administratively prohibited |
| | | |
| Unknown FID | 131 | The FID is not recognized |
| | | |
| Unknown BID | 132 | A BID included in the extension is |
| | | not registered. |
+-------------------+--------+--------------------------------------+
Table 2: Values for the Flow Identification Status field
Action
When this extension is in a registration request this field
specifies the action that needs to be taken by the receiver. The
field SHOULD be set to zero by the home agent in the registration
reply and SHOULD be ignored by the mobile node. See defined
values in Table 3.
The following values are reserved for the Action field.
Tsirtsis, et al. Expires November 5, 2007 [Page 8]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
+---------+-------+-------------------------------------------------+
| Action | Value | Comments |
+---------+-------+-------------------------------------------------+
| Drop | 0 | Drop matching packets. A filter rule |
| | | indicating a drop action MUST include a single |
| | | BID byte, the value of which MAY be set to 255 |
| | | by the sender and the value of which SHOULD be |
| | | ignored by the receiver. |
| | | |
| Forward | 1 | Forward matching packets to the 1st BID in the |
| | | list of BIDs the filter rule is pointing to. |
| | | If the 1st BID becomes invalid (i.e., the |
| | | corresponding CoA is deregistered) use the next |
| | | BID in the list. |
| | | |
| X-Cast | 2 | Forward one copy of each matching packet to the |
| | | list of BIDs this filter rule is pointing to. |
+---------+-------+-------------------------------------------------+
Table 3: Values for the IPv4 and IPv6 Flow Descriptor Action field
F-Type
The Filter Type (F-Type) field identifies the type of Filter
Descriptor included in the extension. Filter Descriptors in
addition to the ones defined in this document can be defined in
other documents but all Filter Descriptors MUST indicate their own
length.
The following values are defined.
+-----------+-------+-----------------------------------------------+
| F-Type | Value | Comments |
+-----------+-------+-----------------------------------------------+
| Do not | 0 | The already registered filter for the FID of |
| Change | | the extension must be used |
| | | |
| IPv4 | 1 | An IPv4 Filter Descriptor follows, see |
| Filter | | Figure 3 |
| | | |
| IPv6 | 2 | An IPv6 Filter Descriptor follows, see |
| Filter | | Figure 4 |
+-----------+-------+-----------------------------------------------+
Table 4
Filter Descriptor
Tsirtsis, et al. Expires November 5, 2007 [Page 9]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
The Filter Descriptor field defines a filter. This field is
further defined in Figure 3 and in Figure 4 depending on the value
of the F-Type field of this extension.
BIDs
Indicates the BIDs to which the Filter Rule Descriptor points to,
in order of appearance. Note that if a filter rule does not point
to any valid BIDs, the filter rule itself becomes invalid.
+---------+-------+-------------------------------------------------+
| BID | Value | Comments |
+---------+-------+-------------------------------------------------+
| Do not | 0 | The already registered filter for the FID of |
| Change | | the extension must be used |
| | | |
| BID | 1-254 | These values point to one of BIDs registered |
| | | with Alternate-CoA extension, in order of |
| | | appearance. Multiple BID bytes can be included |
| | | to point to more than one BIDs |
| | | |
| Default | 255 | the default set of BIDs, registered with |
| List | | Alternate-CoA extensions MUST be used |
+---------+-------+-------------------------------------------------+
Table 5
If the Type field of the Flow Identification extension indicates an
IPv4 Flow then the Filter Rule Descriptor is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|C|D|E|F|G|H|I|K|L| Rsvd |Z| (A)TOS | (B)Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (C)Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (D)Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|(E)S. PrefLeng |(F)D. PrefLeng | (G)Source port - Low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (H)Source port - High | (I)Dst port - Low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (K)Dst port - High | (L)SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (L)SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tsirtsis, et al. Expires November 5, 2007 [Page 10]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
Figure 3: IPv4 Filter Rule Descriptor
Flags (A-L)
Each flag indicates whether the corresponding field is present in
the message
(A)TOS - Type of Service
The TOS field in the data packet as seen by the home agent.
(B)Protocol
An 8-bit unsigned integer representing the value of the transport
protocol number associated with the port numbers in data packets.
(C)Source Address
This field identifies the source address of data packets as seen
by the home agent that is, the 32-bit IPv4 address of the
correspondent node.
(D)Destination Address
This field identifies the destination address of data packets as
seen by the home agent. When included this field must be set to
one of the registered home addresses of the mobile node. It is a
32-bit IPv4 address.
(E)Source Prefix Length
This field includes the prefix length for the source address.
This field can only be included if the Source Address field is
included.
(F)Destination Prefix Length
This field includes the prefix length for the destination address.
If The Destination Address field is included then it refers to
that field; otherwise it refers to the home address field of the
registration request header.
(G)Source Port - Low
This field identifies the lowest source port number within a range
of port numbers that will be used in data packets, as seen by the
home agent.
Tsirtsis, et al. Expires November 5, 2007 [Page 11]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
(H)Source Port - High
This field identifies the highest source port number within a
range of port numbers that will be used in data packets, as seen
by the home agent. If a single port is indicated then this field
SHOULD NOT be included. If it is included it SHOULD be set to the
value of the Source Port - Low field.
(I)Destination Port - Low
This field identifies the lowest destination port number within a
range of port numbers that will be used in data packets as seen by
the home agent.
(K)Destination Port - High
This field identifies the highest destination port number within a
range of port numbers that will be used in data packets as seen by
the home agent. If a single port is indicated then this field
SHOULD NOT be included. If it is included it SHOULD be set to the
value of the Dst Port - Low field.
(L)SPI - Security Parameter Index
The SPI field in the data packet as seen by the home agent.
If the Type field of the Flow Identification extension indicates an
IPv6 Flow then the Filter Rule Descriptor is:
Tsirtsis, et al. Expires November 5, 2007 [Page 12]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|C|D|E|F|G|H|I|K|L|M| Rsv |Z| (A)CS | (B)Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ (C)Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ (D)Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|(E)S. PrefLeng |(F)D. PrefLeng | (G)Source port - Low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (H)Source port - High | (I)Dst port - Low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (K)Dst port - High | (L)SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (L)SPI | (M)Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (M)Flow Label |
+-+-+-+-+-+-+-+-+
Figure 4: IPv6 Filter Rule Descriptor
Flags (A-M)
Each flag indicates whether the corresponding field is present in
the message
CS - Class of Service
The CS field in the data packet as seen by the home agent.
(B)Protocol
An 8-bit unsigned integer representing value of the transport
protocol number associated with the port numbers in data packets.
Tsirtsis, et al. Expires November 5, 2007 [Page 13]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
(C)Source Address
This field identifies the source address of data packets as seen
by the home agent. That is, the address of the correspondent node
and it is a 128-bit IPv6 address.
(D)Destination Address
This field identifies the destination address of the data packet
as seen by the home agent. When included this field must be set
to one of the registered home addresses of the mobile node and it
is a 128-bit IPv6 address.
(E)Source Prefix Length
This field includes the prefix for the source address. This field
can only be included if the Source Address field is included .
(F)Destination Prefix Length
This field includes the prefix for the destination address. If
The Destination Address field is included then it refers to that
field otherwise it refers to the home address field of the
registration request header.
(G)Source Port - Low
This field identifies the lowest source port number within a range
of port numbers that will be used in data packets, as seen by the
home agent.
(H)Source Port - High
This field identifies the highest source port number within a
range of port numbers that will be used in data packets, as seen
by the home agent. If a single port is indicated then this field
SHOULD NOT be included. If it is included it SHOULD be set to the
value of the Source Port - Low field.
(I)Destination Port - Low
This field identifies the lowest destination port number within a
range of port numbers that will be used in data packets as seen by
the home agent.
(K)Destination Port - High
Tsirtsis, et al. Expires November 5, 2007 [Page 14]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
This field identifies the highest destination port number within a
range of port numbers that will be used in data packets as seen by
the home agent. If a single port is indicated then this field
SHOULD NOT be included. If it is included it SHOULD be set to the
value of the Dst Port - Low field.
(L)SPI - Security Parameter Index
The SPI field in the data packet as seen by the home agent.
(M)Flow Label
The Flow Label field in the data packet as seen by the home agent.
Tsirtsis, et al. Expires November 5, 2007 [Page 15]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
4. Protocol Operation
This specification allows a mobile node to register multiple CoAs
using the Alternate-CoA extension and associate different flows with
different CoAs by using the Flow Identification extension.
When multiple CoAs are registered without any specific flow
associated with them, the registered CoAs are treated as alternative
paths to the mobile's current location. The CoAs are ranked by the
Priority field in the Alternate-CoA extension and all traffic to the
mobile's registered HoA(s) SHOULD be sent to the CoA with the lowest
priority. If a CoA is deregistered, the CoA with the next lowest
priority SHOULD become the default path for the mobile's traffic.
Note that, the HA MAY be configured with a local policy that takes
advantage of multiple CoAs in a certain way. For example, x-casting
across the registered CoAs MAY be used by the HA without any further
signaling from the mobile; this is a configuration issue and outside
the scope of this document.
When the Flow Identification extensions are also used, however, the
mobile can indicate which flow is to be associated with which CoA. A
single flow MAY be associated with more than one CoAs, while many
flows MAY be associated with the same CoA. The effect of associating
flows with CoA ofcourse depends on the action defined for that flow.
The Flow Identification extension is variable length and several
fields might be omitted as required. When the extension is sent to
deregister a filter rule (Priority set to 255) only the first line of
Figure 2 needs to be sent (i.e., the first 4 bytes). If the priority
and/or action values need to be changed for an existing FID then the
F-Type MUST be set to 0 and one BID byte set to 0 MUST be included,
indicating no changes to the filter and the BIDs associated with it.
The Filter Descriptor of a given FID can be changed by sending the
extension including the new Filter Desctriptor and a single BID byte
set to 0. The BIDs associated with a given FID can be changed by
sending the extension with F-Type set to 0 (and not including a
Filter Descriptor). The F-Type (when not set to 0) indicates the
type of Filter Descriptor used. In this specification we define
Filter Descriptors for IPv4 and IPv6; other Filter Descriptors MAY be
defined in separate documents.
4.1. Mobile Node Considerations
A mobile MAY send an Alternate-CoA extension with the CoA field
matching the CoA field in the Mobile IP message header to check
whether the HA supports the extensions defined in this specification.
Since the extensions defined here are skippable, if the registration
Tsirtsis, et al. Expires November 5, 2007 [Page 16]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
reply does not include the Alternate-CoA extensions sent by the
mobile, the mobile knows that the HA does not support this
specification. If, however, the HA returns the Alternate-CoA
extensions in the reply, the HA does support this specification.
4.1.1. Using the Alternate-CoA extension
A mobile MAY include one or more Alternate-CoA extensions in each
registration request message. If the mobile has already registered a
CoA without using the Alternate-CoA extension and the mobile wants to
registered an additional CoA, the original and the new CoAs MUST be
sent in the new registration as Alternate-CoA extensions so that they
can be ranked with priorities and be associated with BIDs. In other
words the new message will include an Alternate-CoA with the CoA
field set to the CoA registered in the earlier message.
Unless multiple Alternate-CoA extensions are included in the same
registration request message, the different CoAs will have different
lifetimes associated with them. Each CoA MAY be refreshed
individually by sending a registration request with that CoA in an
Alternate-CoA extension. Alternatively, multiple CoAs can be
refreshed at the same time by sending a registration request with
multiple Alternate-CoA extensions.
If an earlier registered CoA is not included in a registration
request it does not mean that the CoA is deregistered. Instead CoAs
are deregistered when their lifetimes expire or when they are
explicitly deregistered by the mobile node.
A mobile MAY deregister any CoA by setting its priority to 255. Note
that the mobile can change the priority of a given CoA by sending an
Alternate-CoA extension with the BID field set to the BID of the CoA
in question, the priority field to the new value (or 255 for
deregistration), and without including the CoA field.
A mobile MAY replace the CoA associated with a given BID by sending
an Alternate-CoA with the BID field set to the BID of an existing CoA
and the priority and CoA fields to their new values.
4.1.2. Using the Flow Identification Extension
The Flow Identification extensions allow a mobile to control a mobile
specific classifier table present in the Home Agent memory. Each
Flow Identification extension defines one filter rule line in that
classifier, the output of which is one or more BIDs pointing to one
or more of the registered CoAs.
Each filter rule in the classifier table can be referenced by the FID
Tsirtsis, et al. Expires November 5, 2007 [Page 17]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
of the Flow Identification extension that created it. If the mobile
wants to change the priority of a filter rule it can send a Flow
Identification extension including the FID of the filter rule and
setting the Priority field to the new value (or 255 for
deregistration), and without including the Filter Rule Definition or
any BIDs.
Filter rules do not need to be refreshed explicitly. A filter rule
is valid as long as it points to a valid BID, i.e., a registered CoA.
If a filter rule does not point to any valid BIDs it will be removed.
Any filter rule in the classifier table can be replaced by a new
filter rule by sending a Flow Identification extension with the FID
field set to the FID of the filter rule to be replaced and the rest
of the extension defining the new filter rule, priority and the BIDs
it points to.
Each Flow Identification extension is ranked according to its
priority field. The lower the value of the priority field the higher
its priority (i.e., it is checked earlier against each packet). As
in most classifiers, filter rules with the same priority SHOULD be
non-overlapping, otherwise the result is undefined. Overlapping
filter rules SHOULD have different priorities.
Mobiles SHOULD define a default filter rule for traffic that does not
match any other rule. The default filter rule MAY be defined with a
Filter Identification extension with a high priority value (so it is
checked last) and with the Filter Descriptor with all the flags set
to 0 and the action field set to an appropriate value (e.g.,
forward). Note that such a Filter Descriptor will match all packets.
A mobile node can use the Flow Identification extension to associate
a given flow with one or more of the registered CoAs. The mobile
MUST register its CoAs with the Alternate-CoA extension in order to
associate flows with them, using the BID as a handle. One or more
Flow Identification extensions and one or more Alternate-CoA
extensions MAY be present in the same message.
If a Flow Identification extension includes a BID field set to the
value 155 then the filter rule points to all the registered CoAs.
The order of the CoAs for such a filter rule is dictated by the
priority level of each BID, taken by the Priority field of the
Alternate-CoA used to register them. If one or more BIDs are present
in the Flow Identification extension then the filter rule points to
the specific BIDs included in the extension. Note that the list of
BIDs in the Flow Identification extension is ordered and its
significance depends on the action indicated by the action field in
the same extension.
Tsirtsis, et al. Expires November 5, 2007 [Page 18]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
4.2. Home Agent Considerations
4.2.1. Handling Alternate-CoA extensions
A Home Agent that supports this specification SHOULD ignore the "S"
flag (Simultaneous Bindings) in the registration request message
header when the same message includes Alternate-CoA extensions. In
other words, the mechanisms defined in this specification override
the mechanism defined by the "S" flag in [RFC3344].
If an Alternate-CoA extension is received by an HA in a registration
request message, the HA SHOULD include a corresponding Alternate-CoA
extension in the registration reply message. The BID of Alternate-
CoA extension MUST be copied from the BID of the Alternate-CoA
extension in the corresponding registration request and the Status
field SHOULD be set to an appropriate value (e.g., indicating accept,
reject etc).
When a valid registration request message includes one or more
accepted Alternate-CoA extensions the HA MUST include the accepted
CoAs in the mobility bindings table which binds the registered home
address(es) with the registered CoAs together with their BIDs,
priorities and lifetimes. The BID and priority of a CoA is indicated
in the Alternate-CoA extension, while the lifetime is inherited from
the lifetime of the registration reply message that accepted them as
registered CoAs. Thus, different Alternate-CoAs will have different
lifetimes if they are registered with different registration request
messages, but they will have the same lifetime if they are included
in the same registration request.
The CoAs are ranked according to their priority; the lowest the value
of the priority field the higher their ranking. If an Alternate-CoA
is rejected then the HA MUST NOT include it in the mobility bindings
table. If the lifetime of an Alternate-CoA expires, the
corresponding CoA MUST be removed from the mobility bindings table.
If an Alternate-CoA extension is received with a BID that matches an
existing BID then:
The HA MUST check the priority field of the extension in quesiton.
If the priority field is set to 255 (indicating deregistration)
the CoA MUST be removed from the mobility bindings table and from
any filter rules that point to it.
If the priority is set to any other value, the HA MUST check the
CoA field of the same extension. If the CoA field is not
included, the priority of the CoA, identified by the BID included
in the extension, MUST be updated with the indicated value.
Tsirtsis, et al. Expires November 5, 2007 [Page 19]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
If the CoA field exists and matches the CoA that the BID field
points to in the HA mobility bindings table, the priority of that
CoA is again updated.
If the CoA field exists and is different from the CoA the BID
field points to in the HA mobility bindins table, the HA SHOULD
update its table with the new CoA and priority for that BID.
If an Alternate-CoA extension is received with a BID that does not
match an existing BID then:
The HA MUST check the CoA field of the extension. If the CoA
field is not included, the HA SHOULD include an Alternate-CoA
extension in the registration reply with a BID copied from the
corresponding extension in the request message and the Status
field set to "Unknown BID."
If the CoA field exists, the HA MUST store the BID, CoA and
priority values in the mobility bindings table for the mobile.
The CoA MUST be ranked with the other registered CoAs according to
the value of the priority field.
If the CoA field exists but it matches a CoA that is already
registered with a different BID the HA MAY replace the old BID
with the new BID and indicate a "BID changed" in the Status field
of the corresponding Alternate-CoA extension included in the
registration reply message.
4.2.2. Handling Flow Identification Extensions
If a Flow Identification extension is received by an HA in a
registration request message, the HA SHOULD include a corresponding
Flow Identification extension in the registration reply message. The
FID of the Flow Identification extension in the reply message MUST be
copied from the FID of the Flow Identification extension in the
corresponding registration request and the Status field SHOULD be set
to an appropriate value (e.g., indicating accept, reject etc).
When a valid registration request message includes one or more
accepted Filter Identification extensions the HA MUST include the
accepted filter rules in the mobile specific classifier table which
associates the order list of filter rules with the BIDs they point
to. The priority of a filter rule, the description of the filter
rule, the action and the BID(s) the filter rule is associated with
are indicated in the Flow Identification extension.
The filter rules are ranked according to their priority. Filter
rules MUST be ranked from lowest to higher priority. If a filter
Tsirtsis, et al. Expires November 5, 2007 [Page 20]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
rule is rejected then it MUST NOT included in the mobile specific
classifier.
Each filter rules in the mobile specific classifier is valid as long
as points to a valid BID, i.e., a registered CoA. If a filter rule
does not point to any valid BIDs the HA MUST remove it from the
mobile specific classifier.
If the HA receives a Flow Identification extension, it SHOULD first
check the FID field of that extension.
If the value of the FID field does not match any of the FIDs in
the mobile specific classifier, the HA SHOULD include the filter
rule described in the extension in the mobile specific classifier
table. The new filter rule MUST be ranked according to the
priority field indicated in the Flow Identification extension.
If a one or more BIDs are included then the filter rule MUST
point to the list of BIDs in the order they appear.
If any of the including BIDs do not match one of the registered
BIDs in the mobile bindings table for this mobile the HA MUST
disregard the Flow Identification extension and MUST return a
reply message with a Flow Identification extension that
includes the FID of the corresponding extension in the request
message and the Status field set to an appropriate value e.g.,
"Unknown BID."
If a BID of value 255 is included, the filter rule MUST point
to the default list of BIDs. This is the list of BIDs in the
mobility bindings table for this mobile.
If a BID of value 0 is included the HA MUST disregard the Flow
Identification extension and MUST return a reply message with a
Flow Identification extension that includes the FID of the
corresponding extension in the request message and the Status
field set to an appropriate value e.g., "Unknown BID."
If the value of the FID field matches any of the FIDs in the
mobile specific classifier the HA SHOULD then check the priority
field of the Flow Identification extension. If the priority field
is set to 255 then the filter rule associated with the FID in the
Flow Identification extensions MUST be removed from the mobile
specific classifier table.
Tsirtsis, et al. Expires November 5, 2007 [Page 21]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
If the priority field, however, is set to a value other than
255 the HA SHOULD check the Filter Description field of the
Flow Identification extension.
If the Filter Description is not included (F-Type field set to
0) and the BID field is set to 0, the HA MUST adjust the
ranking of the filter rule corresponding to the FID according
to the priority field in the Flow Identification extension.
If any BIDs are also included in the Flow Identification
extensions then the list of BIDs associated with that filter
rule MUST also be replaced by the list provided in the Flow
Identification extension. If a BID field set to 255 is
included then the filter rules MUST be re-pointed to the
default list of BIDs registered with Alternate-CoA extensions.
Note a BID field set to 0 is included the BIDs list for this
filter rule in the mobility specific classifier table MUST NOT
be changed.
If the priority field, however, is set to a value other than 255
and the Filter Description field is included then the HA MUST
replace the corresponding filter rule in the mobile specific
classifier table with the filter rule in the Flow Identification
extension.
If any BIDs are also included in the Flow Identification
extensions then the list of BIDs associated with that filter
rule MUST also be replaced by the list provided in the Flow
Identification extension. If a BID field set to 255 is
included then the filter rules MUST be re-pointed to the
default list of BIDs registered with Alternate-CoA extensions.
Note that if a BID field set to 0 is included the BIDs field,
the list of BIDs this filter rule points to MUST NOT be changed
from its previous configuration.
Tsirtsis, et al. Expires November 5, 2007 [Page 22]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
5. Security Considerations
This specification operates in the security constraints and
requirements of [RFC3344]. All extensions defined in this
specification MUST be covered by the mobile - home authentication
extension.
Tsirtsis, et al. Expires November 5, 2007 [Page 23]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
6. Aknowledgements
This document borrows ideas regarding multiple CoA registration and
flow movement currently being discussed in the context of Monami6. A
special thanks to Michaela Vanderveen for her thorough review.
Tsirtsis, et al. Expires November 5, 2007 [Page 24]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP,
revised", RFC 3024, January 2001.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519,
May 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Tsirtsis, et al. Expires November 5, 2007 [Page 25]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
Appendix A. ANNEX A: Illustrative examples
The extensions defined in this specification manipulate a mobile
specific clasifier of the following format:
FID priority filter_rule action [BID, BID, ...], where:
FID: used as a handle to refer to a given line in the mobile
specific classifier
Priority: Defines the order in which the rule is checked against
the packet; the lower the priority the earlier it is processed.
When filter rules are overlapping, e.g., (filter_rule1=UDP),
(filter_rule2=UDP, Port=80) they should have different priority
numbers otherwise the result is likely to be implementation
specific. If filter_rules are not overlapping
e.g.,(filter_rule1=UDP), (filter_rule2=TCP) they may have the same
priority.
Filter_rule: The collection of parameters against which a packet
is matched. This may include fields from the IP header (e.g.,
source and destination address) as well as fields from the
transport header (e.g., port numbers).
BID: A handle that points to a single Care-of-Address from the
list of registered Care-off Addresses in the mobility bindings
table for the mobile.
Action: Defines what action is to be taken when a given packet
matches a filter_rule
[BID, BID, ...]: Defines one or more BIDs to which the filter_rule
points. The list of BIDs is ordered but its use depends on the
action. each BID represents a registered CoA.
The last Filter Rule should be a rule with a wildcard (i.e., empty)
filter_rule i.e., a rule that matches all packets that have not
matched any of the previous rules.
So for example the following table might be defined:
FID1 10 UDP port1000 xcast
FID2 20 UDP forward BID1
FID7 30 TCP port80 forward BID1, BID2
Tsirtsis, et al. Expires November 5, 2007 [Page 26]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
FID6 50 TCP port123 drop
FID10 200 * forward
The Mobility Bindings table for a given set of HoAs will also have a
format similar to: BID priority CoA
1 10 CoA1
2 20 CoA2
3 30 CoA3
According to the above all UDP packets on port1000 will be x-casted
to all the CoAs in the mobility bindings table (CoA1, CoA2, CoA3).
Any other UDP packets will be forwarded to the CoA indicated by BID1
(i.e., CoA1). All TCP packets on port 80 will be forwarded to the
CoA associated with BID1 (i.e., CoA1), unless the CoA associated with
BID1 is deregistered in which case they will be forwarded to the CoA
associated with BID2 (i.e., CoA2). All TCP packets on port 123 will
be dropped. All other packets will be forwarded to CoA1 unless it is
deregistered, in which case they will be forwarded to CoA2 and then
to CoA3.
Implementation notes:
The Filter Rule priority is defined by the Priority field in the
FID
The BID Priority field defines implicitly the order in which the
BIDs are used when some of them are deregistered without any
further changes.
When a BID is deregistered, any filter rules that points to that
BID as the only BID is removed. If the BID is included as part of
a list of BIDs, then that BID is removed but the rest of the
filter rule remains intact.
Tsirtsis, et al. Expires November 5, 2007 [Page 27]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
Authors' Addresses
George Tsirtsis
Qualcomm
Phone: +908-947-7059
Email: tsirtsis@qualcomm.com
Vincent Park
Qualcomm
Phone: +908-947-7084
Email: vpark@qualcomm.com
Hesham Soliman
Elevate Technologies
Phone: +614-111-410-445
Email: hesham@elevatemobile.com
Tsirtsis, et al. Expires November 5, 2007 [Page 28]
Internet-Draft Flow Movement for Mobile IPv4 May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Tsirtsis, et al. Expires November 5, 2007 [Page 29]
| PAFTECH AB 2003-2026 | 2026-04-23 21:08:07 |