RO Extensions for PMIPv6-LR (ROEXT)
draft-boc-netext-lr-roext-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Michael Math Boc , Christophe Janneteau , Alexandre Petrescu | ||
| Last updated | 2012-10-22 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-boc-netext-lr-roext-04
Network Working Group M. Boc
Internet-Draft C. Janneteau
Intended status: Informational A. Petrescu
Expires: April 25, 2013 CEA
October 22, 2012
RO Extensions for PMIPv6-LR (ROEXT)
draft-boc-netext-lr-roext-04.txt
Abstract
The communication path between two Hosts within a Proxy Mobile IPv6
domain is artificially long - it involves the LMA, even if straight
paths exist (under same MAG, or MAG-to-MAG). Localized Routing
PMIPv6-LR concepts developped by NETEXT WG make use of LRI/LRA
messages to achieve optimized MAG-to-MAG straight paths. This may
prove inconvenient for the network operator, in that it may loose
ability to control traffic (LMA control point is skipped).
In this draft we present a middle-ground solution. It employs new
Intermediary Anchors (IAs) in the paths between MAGs and offers
points of control of traffic useful for QoS and lawful interception.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2013.
Copyright Notice
Copyright (c) 2012 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
Boc, et al. Expires April 25, 2013 [Page 1]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Boc, et al. Expires April 25, 2013 [Page 2]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Concentrated Description . . . . . . . . . . . . . . . . . . . 5
3. LMA Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 9
4. MAG Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 10
5. IA Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Boc, et al. Expires April 25, 2013 [Page 3]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
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].
Boc, et al. Expires April 25, 2013 [Page 4]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
2. Concentrated Description
The work presented in this draft is developped in the context of
Proxy Mobile IPv6 [RFC5213] and uses LRI/LRA messages used by
Localized Routing [I-D.ietf-netext-pmip-lr].
The relevant scenarios are represented by communication between two
Hosts typically situated each under a different MAG.
----- -----
| LMA | | LMA |
----- -----
/ \ / \
/ / \ \ / \
/ / \ \ / \signalling
/ /T1 \ \T2 / \
/ \ / \
----- ----- / \
| MAG1| | MAG2| / \
----- ----- ----- ================== -----
| | | MAG1| Direct Tunnel | MAG2|
| | ----- -----
--|-- --|-- | |
|Host1| |Host2| --|-- --|--
----- ----- |Host1| |Host2|
----- -----
In this figure, on the left side, the established tunnels T1 and T2
for communication between Host1 and Host2 are shown, after the Proxy
Mobile IPv6 protocol has executed. Each tunnel is established
between LMA and the MAG under which a Host is attached. This
illustration is typically used to express a problem of too long
communication paths.
In the right part of the same figure, the Direct Tunnel between two
MAGs is illustrated as a solution to the problem of artificially long
paths through LMA. This is achieved by using Localized Routing
concepts of Proxy Mobile IPv6. The diagonal lines represent
signalling (not wires).
There may exist situations when MAG-LMA-MAG communication paths are
too long and yet the straight MAG-MAG paths may prove disadvantageous
in terms of loss of operator control on various aspects of the
traffic. A middle ground solution as a bent arch path (not fully
Boc, et al. Expires April 25, 2013 [Page 5]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
triangular, not fully straight) may be needed.
-----
| LMA |
-----
/ | \
/ | \
/ | \signalling
/ | \
/ | \
/ | \
/ ---- \
----- =====| IA |======= -----
| MAG1| T1 ---- T2 | MAG2|
----- -----
| |
--|-- --|--
|Host1| |Host2|
----- -----
In this figure a new entity is added between MAGs - the Intermediate
Anchor (IA). The tunnels T1 and T2 are established between the IA
and the two MAGs respectively (instead of LMA). The IA serves
purposes such as ensuring a certain level of control over the route
optimized traffic, such as providing a certain level of Quality-of-
Service, or, potentially, enabling data traffic enforcement for
lawful interception. Several such IAs may be placed at strategic
points within the Proxy Mobile IPv6 domain.
The LMA is pre-configured statically with information about the IP
addresses of all MAGs, and, new, IAs in the Proxy Mobile IPv6 domain.
To illustrate this procedure in a generic manner, we consider two IAs
instead of one. In the following figure, we assume that IA1 and IA2
are positioned in a "sequential" manner between the MAG1 and MAG2.
This is to illustrate that the mechanism pertains to situations where
more IAs are used, and not only one.
Initially, H1 and H2 exchange Data through the tunnels setup by Proxy
Mobile IPv6, via LMA and the respective MAGs (the first 4 double-
arrowed lines at the top of the illustration) .
Boc, et al. Expires April 25, 2013 [Page 6]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
H1 H2 MAG1 MAG2 IA1 IA2 LMA
| | Data | | | | |
|<---------------->| | | | Data |
| | |<--------------------------------->|
| | | | | | Data | via LMA
| | | Data |<----------------------->| and MAG
| |<----------------->| | | |
| | | | | | |
| | |[Trigger RO procedure] |LRI_IA1 |
| | | | |<---------------|
| | | | |LRA_IA1| |
| | | | |--------------->|
| | | | | |LRI_IA2 | RO
| | | | | |<-------| configure
| | | | | |LRA_IA2 |
| | | | | |------->|
| | | LRI_MAG1 | | |
| | |<--------------------------------- |
| | | LRA_MAG1 | | |
| | |---------------------------------->|
| | | | LRI_MAG2 | |
| | | |<------------------------|
| | | | LRA_MAG2 | |
| | | |------------------------>|
| Data | | | | |
|<---------------->| Data | | | |
| | |<---------------->| | |
| | | | | Data | |
| | | | |<----->| |
| | | | Data | | | via IA
| | | |<-------------->| | and MAG
| | Data | | | | |
| |<----------------->| | | |
Subsequently, a certain trigger (to be defined) starts the Route
Optimization procedure. The procedure consists in LRI and LRA
messages. The LMA sends an LRI to IA1 and to IA2 respectively. In a
same centralized manner, LMA sends the same type of messages to MAG1
and MAG2 respectively. There are as many LRI messages as there are
IAs plus (always) two MAGs. The LRI messages instruct the receivers
about the IP addresses of the entities in question. For example,
LRI_IA1 informs IA1 about the IP address of IA2.
When the last LRA has been received from a second MAG, it can be
considered that the paths have been "route optimized", i.e. LMA is
no longer in the path. The Data traffic between H1 and H2 is
exchanged via IAs and MAGs exclusively (LMA is skipped).
Boc, et al. Expires April 25, 2013 [Page 7]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
The following diagram shows a modified LRI 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|S|I| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'I' flag: if set to 1 it indicates that this message is for an
Intermediate Anchor.
The following diagram shows a modified LRA message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|U|I| Reserved| Status | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'I' flag: if set to 1 it indicates that this message is is sent by an
Intermediate Anchor.
Boc, et al. Expires April 25, 2013 [Page 8]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
3. LMA Behaviour
LMA is pre-configured with each address of each MAG and of each IA in
the Proxy Mobile IPv6 domain. In addition, it has topology
information about the placement of these entities (IA, MAG) with
respect to each other, and can know the IP distances (hopcount)
between each to each other. For example, for two given MAGs, it
knows the shortest path and the IP addresses of the intervening IAs.
LMA is expecting a trigger indicating that the Route Optimization
procedure should start. This trigger is to be defined. In one
sense, LMA could deduce this trigger when its Binding Cache is
updated. Speculatively, the addresses stored in the Binding Cache
could indicate that two Hosts are under MAGs of same LMA, and that
their tunnels are using LMA.
The LMA emits LRI messages and, for each LRI sent it waits for an
LRA. It sends the following LRI only when the preceding LRI has been
arcknowledged by an LRA.
Boc, et al. Expires April 25, 2013 [Page 9]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
4. MAG Behaviour
MAG receives LRI messages, and does not generate such. When LRI is
received, it executes indications contained in it. Upon completion,
it sends LRA to the originator of the LRI (the LMA) explaining the
success or error of execution. MAG does not receive LRA.
Boc, et al. Expires April 25, 2013 [Page 10]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
5. IA Behaviour
IA behaviour is similar to that of MAG.
Boc, et al. Expires April 25, 2013 [Page 11]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
6. Security Considerations
Lawful interception is probably the single most unique kind of
requirement difficult to fit within the otherwise very powerful
security architecture of Internet. It is not immediately obvious
whether techniques addressing this particular requirement effectively
influence or are influenced by Internet security.
LRI and LRA messages should be protected by using IPsec.
Boc, et al. Expires April 25, 2013 [Page 12]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
7. Acknowledgements
Other than Authors, a number of persons are involved with
implementation and protection of this technique. For example,
Sofiane Imadali is designing and implementing a testbed prototype
with C, linux and Ethernet, under wise guidance of advisor.
Administratively, this work has been performed in the framework of
CELTIC project CP7-011 MEVICO. The authors would like to acknowledge
the contributions of their colleagues, although the views expressed
are those of the authors and do not necessarily represent the
project.
Boc, et al. Expires April 25, 2013 [Page 13]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
8. Normative References
[I-D.ietf-netext-pmip-lr]
Krishnan, S., Koodli, R., Loureiro, P., Wu, W., and A.
Dutta, "Localized Routing for Proxy Mobile IPv6",
draft-ietf-netext-pmip-lr-10 (work in progress), May 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
Boc, et al. Expires April 25, 2013 [Page 14]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
Appendix A. ChangeLog
The changes are listed in reverse chronological order, most recent
changes appearing at the top of the list.
From draft-boc-netext-lr-roext-03.txt to
draft-boc-netext-lr-roext-04.txt:
o Date change, no content change.
From draft-boc-netext-lr-roext-01.txt to
draft-boc-netext-lr-roext-02.txt:
o Changed affiliation from "CEA LIST" to "CEA, LIST" to respect
local guidelines.
From draft-boc-netext-lr-roext-00.txt to
draft-boc-netext-lr-roext-01.txt:
o The -00 version was mostly a placeholder. Now with -01 we updated
the message exchange diagram and added its respective explanatory
text.
o Added new sections intended to describe behaviour per entity (LMA,
IA, MAG).
Boc, et al. Expires April 25, 2013 [Page 15]
Internet-Draft RO Extensions for PMIPv6-LR (ROEXT) October 2012
Authors' Addresses
Michael Mathias Boc
CEA, LIST
Communicating Systems Laboratory, Point Courrier 173
Gif-sur-Yvette, F-91191
France
Phone: +33 169083976
Email: michael.boc@cea.fr
Christophe Janneteau
CEA, LIST
Communicating Systems Laboratory, Point Courrier 173
Gif-sur-Yvette, F-91191
France
Phone: +33 (0) 169089182
Email: christophe.janneteau@cea.fr
Alexandru Petrescu
CEA, LIST
Communicating Systems Laboratory, Point Courrier 173
Gif-sur-Yvette, F-91191
France
Phone: +33 (0) 169089223
Email: alexandru.petrescu@cea.fr
Boc, et al. Expires April 25, 2013 [Page 16]