Network Working Group H. Deng
Internet-Draft China Mobile
Intended status: Standards Track October 30, 2008
Expires: May 3, 2009
Generic Mobility Management Protocol
draft-deng-gmmp-01
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 May 3, 2009.
Deng Expires May 3, 2009 [Page 1]
Internet-Draft GMMP October 2008
Abstract
This document discusses the communication protocol between mobile
access point and terminal. With the evolution of mobile
communication, there are various kind of wireless communication
technologies such as WCDMA, LTE, WLAN, WiMAX, and TDS-CDMA et al.
Each of these wireless communication technology has independent
connection, mobility and configuration management. This document
would like to cover all these functions into a common ground
especially in the environment of multiple connections.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Multiple Network Connections . . . . . . . . . . . . . . . . . 4
3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. GMMPCONNECT message . . . . . . . . . . . . . . . . . . . 7
4.2. GMMPDISCONNECT message . . . . . . . . . . . . . . . . . . 7
4.3. GMMPACK message . . . . . . . . . . . . . . . . . . . . . 8
4.4. GMMPCONFIG message . . . . . . . . . . . . . . . . . . . . 8
4.5. GMMPDECLINE message . . . . . . . . . . . . . . . . . . . 8
5. GMMP Options . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Client Identifier Option . . . . . . . . . . . . . . . . . 9
5.2. Server Identifier Option . . . . . . . . . . . . . . . . . 10
5.3. Client Address Option . . . . . . . . . . . . . . . . . . 10
5.4. Server Address Option . . . . . . . . . . . . . . . . . . 11
5.5. Authentication Option . . . . . . . . . . . . . . . . . . 11
5.6. Layer2 Identifier Option . . . . . . . . . . . . . . . . . 12
6. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Deng Expires May 3, 2009 [Page 2]
Internet-Draft GMMP October 2008
1. Introduction
In the current wireless communication network, there are various
kinds of wireless access technologies around our environment, even in
one mobile operator's network, there are several choices for
subscriber to choose. It become obvious that multiple connections
have to be supported by mobile terminals.
Currently, each individual wireless communication technology has
independent connection commands and triggers, as well as mobility
management and configuration. For example, 802.11 specify
"Associate/Deassociate/Reassociate", WCDMA/LTE/TDS-CDMA specify "RRC
setup/release", and WiMAX specify "MAC Ranging" et al.
Mobile terminal normally use each specific interface to control its
connection, mobility management and configurations et al. Terminal
software have to study each interface characteristics. This
phenomena become more serious when the request of terminal for
multiple connections comes.
There were some proposals to extend link layer to make a common
ground for this operation, but it will cost to revise some chipset or
kernel level. This make it hard to realize. But solution such as
defining a more high level interface and independent on link layer
may meet the requirement. And it will be quite convenient for the
mobile operator to handle if the connection, mobility, and
configuration management will be based on a common protocol which
don't rely on link layer technology.
Deng Expires May 3, 2009 [Page 3]
Internet-Draft GMMP October 2008
2. Multiple Network Connections
Multiple Network Connection has become obvious requirement for
wireless data communications. Operator may think about efficient
using radio resource. Subscriber may think about different price for
different connections. Some connections may be flat rate based,
others may be transmitted packet based. Or some connection has
better Quality of Service or no traffic filter exist.
The multiple network connections for mobile terminal is shown in the
figure below:
x y v z xi
| | | | |
+-----+ +-----+ +-----+ +-----+ +-----+
| MAR |......| MAR |......| MAR |......| MAR |......| MAR |
+-----+ +-----+ +-----+ +-----+ +-----+
`. : ,' `. : ,'
`. : ,' `. : ,'
`. : ,' `. : ,'
`. : ,' `. : ,'
v v v v v v
| | | | | |
+----------+ Move +----------+
| Terminal | ==========> | Terminal |
+----------+ +----------+
When Terminal move around in the wireless environment, it may change
multiple connections timely.For example, radio x and xi are the same
type wireless link like LTE, and radio v is always connected like
WiMAX, radio y is WLAN and radio z is TDS-CDMA. when terminal make a
movement, wireless connections will also changes, the routing and
mobility management would better change accordingly.
Different service may act independently when terminal has multiple
connections. From the service provider point of view, they don't
mandate that the application must handover to the second interface
when it just start up. Some services may keep original connection,
and others may handover to the second interface. This kind of
handover could happen both initiated by network or terminal itself.
On this purpose, operator normally specify some policy accordingly,
GMMP could be used for transmiting this policy between AP and
terminal.
Deng Expires May 3, 2009 [Page 4]
Internet-Draft GMMP October 2008
3. Reference Model
Assuming the name of protocol between terminal and access point is
GMMP which would work in the various kind of wireless connections
such as WCDMA, LTE, WiFi, and TD-SCDMA et al. After the coding of
each command for connections, mobility, and configuration, network or
terminal could control each connection and mobility management based
on a common language like the figure below.
+------+------+------+------+------+-------+
| GMMP Protocol |
+------+------+------+------+------+-------+
| GMMP Interface and Payload |
+------+------+------+------+------+-------+
| Various Kinds of MAC layer and Protocol |
+------+------+------+------+------+-------+
| WCDMA | LTE | WiFi | TDSCDMA |
+------+------+------+------+------+-------+
Each wireless technology essentially has independent control command
and protocol, but when network would like to control all wireless
connection based on a generic command, it has to some changes in
driver level.
+-----------------+ | +-----------------+
| | | | |
| +-------------+ | | | +-------------+ |
| | GMMP | | GMMP | | GMMP | |
| |Connection | | | | |Connection | |
| |Configuration| | | | |Configuration| |
| |Mobility |(------|------)|Mobility | |
| +-------------+ | | | +-------------+ |
| | | | | | |
| +-------------+ | | | +-------------+ |
| | Driver | | | | | Driver | |
| | MAC | | Radio/MAC | | MAC | |
| | Phy |(------|------)| Phy | |
| +-------------+ | | | +-------------+ |
| | | | |
| MN | | | AP |
+-----------------+ | +-----------------+
Deng Expires May 3, 2009 [Page 5]
Internet-Draft GMMP October 2008
4. Protocol Overview
GMMP could use UDP/TCP/SCTP as its transport protocol. GMMP messages
from a client to a server are sent to the 'GMMP server' port (TBD),
and GMMP messages from a server to a client are sent to the 'GMMP
client' port (TBD).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|GMMP v.| Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: GMMP message header
GMMP V.:
A 4 bit field which contains the version of GMMP used in this
packet. The value for this specification is zero (0).
Type:
A 4 bit field which specifies the payload type that follows the
UDP header.
GMMP message defines the following message type:
GMMPCONNECT(1) A mobile node send a connection message to a AP.
GMMPDISCONNECT(2) A mobile node send a disconnection message to a AP.
GMMPACK(3) A mobile node send a acknowledge message to a AP.
GMMPCONFIG(4) A AP send a configuration message to a mobile node.
GMMPDECLINE(5) A AP send a decline message to a mobile node
Length:
A 8 bit field containing the length of the GMMP transport header
in 4 byte words (Similar to IP header length). This length
includes the optional headers.
Deng Expires May 3, 2009 [Page 6]
Internet-Draft GMMP October 2008
Flags:
A set of reserved bits for future flags in the GMMP header. All
implementations complying with this protocol MUST set to zero any
bits that are reserved in the version of the protocol supported by
that implementation. Receivers MUST ignore all bits not defined
for the version of the protocol they support.
Identification:
A 64-bit number, constructed by the sender, used for protecting
against replay attacks of GMMP messages.
The GMMP client broadcasts GMMPCONNECT and GMMPDISCONNECT messages,
unless the client knows the address of a GMMP server. The client
unicasts GMMPACK messages to the server.
When the GMMP client knows the address of a GMMP server, the client
may use that address in the GMMPCONNECT or GMMPDISCONNECT rather than
the IP broadcast address. If the client receives no response to GMMP
messages sent to the IP address of a known GMMP server, the GMMP
client reverts to using the IP broadcast address.
The mobile node broadcasts a GMMPCONNECT message on its local
physical subnet. The GMMPCONNECT message MAY include options that
suggest values for the network authentication and address assignment.
GMMP relay agents may pass the message on to GMMP servers not on the
same physical subnet.
Each server may respond with a GMMPCONFIG message that includes an
available network information such as address, security challenges et
al.Each server could also respond with a GMMPDECLINE message which
means server doesn't allow this action.
After receiving the GMMPCONFIG or GMMPDECLINE message. The client
unicasts GMMPACK messages to the server.
4.1. GMMPCONNECT message
A mobile node send a connection message to a AP.
A mobile node send this message to a AP when it decide to connect to
this wireless link in the case of mobile node decide handover.
4.2. GMMPDISCONNECT message
A mobile node send a disconnection message to a AP.
Deng Expires May 3, 2009 [Page 7]
Internet-Draft GMMP October 2008
A mobile node send this message to a AP when it decide to disconnect
to this wireless link in the case of mobile node decide handover.
4.3. GMMPACK message
A mobile node send a acknowledge message to a AP.
4.4. GMMPCONFIG message
A AP send a configuration message to a mobile node.
4.5. GMMPDECLINE message
A AP send a decline message to a mobile node.
Deng Expires May 3, 2009 [Page 8]
Internet-Draft GMMP October 2008
5. GMMP Options
GMMP options will be used in GMMP message as various kind of
purposes. The format of GMMP options 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-type | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: GMMP message header
The definition of all units are:
option-type An unsigned integer identifying the specific
option type carried in this option.
option-len An unsigned integer giving the length of the
option-value field in this option in octets.
option-value The value for the option, the format of this
value depends on the definition of the
option.
5.1. Client Identifier Option
The format of Client Identifier Option 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENTID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Client Identifier .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Client Identifier Option
The definition of all units are:
Deng Expires May 3, 2009 [Page 9]
Internet-Draft GMMP October 2008
option-type OPTION_CLIENTID (1)
option-len Length of Client Identifier in octets.
option-value The value for the client identifier.
5.2. Server Identifier Option
The format of Server Identifier Option 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SERVERID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Server Identifier .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Server Identifier Option
The definition of all units are:
option-type OPTION_SERVERID (2)
option-len Length of Server Identifier in octets.
option-value The value for the server identifier.
5.3. Client Address Option
The format of Client Address Option 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENTADDRESS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Client Address .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Client Address Option
Deng Expires May 3, 2009 [Page 10]
Internet-Draft GMMP October 2008
The definition of all units are:
option-type OPTION_CLIENTADDRESS (3)
option-len Length of client address in octets.
option-value The value for the client address.
5.4. Server Address Option
The format of Server Address Option 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SERVERADDRESS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Server Address .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Server Address Option
The definition of all units are:
option-type OPTION_SERVERADDRESS (4)
option-len Length of server address in octets.
option-value The value for the server address.
5.5. Authentication Option
The format of Authentication Option 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_AUTHENTICATION | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Authentication Value... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Authentication Option
Deng Expires May 3, 2009 [Page 11]
Internet-Draft GMMP October 2008
The definition of all units are:
option-type OPTION_AUTHENTICATION (6)
option-len Length of authentication in octets.
SPI Security Parameter Index.
option-value The value for the authentication.
5.6. Layer2 Identifier Option
The format of Layer2 Identifier Option 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LAYER2IDENTIFIER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Layer2 Identifier .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Layer2 Identifier Option
The definition of all units are:
option-type OPTION_LAYER2IDENTIFIER (6)
option-len Length of layer2 identifier in octets.
option-value The value for the layer2 identifier.
Deng Expires May 3, 2009 [Page 12]
Internet-Draft GMMP October 2008
6. Usage Scenario
Proxy Mobile IPv6 protocol [NETLMM-MM-MAG] has specify an interface
between mobile node and MAG, but it doesn't specify any protocol for
usage. Normally, it will depends on layer 2 specific message.
Another issue for Proxy Mobile IPv6, regarding to mobile initiate
mobility management, the trigger for sending proxy binding update
message could be various kind of message such as DHCP, Router
solicitaion or acknowledgement message. When the mobile node has
multiple heterogenerous wireless connections, such various kind of
message will be not suitable.
GMMP could be used between MAG and MN in Proxy Mobile IPv6 protocol
which will be used for mobility trigger, IP address configuration,
policy configuration et al.
Deng Expires May 3, 2009 [Page 13]
Internet-Draft GMMP October 2008
7. Security Considerations
The protocol between terminal and wireless access point could be
protected by wirless protection mechanism since most of wireless
communication is based on point to point connections, in the case of
shared link wireless connection, layer 2 or layer 3 based security
mechanism should be adopted.
Deng Expires May 3, 2009 [Page 14]
Internet-Draft GMMP October 2008
8. IANA Considerations
IANA has recorded the following message types (defined in section 4).
IANA will maintain the registry of GMMP message types.
GMMPCONNECT 1
GMMPDISCONNECT 2
GMMPACK 3
GMMPCONFIG 4
GMMPDECLINE 5
IANA has recorded the following Option types (defined in section 5).
IANA will maintain the registry of GMMP Option types.
OPTION_CLIENTID 1
OPTION_SERVERID 2
OPTION_CLIENTADDRESS 3
OPTION_SERVERADDRESS 4
OPTION_AUTHENTICATION 5
OPTION_LAYER2IDENTIFIER 6
Deng Expires May 3, 2009 [Page 15]
Internet-Draft GMMP October 2008
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[NETLMM-MM-MAG]
Laganier, J., "Interface between a Proxy MIPv6 Mobility
Access Gateway and a Mobile Node", Februray 2008,
<draft-ietf-netlmm-mn-ar-if-03(work in progress)>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
Deng Expires May 3, 2009 [Page 16]
Internet-Draft GMMP October 2008
Author's Address
Hui Deng
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: denghui02@gmail.com
Deng Expires May 3, 2009 [Page 17]
Internet-Draft GMMP October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Deng Expires May 3, 2009 [Page 18]