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, . [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]