IKEv2 based flow control extension of PMIPv6
draft-liu-netext-flow-pmip-02

Abstract

PMIPv6 is designed to provide network based mobility, it requries no changes to the UE. There are proposals to extend PMIPv6 to support flow mobility. Flow mobility requries the UE and the network having communication protocol to carry the flow control messages. This document proposes to use the extended IKEv2 protocol to carry the flow control messages between the UE and network.

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 January 11, 2011.

Copyright Notice

Copyright (c) 2010 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 (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.

Table of Contents

1.  Introduction
2.  Conventions used in this document
3.  Overview of using IKEv2 to carry flow control information
4.  IKEv2 configuration payload extension
5.  MN operation
6.  MAG operation
7.  LMA operation
8.  Security Considerations
9.  IANA Considerations
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses

1.  Introduction

There are proposals to extend PMIPv6 to support flow mobility. But there is currently no protocol is specified between the UE and network which is used to carry the flow control policies. Since PMIPv6 is aimed to provide network based mobility solution and no UE changes is prefered, it is not feasible to define new protocol between the UE and network which is used to carry the flow control information. This document proposes to use extended IKE protocol to carry the flow control information.

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Overview of using IKEv2 to carry flow control information

IKEv2 is used for security parameter negotiation. It is usally used combine with IPSec. There are configuration payload options in IKEv2 which could be used for IP address allocation and other configuration purposes. This document proposes to extend the configuration payloads to carry the flow control information.

IKEv2/IPSec is also used for protecting mobility signalling in 3GPP. In 3GPP architecture, s2b interface is based on PMIP and used for un-trusted non-3GPP access. There is an IPSec tunnel between the UE and the un-trusted non- 3GPP access gateway(ePDG). This IPSec tunnel's security association and other security parameters are set up using IKEv2. Except for the security function, the IKEv2 protocol between the UE and no-3GPP access gateway(ePDG) is also used for IP address configuration. The IP address is carried by configuration payload in IKEv2.

From the above analysis, we can see that there is a mandatory IKEv2 protocol running between the UE and the network in 3GPP s2b interface. It is natural to consider extending this protocol to carry the flow mobility control information.

4.  IKEv2 configuration payload extension

IKEv2's configuration payload is defined to carry configuration information, for example: IP address allocation etc. The format of the configration payload is as follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C! RESERVED    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!   CFG Type    !                    RESERVED                   !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                   Configuration Attributes                    ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As Figure 1 (Format of Configuration Payload of IKEv2) depicted, IKEv2 configuration payload has CFG Type and configuration attributes options. CFG Type includes CFG_REQUEST, CFG_REPLY, CFG_SET, CFG_ACK. "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data to its peer. "CFG_REQUEST/ CFG_REPLY" allows an IKE endpoint to request information from its peer.

Configuration attributes has the following format:

                         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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!R|         Attribute Type      !            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                             Value                             ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Current specified attribute type include:

                                Multi-
            Attribute Type          Value Valued Length
           ======================= ===== ====== ==================
            RESERVED                 0
            INTERNAL_IP4_ADDRESS     1    YES*  0 or 4 octets
            INTERNAL_IP4_NETMASK     2    NO    0 or 4 octets
            INTERNAL_IP4_DNS         3    YES   0 or 4 octets
            INTERNAL_IP4_NBNS        4    YES   0 or 4 octets
            INTERNAL_ADDRESS_EXPIRY  5    NO    0 or 4 octets
            INTERNAL_IP4_DHCP        6    YES   0 or 4 octets
            APPLICATION_VERSION      7    NO    0 or more
            INTERNAL_IP6_ADDRESS     8    YES*  0 or 17 octets
            RESERVED                 9
            INTERNAL_IP6_DNS        10    YES   0 or 16 octets
            INTERNAL_IP6_NBNS       11    YES   0 or 16 octets
            INTERNAL_IP6_DHCP       12    YES   0 or 16 octets
            INTERNAL_IP4_SUBNET     13    YES   0 or 8 octets
            SUPPORTED_ATTRIBUTES    14    NO    Multiple of 2
            INTERNAL_IP6_SUBNET     15    YES   17 octets

This document proposes to extend the attribute type of the Configuration attributes , adding two new types: IPv4_FLOW_CONTROL/ IPv6_FLOW_CONTROL, the definition of this proposal is as follows:

                               Multi-
            Attribute Type          Value Valued Length
           ======================= ===== ====== ==================
           IPv4_FLOW_CONTROL         20    YES*  0 or x octets
           IPv6_FLOW_CONTROL         21    YES*  0 or x octets

The corresponding value of this proposed FLOW_CONTROL attribute is as follows:

  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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             MN-ID             |            BID                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             HNP               |            Action             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 start Source Address                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 End Source Address                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 start Destination Address                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 End Destination Address                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          Start SPI                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          End SPI                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Start Source port        |      End Source port          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      start Destination port   |      End Destination port     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• MN-ID: MN idendification of the mobile node.
• BID: Binding idendification associated with this flow and HNP.
• HNP: Home network prefix associated with this flow.
• Action: The action that the sender request the receiver to perform. Actions may include:Foward(1): request the receiver to foward the flow based on the HNP and BID.other values of action need further specified.
• Start Source Address: Start of source address of this flow. this address could be IPv4 or IPv6 address, depending on the FLOW_CONTROL type is IPv4 or IPv6.
• End Source Address: end of source address of this flow. this address could be IPv4 or IPv6 address, depending on the FLOW_CONTROL type is IPv4 or IPv6.
• Start Destination Address:start of destination address of this flow. this address could be IPv4 or IPv6 address, depending on the FLOW_CONTROL type is IPv4 or IPv6.
• End Destination Address:end of destination address of this flow. this address could be IPv4 or IPv6 address, depending on the FLOW_CONTROL type is IPv4 or IPv6.
• Start SPI: Start SPI of this flow.
• End SPI: End SPI of this flow.
• Start Source port: Start soure port of this flow.
• End Source port: End of source port of this flow.
• Start Destination port: Start of destination port of this flow.
• End Destination port: End of destination port of this flow.

5.  MN operation

for flow mobility, MN decides when to initiate flow handover. MN uses the above extended IKEv2 configureation payload extension to send the flow control message. Flow mobility polilcy control function need to communicate with the IKE module in the MN to carry the flow mobility control information.

6.  MAG operation

MAG needs to get the flow mobility control information from the IKE configration payload extension. MAG then send PBU message with the flow mobility extension.

7.  LMA operation

LMA get flow control information from the PBU which carries the flow mobility extension. Then it control the flow mobility action accordingly.

8.  Security Considerations

TBD

9.  IANA Considerations

None

10.  References

10.1. Normative References

10.2. Informative References

Authors' Addresses