One document matched: draft-wu-netext-local-ro-00.txt
Network Working Group Q.Wu
B.Sarikaya
Internet Draft Huawei Technologies
Intended status: Standard Track March 4, 2009
Expires: September 2009
Proxy MIP extension for local routing optimization
draft-wu-netext-local-ro-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
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 September 4, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wu,et al. Expires September 4, 2009 [Page 1]
Internet-Draft Proxy MIP Extension for local routing March 2009
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.
Abstract
Proxy Mobile IPv6 allows the Mobility Access Gateway (MAG) to
optimize the media delivery by locally routing the packets within one
MAG, However it does not support optimization of the media delivery
by locally routing the packets between MAGs sharing the same LMA.
This document specifies extensions for Proxy MIP to support local
routing optimization through the interaction between the MAG and the
LMA.
Table of Contents
1. Introduction.................................................3
2. Conventions used in this document............................3
3. Scenarios for local routing optimization.....................4
3.1. Intra-MAG local routing.................................4
3.2. Intra-LMA local routing.................................5
4. Local routing optimization protocol overview.................6
4.1. MAG initiated local routing optimization................6
4.2. LMA initiated local routing optimization................7
5. Conceptual Data Structure Extension..........................7
5.1. Binding Update List Extension...........................7
6. Local routing optimization message format....................8
6.1. Routing optimization mobility option....................8
6.2. Routing optimization Request message....................9
6.3. Routing optimization Response Message..................10
7. Process consideration.......................................12
7.1. Mobile Access Gateway Consideration....................12
7.2. Local Mobility Anchor Consideration....................14
8. IPv4 support................................................14
9. Security Considerations.....................................15
10. IANA Considerations........................................15
11. References.................................................15
11.1. Normative References..................................15
11.2. Informative References................................16
Wu,et al. Expires September 4, 2009 [Page 2]
Internet-Draft Proxy MIP Extension for local routing March 2009
1. Introduction
Proxy Mobile IPv6 [RFC5213] can allow the Mobility Access Gateway
(MAG) to optimize the media delivery by locally routing the packets
within one MAG and by not reverse tunneling them to the mobile node's
local mobility anchor (LMA). However it does not address the case of
routing optimization between two MAGs sharing the same LMA. The
capability for local routing optimization provided in [RFC5213]
requires the MAG to support the EnableMAGLocalRouting flag and allow
the MAG to control local routing optimization behavior. However,
[RFC5213] does not define how local routing optimization capability
is detected, who initiates local routing optimization and how to
negotiate between the MAG and the LMA to determine whether the local
routing optimization is allowed.
This document describes a routing optimization mobility option for
proxy mobile ipv6 that is intended to assist the MAG to make specific
choice for local routing optimization with LMA involvement. The new
mobility routing optimization option may be used between the LMA and
the MAG to enable local forwarding with LMA involvement, in each
initial binding update that makes a new registration to the LMA, or
in other local forwarding control messages (e.g., as defined in
[I-D.localFwd]). As [RFC5213] warns, use of local routing may affect
accounting and traffic policies relating to the mobile node, home
agent routing policies, and security policies. The general aim of the
proposals in this document is to provide better manageability of
mobility services and mobility service provisioning from the point of
view of both operators and service providers within one PMIPv6 domain.
2. Conventions used in this document
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
The document uses the terminology specified in [RFC5213] and in
[RFC3775]. In addition, this document defines the following:
Local routing: Traffic between MN and CN does not pass through LMA
and is locally routed.
Routing Optimization Request (RORQ) A message initiated by the MAG or
LMA requesting the MAG to establish local routing optimization for a
pair of MNs who communicate with each other.
Wu,et al. Expires September 4, 2009 [Page 3]
Internet-Draft Proxy MIP Extension for local routing March 2009
Routing Optimization Response (RORP) A reply message from the MAG or
LMA to confirm local routing optimization results.
3. Scenarios for local routing optimization
In this section, we introduce two scenarios that illustrate how the
route optimization technique can be applied to PMIPv6 and discuss
these techniques in details.
3.1. Intra-MAG local routing
+----------+
| |
| LMA |
| |
+----------+
|
|
/----------\
///// \\\\\
| BACKBONE |
| Network |
\\\\ ////
/ \----------/ \
/ \
+----/--+ +---\----+
| | | |
| MAG1 | | MAG2 |
+------ + +------- +
/ \
/ \
/ \
+--/---+ +\-----+
| | | |
| MN | | CN |
+------+ +------+
Figure 1: Intra MAG Local Routing Scenario
Figure 1 shows intra-MAG local routing within a PMIPv6 domain, the
case dealt with in [RFC5213]. It is assumed that MN movement is
intra-MAG, and that the MN and CN belong to the same PMIPv6 domain.
Routing between the MN and CN in the absence of optimization requires
tunneling to the LMA and back again. Routing optimization establishes
a more direct path between the MN and CN via the MAG, thus reducing
the end-to-end delay in delivery of media.
Wu,et al. Expires September 4, 2009 [Page 4]
Internet-Draft Proxy MIP Extension for local routing March 2009
3.2. Intra-LMA local routing
+-----------+
| |
| LMA |
| |
+-----------+
|
-----|-----
/// \\\
// \\
| |
| BACKBONE |
| Network |
/\ \/
/ \\\ /// \
/ ----------- \
/ \
/ \
+-----------+ +---------+
| | | |
| MAG1 | |MAG2 |
| | | |
+-----------+ +---------+
+--\--+ +---/---+
| | | |
| MN | | CN |
+-----+ +-------+
Figure 2: Intra LMA Local Routing Scenario
Figure 2 shows intra-LMA local routing within a PMIPv6 domain. If
movement of the MN is intra-MAG, previously-established routing
optimization is unaffected, so this scenario assumes that:
o the MN moves between MAGs sharing the same LMA,
o the CN is attached to a MAG also served by that LMA,
o and in its new position the MN is attached to a different MAG from
the CN.
As in the intra-MAG scenario, unoptimized routing involves tunneling
to the LMA and back again. There is an opportunity for routing
optimization in this scenario, too, by establishing a tunnel directly
between the two MAGs. [RFC5213] does not deal with this case.
Wu,et al. Expires September 4, 2009 [Page 5]
Internet-Draft Proxy MIP Extension for local routing March 2009
4. Local routing optimization protocol overview
The protocol specified here assumes that the MAG and the LMA are
situated in one PMIP domain. The MAG has the capability to perceive
intra-MAG local routing (i.e., in the intra-MAG local routing
scenario, the MAG can detect whether the mobile node and
correspondent node attach to the same MAG by checking binding update
list). The LMA has the capability to perceive intra-LMA local routing
(i.e., in the intra-LMA local routing scenario, the LMA can detect
whether the MAGs to which MN and CN are attach belong to the same LMA
by checking its binding cache list). The flag
EnableDetectLocalRouting on the MAG and LMA may be used to control
this behavior. The decision to enable/disable detection of local
routing should be based on the policy configured on the MAG or LMA.
The specific details on how this is achieved are beyond of the scope
of this document. Subsequently there are two modes in which the local
routing optimization protocol operates.
4.1. MAG initiated local routing optimization
When the MAG perceives intra-MAG local routing, it can initiate local
routing optimization to determine the value of the localMAGrouting
(defined in section 5) flag by message exchange between the MAG and
LMA. When the MAG can not perceive intra-MAG local routing but want
to check whether intra-LMA routing is allowed, it also can initiate
the local routing optimization. The message may be an initial binding
update message which contains the routing optimization mobility
option and home network prefix option for the correspondent node or a
newly defined routing optimization message. It will be used to
negotiate with LMA to determine whether or not the local routing
optimization between the mobile node and correspondent node is
supported. If the LMA does not allow the MAG bypass traffic from
itself, it will respond to the MAG that the local routing
optimization is not available. Otherwise it will set the
localMAGrouting flag on the MAG into value one by sending successful
response message.
After successful local routing optimization process, the MAG1 which
the MN is associated with may send PBU message to the MAG2 which the
CN is associated with. This PBU message sets the lifetime of the
binding of MN at MAG2. Similarly the MAG2 sends PBU message to the
MAG1. This PBU message sets the lifetime of the binding of CN at MAG1.
Each PBU MUST be acknowledged with PBAs. PBU-PBA exchange is
repeated to extend the lifetime of the binding.
Wu,et al. Expires September 4, 2009 [Page 6]
Internet-Draft Proxy MIP Extension for local routing March 2009
For the data traffic, either of the MAGs can lookup local routing
flag and process traffic in terms of the value of LocalMAGrouting
flag. If the LocalMAGrouting flag is set to value one, the traffic
from MN will go directly to CN via MAG. If the localLMArouting flag
is set to value one, the traffic from MN will be forwarded directly
to the MAG associated with the CN.
In case of handover, registration entry for MN in MAG1's Binding
update list should be transferred to the new MAG. The new MAG sends
PBUs to each MAG MN was in communication with route optimization
established. This PBU- PBA exchange reestablishes optimal route path
between MN and its CNs.
4.2. LMA initiated local routing optimization
When the LMA perceives intra-LMA local routing, it can initiate local
routing optimization to determine the value of localLMArouting flag
(defined in section 5) by message exchange between the MAG and LMA.
The message could be initial binding update message which contain
routing optimization mobility option or a newly defined routing
optimization message. It will be used to notify MAG to determine
whether or not the local routing optimization is supported. If the
LMA verifies there exists binding cache list of correspondent node
and mobile node and allow the MAG bypass traffic between mobile node
and correspondent node from itself, it will notify the MAG to set the
LocalLMArouting flag into value one, otherwise, it will respond to
MAG with failure information which indicate the intra-LMA routing
optimization is not supported.
5. Conceptual Data Structure Extension
5.1. Binding Update List Extension
Every mobile access gateway maintains a Binding Update List. Each
Entry in the Binding Update List represents a mobile node's mobility
binding with its local mobility anchor, as described in Section 6.1
of the PMIPv6 specification [RFC5213]. This specification extends the
Binding Update List Entry data structure with the following
additional fields:
LocalMAGRouting Flag indicating whether the media delivery
optimization is allowed by locally routing the packets within one MAG.
The flag is set to value 1 for local media delivery optimization is
allowed and vice versa.
Wu,et al. Expires September 4, 2009 [Page 7]
Internet-Draft Proxy MIP Extension for local routing March 2009
LocalLMARouting Flag indicating whether the media delivery
optimization is allowed by locally routing the packets from one MAG
to another within one LMA. The flag is set to value 1 for local media
delivery optimization is allowed and vice versa.
Home network prefix assigned to Correspondent Node
Proxy Care-of Address assigned to Correspondent Node
6. Local routing optimization message format
6.1. Routing optimization mobility option
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 = TBD | Length | Reserved |ROI~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Routing Optimization Mobility Option
Type TBD
Length
8-bit unsigned integer indicating the length of the option in octets,
excluding the type and length fields. This field MUST be set to 2.
Reserved (R)
This 8-bit field is unused for now. The value MUST be initialized to
0 by the sender and MUST be ignored by the receiver.
Routing Optimization Indication (ROI)
0: Reserved
1: The value of LocalMAGRouting
2: The value of LocalLMARouting
3: Routing optimization state is unknown or routing optimization is
not available.
Wu,et al. Expires September 4, 2009 [Page 8]
Internet-Draft Proxy MIP Extension for local routing March 2009
6.2. Routing optimization Request 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|ROI| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Routing Optimization Request 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 routing optimization request
message.
Routing Optimization Indication (ROI)
00: Reserved
01: The value of LocalMAGRouting
10: The value of LocalLMARouting
11: Routing optimization state is unknown or routing optimization is
not available.
Lifetime: The requested time in seconds for which the sender wishes
to have local routing.
Wu,et al. Expires September 4, 2009 [Page 9]
Internet-Draft Proxy MIP Extension for local routing March 2009
6.3. Routing optimization Response 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|ROI| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Routing Optimization Response 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 routing optimization request
message. Set to 1, indicates it is an routing optimization response
message.
Routing Optimization Indication (ROI)
00: Reserved
01: The value of LocalMAGRouting
10: The value of LocalLMARouting
11: Routing optimization state is unknown or routing optimization is
not available.
Lifetime: The requested time in seconds for which the sender wishes
to have local routing.
Mobility options: Routing optimization mobility option described in
section 6.1 and MN-CN pair mobility option described in section 6.4
can be included.
6.4. MN and CN pair mobility option
A new option, MN-CN pair mobility option is defined for use with the
Route Optimization Request and Response messages exchanged between LMA
Wu,et al. Expires September 4, 2009 [Page 10]
Internet-Draft Proxy MIP Extension for local routing March 2009
and MAGs. This option is used by the LMA to enable local routing for MN
to CN path from the destination MAG that receives the request message
towards CN connected a different MAG whose address is given in option.
The option MUST be used in pairs, one for MN and one for CN. The order
is important. The LMA places the data for MN to which the destination
MAG is connected first.
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 |P| Reserved |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Proxy CoA +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 HoA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Proxy CoA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: MN-CA pair mobility option
P Flag
P flag is set for IPv4 support. When set IPv4 HoA and IPv4 Proxy CoA
fields must be included for MN or CN.
Reserved
This 7-bit field is unused for now. The value MUST be initialized to
0 by the sender and MUST be ignored by the receiver.
Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option.
Wu,et al. Expires September 4, 2009 [Page 11]
Internet-Draft Proxy MIP Extension for local routing March 2009
Home Network Prefix
A sixteen-byte field containing the mobile or corresponding node's
IPv6 Home Network Prefix.
Proxy CoA
A sixteen-byte field containing the global address configured on the
egress interface of the mobile access gateway to which the mobile or
corresponding node is connected.
IPv4 HoA
Optional 32-bit field containing IPv4 home address of the mobile or
corresponding node.
IPv4 Proxy CoA
Optional 32-bit field containing IPv4 address that is configured on
the egress-interface of the mobile access gateway.
7. Process consideration
7.1. Mobile Access Gateway Consideration
The MAG may include the routing optimization mobility option and the
correspondent node's home network prefix option into initial binding
update message or create a new routing optimization request message
in which the above two options are contained. The routing
optimization mobility option is used to negotiate which kind of local
routing optimization is available. The correspondent node's home
network prefix option is used for the LMA to verify the validity of
local routing optimization path end points (in the intra-MAG local
routing scenario) or to request the LMA to determine proxy CoA-
Address of correspondent node for local routing optimization (in the
intra-LMA local routing scenario). In the intra-MAG local routing
case, ROI field in routing optimization mobility option is set into
value 1 while in the intra-LMA local routing case, ROI field in
routing optimization mobility option is set into value 0 for mobile
node's MAG does not know whether traffic between MN and CN can be
locally routed within one LMA.
If the MAG receives initial binding acknowledge message with routing
optimization mobility option or routing optimization response message,
it will extract the ROI field from the routing optimization mobility
option or routing optimization response message and check the value
of it. If ROI field is 0, it indicates the LMA does not support this
Wu,et al. Expires September 4, 2009 [Page 12]
Internet-Draft Proxy MIP Extension for local routing March 2009
local routing optimization and the MAG should set LocalMAGRouting
flag to value 0 in the binding update list extension; if ROI field is
1, it indicates the LMA allow local routing in one MAG and bypass the
LMA and MAG should set LocalMAGRouting flag to value 1 in the binding
update list extension, if ROI field is 2, it indicates LMA has find
correspondent node's MAG address in terms of home network prefix of
CN and MAG should extract correspondent node's MAG address from
initial binding acknowledge message or routing optimization response
message and store it in binding update list extension with
correspondent node's home network prefix.
Upon the LocalMAGrouting flag or LocalLMArouting flag setup at the
MAGs, one MAG may send the proxy binding update message to another
MAG to establish corresponding binding cache associated with the MN
and CN. Upon receiving Proxy Binding Update message, the MAG checks
if the EnableLMALocalRouting flag is set to one. If the
EnableLMALocalRouting flag is not set to one, the MAG MUST reject the
request and send a Proxy Binding Acknowledgement message with the
status field set to 129 (administratively prohibited).
Upon accepting Proxy Binding Update request, the MAG MUST create a
Binding Cache entry. The Source address of Proxy Binding Update is
copied to Proxy CoA field of the binding cache entry. The Mobile
node data (MN- Identifier, link-layer identifier, link-local address,
home network prefixes, etc.) are copied from the corresponding
fields of the proxy binding update.
Upon accepting Proxy Binding Update request for the first time from
another MAG, the MAG MUST establish a bi-directional tunnel between
the two MAGs. The tunnel endpoints are the Proxy-CoA of this mobile
access gateway and the Proxy-CoA of the mobile access gateway that
sent Proxy Binding Update as can be obtained from the source address
of Proxy Binding Update. This tunnel should be deleted when there
are no mobile nodes sharing it or when mobile access gateway receives
RORQ message from local mobility anchor with lifetime set to zero.
When using IPv4 transport, the endpoints of the bi-directional tunnel
are IPv4-Proxy-CoA of the mobile access gateway that sent Proxy
Binding Update as can be obtained from the source address of Proxy
Binding Update and IPv4-Proxy-CoA of this mobile access gateway with
the encapsulation mode as specified in [I-D.ietf-netlmm-pmip6-ipv4-
support].
For the data traffic between the MN and CN, on receiving a packet
from a mobile node connected to its access link, to a destination
that is directly connected or not directly connected, the MAG will
lookup local routing flag and process traffic in terms of
Wu,et al. Expires September 4, 2009 [Page 13]
Internet-Draft Proxy MIP Extension for local routing March 2009
LocalMAGrouting flag or LocalMAGrouting flag. If the
EnableLMALocalRouting flag is set to one and the destination address
matches one of the home network prefixes in the binding cache, the
packet must be forwarded to the Proxy CoA field in the binding cache
entry as a tunneled packet. For the packet from a mobile node
connected to its access link,to a destination that is also directly
connected to the same access link, if the EnableMAGLocalrouting flag
is set to one, the packet must go directly via the MAG.
7.2. Local Mobility Anchor Consideration
For the case where the MAG initiates local routing, upon receiving
initial binding update message or routing optimization request
message, the LMA will check ROI field in the routing optimization
mobility option or routing optimization message. If ROI field is 1,
the LMA will check whether there exists binding cache list for CN and
whether MN's proxy CoA address is same as CN's proxy CoA address. If
ROI field is 0 and correspondent node's home network prefix included,
the LMA will check whether there exists binding cache list for CN in
terms of the correspondent node's home network prefix. If does, the
LMA will respond to the MAG with ROI field set to value 2.Otherwise,
the LMA will respond to the MAG with ROI field set to 0 in the
routing optimization mobility option to indicate the MAG that the
local routing optimization is not available. For the case where the
LMA initiates local routing, upon perceiving intra-LMA routing, the
LMA sends routing optimization request message with the ROI field set
to value 2. And then the LMA receives routing optimization reply
message from the corresponding MAG.
8. IPv4 support
IPv4 support is needed in two cases: MN is IPv4 enabled and receives
IPv4 home address and the transport network between the LMA and the
MAG is an IPv4 network. Local route optimization can be supported
if both IPv4 home address (IPv4-MN-HoA) and IPv4 Proxy Care-of
Address at the MAGs are global addresses.
Initially, both the MN and the CN configure IPv4 home addresses by
exchanging PBU/PBA as explained in [I-D.ietf-netlmm-pmip6-ipv4-
support] with the LMA.
The LMA MUST include IPv4 IPv4-MN-HoA in routing optimization
request message for both MN and CN. The LMA MAY include Home
Network Prefix in PBU if the MN or CN is assigned Home Network
Prefix. Both routing optimization request and routing optimization
response messages are IPv6 messages and are transported on LMA-MAG
tunnel as PBU and PBA are transported.
Wu,et al. Expires September 4, 2009 [Page 14]
Internet-Draft Proxy MIP Extension for local routing March 2009
The PBU and PBA exchanged between the MAGs are IPv6 messages and are
transported as unencapsulated IPv6 messages between MAGs. Data
messages between the MAGs after local routing is established are
transported in in IPv6 as IPv4 payload.
When IPv4 transport is used, RORQ, RORP, PBU and PBA messages are
transported as IPv6 messages using IPv4 or IPv4-UDP-ESP
encapsulation [I-D.ietf-netlmm-pmip6-ipv4-support]. IPv4-UDP and
IPv4-UDP-TLV modes are not used because no NAT boxes are supported
in local Routing Optimization protocol.
When IPv4 transport is used, IPv4 data packets are transported in an
IPv4 packet or encapsulated in IPv4-UDP-ESP encapsulation.
9. Security Considerations
The protocol specified in this document can use the security
association between the LMA and the MAG to create security
association between MAGs to which MN and CN attach in the intra-LMA
local routing scenario. As regarding intra-MAG local routing scenario,
integrity protection can be considered and confidentiality using
IPsec is not necessary.
10. IANA Considerations
This document has no actions for IANA.
11. Acknowledgement
The authors would like to thank Tom Taylor for his review and comments
of this draft and all colleagues who have supported the advancement of
this draft effort.
12. References
12.1. Normative References
[RFC3775] Johnson, D. and al. et, "Mobility Support in IPv6", RFC3775,
June 2004
[RFC5213] Gundavelli, S. and al. et, "Proxy Mobile IPv6", RFC5213,
May 2008.
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09
(work in progress), January 2009.
Wu,et al. Expires September 4, 2009 [Page 15]
Internet-Draft Proxy MIP Extension for local routing March 2009
12.2. Informative References
[I-D.LocalFwd]
Koodli,R., Chowdhury,K. "Local Forwarding in Proxy
Mobile IPv6", draft-koodli-netlmm-local-forwarding-00,
July 2008
Wu,et al. Expires September 4, 2009 [Page 16]
Internet-Draft Proxy MIP Extension for local routing March 2009
Authors' Addresses
Qin Wu
Huawei Technologies Co.,Ltd
Site B,Floor 12F,Huihong Mansion,No.91,Baixia Rd.
Nanjing 210001
China
Email: Sunseawq@huawei.com
Behcet Sarikaya
Huawei Technologies Co.,Ltd
1700 Alma Dr.Suite 500
Plano, TX 75075
USA
Email: sarikaya@ieee.org
Wu,et al. Expires September 4, 2009 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 15:08:19 |