NETEXT Dapeng Liu
Hui Deng
Internet Draft China Mobile
Yong Cui
Tsinghua University
Intended status: Standards Track October 19, 2009
Expires: April 2010
Signaling and data separation extension to PMIPv6
draft-liu-netext-singnaling-data-separation-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.
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 February, 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.
Dapeng Liu Expires April 19, 2010 [Page 1]
Internet-Draft Signaling and data separation of PMIPv6 October 2009
Abstract
The mobility management signaling of PMIPv6 includes PBU/PBA message.
Both messages use the IPv6 mobility header, which is an expansion of
IPv6 header, to carry signaling information. The transport protocol
has not been used, which can not guarantee the reliability of
transmission. This draft proposes to extend PMIP to make it has
transport protocol support and negotiation mechanism. The advantage
of this extension is that transport protocol can provide more
reliable transportation especially in the scenario that MAG and LMA
are connected by a congested IP network.
Table of Contents
1. Introduction................................................3
2. Conventions used in this document............................3
3. Motivation of signaling and data separation for PMIP..........3
3.1 Scenario................................................3
3.2 Experimental result of PMIP signaling transportation......4
4. Extensions of PBU/PBA........................................4
5. Negotiation Mechanism........................................5
6. Mobility Agent Considerations................................6
6.1. Mobility Access Gateway Considerations..................6
6.2. Local Mobile Anchor Considerations......................6
6.3. Compatibility..........................................6
7. Security Considerations......................................7
8. IANA Considerations.........................................7
9. Acknowledgments.............................................7
10. References.................................................7
10.1. Normative References...................................7
10.2. Informative References.................................7
Author's Addresses.............................................8
Dapeng Liu Expires April 19, 2010 [Page 2]
Internet-Draft Signaling and data separation of PMIPv6 October 2009
1. Introduction
RFC5213 specifies proxy mobile IPv6 which is different from MIPv6 in
many aspects but the signaling of PMIPv6 and MIPv6 has much
similarity. The mobility management signaling of PMIPv6 is mainly
PBU/PBA message. Both of them use IPv6 mobility header to carry
signaling information and do not use any transport layer protocol.
This design approach is inherited from MIPv6. MIPv6 use mobility
header enables IPv6 supporting mobility inherent, since MIPv6
requires the MN which has IPv6 protocol stack involved in mobility
management. Further more, IPv6 extension header facilitates MIPv6's
routing optimization.
For PMIP, there is not much benefit from using mobility header except
that the signaling format has much similarity with MIPv6 and then
enable the LMA could reuse the functionality of HA. Since PMIPv6 does
not use and transport layer protocol for signaling, there is no
guarantee for the signaling message would be transferred successfully.
The lost of mobility signaling message will lead to poor user
experience during handover or even break the functionality of PMIPv6.
This document proposes a new extension to PMIPv6 to make it support
transport layer protocol negotiation. Using this extension, operators
that deploy PMIPv6 in large scale and un-trusted network scenario
will guarantee the transportation of mobility signaling and thence
improve the user experience during handover.
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.
3. Motivation of signaling and data separation for PMIP
3.1 Scenario
The following figure describe that the scenarios that PMIPv6 may need
transport layer protocol for mobility signaling message. As
illustrated in figure 1, the LMA and MAG may be deployed by one
operator but the transport network between them may belong to another
operator. The operator that deploys the LMA and MAG have no control
of the transportation network so it can not optimize the transport
network to enable it provide better availability. For example, if the
PBU message lost during the transmission, the MAG would resend again,
but if the PBA message lost, the MAG will have no way to know whether
the PBA is lost during transmission or LMA have not finishing the
Dapeng Liu Expires April 19, 2010 [Page 3]
Internet-Draft Signaling and data separation of PMIPv6 October 2009
processing of the PBU message. This will cause problems during
handover. In this scenario, it is necessary to use transport protocol
to guarantee the availability of the transmission of mobility
signaling.
+----------------------------------------------- -----+
| +----+ |
| |LMA | |
| +----+ |
| | |
| +----------------------+ |
| | Un-trusted network | |
| +----------------------+ |
| | | |
| +---+ +---+ |
| |MAG| |MAG| |
| +---+ +---+ |
| MN |
+------------------------------------------------ ----+
Figure 1 scenario for using transport protocol for PMIP
3.2 Experimental result of PMIP signaling transportation
We have setup and PMIP demo to test the PMIP signaling transportation
issue when LMA and MAG are connected through large scale network. The
detail result will be included in the updated version of this
document.
4. Extensions of PBU/PBA
The extension of PBU/PBA is shown in Figure 2. It is an optional
extension. The purpose of this extension is used for the MAG and LMA
to negotiate whether they support the transport protocol and decide
which transport protocol to use.
0 1 2 30
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 | Transport protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |T|E|A|R|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Transport protocol negotiation option
The above option could be added in the mobility options section of
PBU and PBA. The definition of its various fields is as follows:
Dapeng Liu Expires April 19, 2010 [Page 4]
Internet-Draft Signaling and data separation of PMIPv6 October 2009
Type: the type of option, specific value to be determined.
Length: option length (number of bytes, excluding type and length
field).
Transport protocol Type: transport protocol type. Its value is as
follows:
001: SCTP Protocol.
002: TCP Protocol.
Others: To be determined.
Status: Its value as follows:
000: Negotiation successfully.
001: Using the transport protocol negotiations failed. The reason is:
LMA does not support this feature or do not want to use it.
002: Negotiation failed. The reason is: PBU issued by MAG with this
option in the wrong format.
003: Termination the use of transport protocol failed. The reason is:
the LMA could not be terminated the use of transport protocol
temporarily.
Others: To be determined.
Flag:
T: If this flag is set to 1, it means that MAG initiates the
negotiation of transport protocol.
E: If this flag is set to 1, it means that MAG wants to terminate the
using of transport protocol for transmit mobility signaling.
A: If this flag is set to 1, it means LMA agreed to the negotiation
request by MAG.
R: If this flag is set to 1, it means MAG refused the request of the
negotiation. The specific reason is given by the status code.
Reserved: reservation, and can be used for other expansion.
5. Negotiation Mechanism
When MAG wants to use transport protocol, it can send PBU to the LMA
with the transport protocol option which contains the transport
protocols it support and T field set to 1. When LMA receives PBU with
this option, if it agrees to use transport protocol for transmission,
it should select one transport protocol that listed by the PBU and
Dapeng Liu Expires April 19, 2010 [Page 5]
Internet-Draft Signaling and data separation of PMIPv6 October 2009
send PBA with transport protocol options and A filed set to 1. The
selected transport protocol is indicated by the Transport protocol
Type filed.
After the successful negotiation, the follow-up transport between the
PBU/PBA Message will use the transport protocol to provide
reliability. The signaling message will be put into the payload
section of the transport protocol.
LMA MAY send PBA with R filed set to 1 to reject the negotiation
request in error conditions. The MAG will then use the IPv6 mobility
header for signaling.
MAG can also send PBU with transport protocol negotiation options to
stop the use of transport protocol. When MAG wants to stop the use of
transport protocol, it MAY send PBU with E set to 1 to the LMA. LMA
received this PBU with this option. If LMA agrees to end the using of
transport protocol, LMA MAY send PBA with A set to 1. After that,
follow-up transport of signaling between MAG and LMA will no longer
use transport protocol. LMA MAY send PBA Message with R set to 1 to
reject this request in some conditions.
6. Mobility Agent Considerations
The following sections describe the behavior of the mobility agent in
detail.
6.1. Mobility Access Gateway Considerations
The MAG SHOULD send PBU with this extend option of the transport
protocol in accordance with the deployment scenario and management
strategy. The MAG should turn on/off this feature by configuration
files or FLAG.
6.2. Local Mobile Anchor Considerations
The LMA SHOULD send PBA with this extend Options of the transport
protocol in accordance with the deployment scenario and management
strategy to accept or reject MAG's request.
6.3. Compatibility
During the deployment, there may be a scenario that the MAG/LMA
supports this feature but the peering MAG/LMA does not support. This
scenario may happen during handover between different domains. In
Dapeng Liu Expires April 19, 2010 [Page 6]
Internet-Draft Signaling and data separation of PMIPv6 October 2009
this condition, the unsupported entity should discard this option and
the entity that support this option should stop trying after time out.
7. Security Considerations
TBD
8. IANA Considerations
This document requests IANA to allocate the application protocol
number for TCP/SCTP to indicate the payload is PMIPv6 mobility
signaling.
9. Acknowledgments
The authors want to thanks Basavaraj Patil from Nokia, Sri Gundavelli
from Cisco, Tianze Ma from Tsinghua University and Zhen Cao from CMCC
for their useful suggestions and discussions.
10. References
10.1. Normative References
[RFC2119] Bradner. S.. "Key words for use in RFCs to Indicate
Requirement Levels". BCP 14. RFC 2119. March 1997.
[RFC5555] H. Soliman. Ed. "Mobile IPv6 Support for Dual Stack Hosts
and Routers". RFC 5555. June 2009
[RFC5213] K. Leung. V. Devarapalli. K. Chowdhury and B. Patil. "Proxy
Mobile IPv6". RFC 5213. August 2008.
10.2. Informative References
G. Giaretta. Ed.. "Interactions between PMIPv6 and MIPv6: scenarios
and related issues". Internet Draft. June. 2009.
Dapeng Liu Expires April 19, 2010 [Page 7]
Internet-Draft Signaling and data separation of PMIPv6 October 2009
Author's Addresses
Dapeng Liu
China Mobile research institute
Unit2, 28 Xuanwumenxi Ave,Xuanwu District,
Beijing 100053, China
Phone: (8610)13911788933
Email: liudapeng@chinamobile.com
Hui Deng
China Mobile research institute
Unit2, 28 Xuanwumenxi Ave,Xuanwu District,
Beijing 100053, China
Phone: (8610)13910750201
Email: denghui@chinamobile.com
Dapeng Liu Expires April 19, 2010 [Page 8]