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]