Netext Working Group D. Oulai
Internet-Draft S. Krishnan
Intended status: Standards Track Ericsson
Expires: April 29, 2010 October 26, 2009
Optimized Local Routing for PMIPv6
draft-oulai-netext-opt-local-routing-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Oulai & Krishnan Expires April 29, 2010 [Page 1]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
Abstract
Base Proxy Mobile IPv6 requires all communications to go through the
local mobility anchor. As this can be suboptimal, local routing has
been defined to allow mobile nodes attached to the same or different
mobile access gateways to exchange traffic by using local forwarding
or a direct tunnel between the gateways. This document proposes an
initiation method and fast handover mechanisms for local routing.
The solutions aim at reducing handover delay and packet loss.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Local Routing Initialization . . . . . . . . . . . . . . . 7
4.2. Handover . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Non optimized handover . . . . . . . . . . . . . . . . 8
4.2.2. Optimized handover . . . . . . . . . . . . . . . . . . 11
4.3. IPv4 considerations . . . . . . . . . . . . . . . . . . . 12
5. Messages formats . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Local Routing Indication message . . . . . . . . . . . . . 13
5.2. Local Routing Acknowledge message . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Oulai & Krishnan Expires April 29, 2010 [Page 2]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
1. Introduction
Base Proxy Mobile IPv6 requires all communications to go through the
LMA [RFC5213]. In the case where both endpoints are located in the
same PMIPv6 domain, this can be suboptimal and results in higher
delay and congestion in the network. Moreover, it increases
transport costs and traffic load at the LMA.
To overcome this situation, local routing has been defined to allow
nodes attached to the same or different mobile access gateways to
exchange traffic by using local forwarding or a direct tunnel between
the gateways. [I-D.ietf-netext-pmip6-lr-ps] details the local
routing problem statement.
+----+
+------------|LMA |----------+
| +----+ |
| | |
| | |
| | |
| | |
+----+ +----+ +----+
|MAG1|==========|MAG2| |MAG3|
+----+ +----+ +----+
| |
=============================
+----+ +----+
|MN1 | |MN2 | -------->
+----+ +----+
Figure 1: Local Routing Scenario
Figure 1 defines a scenario where local routing could be used. MN1
and MN2 are communicating and are attached to the same PMIPv6 domain.
MN1 is attached to MAG1 and MN2 is initially attached to MAG2. The
LMA triggers the local routing by exchanging messages with the MAGs.
A tunnel is created between MAG1 and MAG2.
Regarding handover, suppose MN2 moves from MAG2 to MAG3. Based on
PMIPv6 specification, MN2 does an attach on MAG3. MAG3 performs
authentication then sends a PBU to the LMA. If there is no local
routing, the traffic is switched towards MAG3 at this point.
However, local routing imply that traffic from MN1 do not reach LMA
but is routed directly towards MAG2. Therefore, the LMA has to send
a message to MAG1 in order to switch traffic. This results in worst
handover performance than base PMIPv6.
Oulai & Krishnan Expires April 29, 2010 [Page 3]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
This document proposes an initiation method and two fast handover
mechanisms for PMIPv6 local routing. The solutions aim at reducing
handover delay and packet loss. They reused some PFMIPv6 concepts
[I-D.ietf-mipshop-pfmipv6] .
Oulai & Krishnan Expires April 29, 2010 [Page 4]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
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 [RFC2119].
Oulai & Krishnan Expires April 29, 2010 [Page 5]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
3. Terminology
All the general mobility-related terms used in this document are to
be interpreted as defined in the Mobile IPv6 [RFC3775] and Proxy
Mobile IPv6 [RFC5213] specifications as well as in
[I-D.ietf-netext-pmip6-lr-ps].
Local Routing Indication (LRI): message sent to the MAG by the LMA or
a peer MAG in a local routing session. This message triggers local
routing.
Local Routing Acknowledgement (LRA): message sent by the MAG to the
LMA or a peer MAG in a local routing session. This message
acknowledge a LRI message.
Oulai & Krishnan Expires April 29, 2010 [Page 6]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
4. Operations
The operations described here are based on the scenario presented in
Figure 1.
4.1. Local Routing Initialization
When the LMA notices that Local Routing should be initiated between
two MNs, it sends one LRI message to each MAG where the MNs are
attached. The LRI messages contains information to identify both
MNs, the target MAG which will be the other endpoint of the tunnel
and some data needed to establish a security association between the
MAGs. Note that we can have pre-established security associations
between the MAGs of the same PMIPv6 domain. The LRI MAY also
includes GRE Keys and a Tunnel mode option to indicate which type of
tunneling SHOULD be used between the MAGs. The Tunnel mode is
determined based on the information the LMA have on the MAGs
capabilities. Note that the tunnel mode MAY also be preconfigured
between MAGs.
If the MAG accepts to apply local routing, it sends a LRA message to
the LMA to acknowledge the Local Routing. At this point, the LMA
MUST not modify the binding of the MN as other communications MAY
still go through the LMA. The LMA MUST record that there is an
ongoing Local Routing session and also the involved MAGs and MNs.
How the charging is done when local routing is in place is out of
scope of this document.
Note also that this initiation mechanism can be extended to work in
scenarios where the MAGs are attached to different LMAs. In this
case, extra signalling will be required between the LMAs before they
initiate the local routing process. How the LMAs discover each
others is out of scope of this document.
Oulai & Krishnan Expires April 29, 2010 [Page 7]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
+----+ +----+ +----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG1| |MAG2| |MAG3| |LMA |
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | |
| data | | data | |
|<--------------------->|<------------------------------------->|
| | | | | |
| | data | data |
| |<--------------------->|<------------------------->|
| | | | | LR decision
| | | LRI(MN1,MN2,MAG2,Security,Tun_mode,GRE_Keys)
| | |<--------------------------------------|
| | | | | |
| | | LRI(MN2,MN1,MAG1,Security,Tun_mode,GRE_Keys)
| | | |<--------------------------|
| | | | | |
| | | | LRA(MN1,MN2,MAG2) |
| | |-------------------------------------->|
| | | | | |
| | | | LRA(MN2,MN1,MAG1) |
| | | |-------------------------->|
| | | | | |
| data | data | | |
|<--------------------->|<--------->| | |
| | | | | |
| | data | | |
| |<--------------------->| | |
| | | | | |
| | | | | |
Figure 2: Local Routing Initialization
4.2. Handover
The handover mechanisms proposed here are proactive. They are based
on the fact that the moving MN is able to send information to the MAG
it is still attached to about the target access point or MAG. Those
information are used by the old MAG to identify the target MAG. Note
that a MN which does not support this specification performs base
PMIPv6 handover and the LMA has to restart the Local Routing session
later.
4.2.1. Non optimized handover
In this mechanism, before moving to MAG3, MN2 sends a Handover
Initiate message to MAG2. This message MAY be L2 or L3 specific and
Oulai & Krishnan Expires April 29, 2010 [Page 8]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
MUST provide MAG2 with useful information to resolve MAG3's address.
For example, in 3GPP LTE networks, the Mobility Management Entity
(MME) may generate this message towards the old Serving Gateway with
the result that no modification is needed on the MN side. The
details of this message is out of scope for this document.
If the target MAG is different from MAG2, MAG2 sends a refresh PBU
message to the LMA containing a new flag indicating a possible
movement. When receiving this PBU, the LMA MUST not update the BCE
but rather abort the Local Routing sessions by sending a
deregistration LRI message to MAG1. Therefore, MAG1 switches back
the traffic towards the LMA. At this time, the traffic is asymmetric
as the local routing from MAG2 to MAG1 is unaffected. When the LMA
receives the PBU indicating the new attach point of MN2, it can start
over a new Local Routing session between MN1 and MN2. Figure 3 shows
this mechanism. Even if we refer to this method as non-optimized, it
allows to reduce packet loss and handover delay. Another option
could be for the LMA to send to MAG1 a LRI to directly set up the
tunnel towards MAG3.
Note also that this method can be applied without any specific fast
mobility mechanisms. The difference will be that instead of
resolving MAG3's address, MAG2 detects MN2's detach and send a
deregistration PBU as recommended by [RFC5213].
Oulai & Krishnan Expires April 29, 2010 [Page 9]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
+----+ +----+ +----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG1| |MAG2| |MAG3| |LMA |
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | |
| data | data | | |
|<-------------------->|<--------->| | |
| | data | | |
| |<--------------------->| | |
| HO decision | | | |
| HO_Init (MAG3 or Access Point) | |
| |---------------------->| | |
| | | | PBU |
| | | |---------------------->|
| | | | | |
| | | Dereg LRI(MN1,MN2,MAG2) |
| | |<----------------------------------|
| | | LRA(MN1,MN2,MAG2) |
| | |---------------------------------->|
| data | | data | |
|--------------------->|---------------------------------->|
| | data | data |
| |<----------------------|<----------------------|
| | data | | |
| |---------------------->| | |
| data | data | | |
|<---------------------|<----------| | |
| | | | | |
| | | Attach | | |
| |<--------------------------------->| |
| | | | | PBU |
| | | | |---------->|
| | | | | |
| | | LRI(MN1,MN2,MAG3,Security,Tun_mode,GRE_Keys)
| | |<----------------------------------|
| | | LRA(MN1,MN2,MAG3) |
| | |---------------------------------->|
| | | LRI(MN2,MN1,MAG1,Security,Tun_mode,GRE_Keys)
| | | | |<----------|
| | | | LRA(MN1,MN2,MAG1)
| | | | |---------->|
| data | data | |
|<-------------------->|<--------------------->| |
| | | data | | |
| |<--------------------------------->| |
| | | | | |
Figure 3: Non optimized handover
Oulai & Krishnan Expires April 29, 2010 [Page 10]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
4.2.2. Optimized handover
We assume here that Local Routing sessions MUST be maintained after
handover. Before moving to MAG3, MN2 sends a Handover Initiate
message to MAG2. MAG2 resolves MAG3 address. Then it sends a LRI
message to inform MAG1 that MN2 will be attached to MAG3. It also
sends a LRI message to inform MAG3 to start a Local Routing session
with MAG1. To perform this, there need to be SA between each MAG and
all its neighbour which support Local Routing and where a MN may
move. This SA is used to exchange LRI/LRA messages between MAG2 and
MAG3. After this, the Local Routing session is established between
MAG1 and MAG3. MN2 can resume communications right after attachment
with MAG3 if MAG3 advertises MN2's prefix before completing the PBU/
PBA exchange or packet may be buffered until the PBA is received by
MAG3. Figure 4 shows this mechanism. If this mechanism is used,
MAG3 MUST include an indication in the PBU to let the LMA know that
the LR session is now between MAG1 and MAG3.
In this method, MAG2 suggest a tunnelling mode and GRE Keys to MAG1
and MAG3. MAG2 SHOULD suggest the same tunnelling mode and GRE keys
he was using unless he has specific information allowing a more
accurate choice. In any case, if MAG1 and MAG3 rejects the
suggestion of MAG2, they MUST directly negotiate the tunnelling mode
and the GRE keys.
Another option could be for the MAG2 to send a LRI only to MAG3 in
order to establish temporary Local Routing session between MAG2 and
MAG3. Therefore, packets follow the path MAG1-MAG2-MAG3 during
handover and the normal Local Routing path is restored after
handover. However, this imply an additional tunnelling step and
requires the LMA to establish a direct LR session between MAG1 and
MAG3.
In case the MAGs are attached to different LMAs, extra inter-LMA
signalling is required to updated the LR states in each LMA.
Oulai & Krishnan Expires April 29, 2010 [Page 11]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
+----+ +----+ +----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG1| |MAG2| |MAG3| |LMA |
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | |
| data | data | | |
|<-------------------->|<--------->| | |
| | | | | |
| | data | | |
| |<--------------------->| | |
| HO decision | | | |
| HO_Init (MAG3 or Access Point) | |
| |---------------------->| | |
| | LRI(MN1,MN2,MAG3,Security,Tun_mode,GRE_Keys) |
| | |<----------| | |
| | LRI(MN1,MN2,MAG1,Security,Tun_mode,GRE_Keys)
| | | |--------->| |
| | LRA(MN1,MN2,MAG3) | |
| | |---------->| | |
| | | LRA(MN1,MN2,MAG1) |
| | | |<---------| |
| | | Attach | | |
| |<-------------------------------->| |
| data | data | |
|<-------------------->|<-------------------->| |
| | | | | |
| | | data | | |
| |<-------------------------------->| |
| | | | | PBU |
| | | | |---------->|
| | | | | PBA |
| | | | |<----------|
| | | | | |
Figure 4: Optimized handover
4.3. IPv4 considerations
In case of IPv4 Home Addresses used over IPv6 transport, the proposed
mechanisms works well and the chosen tunnelling mode MUST be IPv4
over IPv6. The GRE Keys MUST also be present to differentiate
private IPv4 HoAs.
If IPv4 transport is involved, the tunnelling mode suggested by MAG2
MAY not be accurate as NATs may be involved. In this case, unless
there are preconfigured tunnels, the MAGs MUST directly negotiate the
tunnelling mode.
Oulai & Krishnan Expires April 29, 2010 [Page 12]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
5. Messages formats
This protocol requires two new messages, Local Routing Indication
(LRI) and Local Routing Acknowledgement (LRA) messages. They use MH
type (IANA-TBD). Figure 5 shows the MH. If the Local Routing type
is set to 1, it is a Local Routing Indication message (Section 5.1).
If it is set to 2, it is a Local Routing Acknowledgement message
Section 5.2).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | LR Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. Local Routing Message Data .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Local Routing Message
Local Routing Type
8-bit unsigned integer. It defines the type of Local Routing
message. Assigned values are:
0 Reserved
1 Local Routing Indication Message
2 Local Routing Acknowledgement Message
Local Routing Message Data
It follows the format defined for the specific Local Routing
message (Section 5.1 and Section 5.2).
5.1. Local Routing Indication message
The LR type is set to 1. The format of the corresponding Local
Routing Message Data is depicted in Figure 6. There is a 2n
alignment for this message.
Oulai & Krishnan Expires April 29, 2010 [Page 13]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LR Type = 1 |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Local Routing Indication Message
Acknowledge bit (A)
Set to 1 to request a LRA message from the target MAG.
Reserved
Unused bits. Must be set to 0.
Sequence #
A 16-bit unsigned integer used by the LMA or a MAG to match a LRI
message with a LRA message.
Lifetime
A 16-bit unsigned integer used to define the lifetime of the Local
Routing session.
Mobility options
Variable length field. The Mobility header MUST be an integer
multiple of 8 octets long. There MUST be at least options present
to provide the source MN's address, the destination MN's address
and the target MAG address. This field can include options for
security and tunneling mode indication.
5.2. Local Routing Acknowledge message
The LRA is sent by the target MAG in response to a LRI message with
the A bit set. The LR type is set to 2. The format of the
corresponding Local Routing Message Data is depicted in Figure 7.
There is a 2n alignment for this message.
Oulai & Krishnan Expires April 29, 2010 [Page 14]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LR Type = 2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Local Routing Acknowledgement Message
Reserved
Unused bits. Must be set to 0.
Sequence #
A 16-bit unsigned integer used by the requesting entity to match a
LRI message with a LRA message. MUST be copied from the sequence
# receive in the LRI message.
Lifetime
A 16-bit unsigned integer. MUST be copied from the lifetime
receive in the LRI message.
Mobility options
Variable length field. The Mobility header MUST be an integer
multiple of 8 octets long. The options present in the LRI message
MUST be copied in the LRA message.
Oulai & Krishnan Expires April 29, 2010 [Page 15]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
6. Security Considerations
Message between the LMA and the MAGs MUST be exchanged using the
security associations existing for PBU/PBA messages. If inter-MAG
signaling messages are used, there MUST be a SA between the MAGs as a
malicious node can trigger a Local Routing session update.
Oulai & Krishnan Expires April 29, 2010 [Page 16]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
7. IANA Considerations
This specification requires type to be assigned for LRI and LRA
message.
Oulai & Krishnan Expires April 29, 2010 [Page 17]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
8. Normative References
[I-D.ietf-mipshop-pfmipv6]
Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6",
draft-ietf-mipshop-pfmipv6-09 (work in progress),
September 2009.
[I-D.ietf-netext-pmip6-lr-ps]
Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized
Routing Problem Statement",
draft-ietf-netext-pmip6-lr-ps-00 (work in progress),
September 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
Oulai & Krishnan Expires April 29, 2010 [Page 18]
Internet-Draft Optimized Local Routing for PMIPv6 October 2009
Authors' Addresses
Desire Oulai
Ericsson
8400 Blvd Decarie
Town of Mount Royal, Quebec
Canada
Email: desire.oulai@ericsson.com
Suresh Krishnan
Ericsson
8400 Blvd Decarie
Town of Mount Royal, Quebec
Canada
Email: Suresh.Krishnan@ericsson.com
Oulai & Krishnan Expires April 29, 2010 [Page 19]