TOC 
Network Working GroupX. Fu
Internet-DraftUniv. Goettingen
Expires: April 17, 2006J. Loughney
 Nokia
 October 14, 2005

Context Transfer Using GIST

draft-fu-cxtp-gist-00.txt

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 April 17, 2006.

Copyright Notice

Copyright © The Internet Society (2005).

Abstract

The CXTP specification uses SCTP as transport for CXTP message exchanges between a mobile node's new and previous access routers. It also relies on a pre-established IPsec ESP transport mode tunnel. This document presents an alternative approach based on the NSIS GIST protocol, which offers a more flexible transport and richer security properties for context transfer between different entities within the network that support forwarding of a mobile node's IP traffic.



Table of Contents

1.  Introduction
2.  Terminology
3.  Design Overview
4.  Context Transfer over GIST
5.  Further Discussions
    5.1.  Triggers for Context Transfer
    5.2.  Interworking with NSIS QoS and NAT/FW NSLP protocols
    5.3.  GIST MA bootstrapping, maintenance and inter-domain context transfer issues
6.  Security Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1. Introduction

The Context Transfer Protocol (CXTP)[1] (Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, “Context Transfer Protocol (CXTP),” July 2005.) provides a way to improve performance for mobile hosts by transferring state from the previous access router (pAR) to the new access router (nAR) across an IP based network. This document describes a solution based on the General Internet Signaling Transport protocol (GIST)[2] (Schulzrinne, H. and R. Hancock, “GIST: General Internet Signaling Transport,” September 2005.) for enhancing CXTP to perform more effectively. This approach allows reuse of an existing (secure) communication channel for context transfer between a pAR and any nAR, as well as seamless interworking with PANA and NSIS protocols, and minimized involvement of mobile hosts. This channel is soft state based, which allows an efficient and secure acquisition of state information for roaming devices as well as flexible selection of underlying transport mechanisms and automatic release of unused resources.



 TOC 

2. Terminology

Most of the terms are defined in the CXTP [1] (Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, “Context Transfer Protocol (CXTP),” July 2005.) and GIST [2] (Schulzrinne, H. and R. Hancock, “GIST: General Internet Signaling Transport,” September 2005.) specifications:

 o  MA    GIST messaging association
 o  MRS   GIST message routing state
 o  MRI   GIST message routing information
 o  CTAR  CXTP Activate Request message
 o  CTAA  CXTP Activate Acknowledge message
 o  CTD	  CXTP Data message
 o  CTReq CXTP Request message
 o  CTDR  CXTP Data Reply message
 o  CTC	  CXTP Cancel message
 o  pAR   previous Access Router
 o  nAR   new Access Router
 o  AR	  Access Router



 TOC 

3. Design Overview

The GIST protocol being developed by the NSIS working group for general signaling transport is independent on the underlying transport protocol, such as UDP, TCP, TCP over TLS or SCTP. In this section we describe the overall approach on how to reuse GIST for general context transfer between two entities within the network that support forwarding of a mobile node's IP traffic.

The most important part of CXTP is message exchanges between the entities within the network. These entities can be either nodes supporting access control or a PEP (Policy Enforcement Point) function, or access routers. This document covers the case where these entities are access routers, but the mechanisms are also applicable for any other types of nodes. The context transferred can be anything related to mobile nodes' end-to-end communications, such as AAA, header compression, QoS, Policy, and possibly sub-IP protocols and services such as PPP, as supported by CXTP.

This document extends CXTP [1] (Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, “Context Transfer Protocol (CXTP),” July 2005.) in that the CXTP messages exchanged between the entities within the network are encapsulated as a NSIS signaling application running above GIST. This way, features like soft state refreshes and messaging state reuse, transport protocol flexibility and ensured reliable and secure transport will allow CXTP to be applicable in many operational environments.

Typically, GIST operates with a path-coupled discovery procedure to determine the signaling node. As an access router will likely be able to know its neighboring access routers' address information (either by static configuration or can learn that information by other means), GIST messaging associations (MAs) between them can be either established on demand or pre-established depending on the policies, without the need of performing GIST path-coupled discovery and maintaining GIST message routing state (MRS).

If a mobile node (MN) requests for context transfer, or an AR predicts an MN is likely to move to another AR, context transfer message exchanges can be made upon the corresponding GIST MA.

Figure 1 illustrates an example scenario for CXTP using GIST. Theoretically, an AR can maintain GIST MA(s) between itself and any number of its neighboring ARs. Assume there is an MN moving from AR1 to AR3, then to AR4 and finally AR6. As there is already an existing GIST MA3 between AR1 and AR3, AR1 can transfer context of this MN to AR3 through MA3 by exchanging CXTP data messages (as CXTP NSLP messages). As there is no MA exists between AR3 and AR4, GIST will establish an MA4 when either AR3 or AR4 learns MN's movement or intention to move from AR3 to AR4. Note, one can negotiate which transport protocol and security properties between these ARs, allowing maximal flexibility and applicability in operational scenarios. After MA4 is established, AR3 can perform CXTP over it as usual. If for some (long) period of time AR1 does not anticipate any need for transferring context to any neighboring AR, nor it receives any CXTP message from that neighbor, GIST MAs SHOULD be released, avoiding waste of network resources.

                (GIST MA)        +-----+GIST MA6+-----+
      +----+---------------------+ AR5 +--------+ AR6 |
      |AR1 |\                    +--+--+       /+--+--+
      +----+ \                      |        /     |
   GIST/      \GIST             GIST|      GIST    |GIST
   MA1/        \ MA3             MA5|    / MA7     |MA8
     /          \                   |  /           |
 +--/-+ GIST MA2+\----+(GIST MA4)+--+--+GIST MA8+--+--+
 |AR2 +---------+ AR3 +----------+ AR4 +--------+ AR7 |
 +----+         +-----+          +-----+        +-----+

   Figure 1: An example scenario for CXTP using GIST



 TOC 

4. Context Transfer over GIST

A new NSIS signaling application type (NSLP ID TBD), "CXTP NSLP", is defined in this document for exchanging CXTP messages (CTD, CTReq, CTDR and CTC) between pAR and nAR and possibly creating GIST MAs. Each CXTP NSLP message contains a common NSLP header (as defined in [2] (Schulzrinne, H. and R. Hancock, “GIST: General Internet Signaling Transport,” September 2005.)), followed by one of these 4 types of CXTP messages defined in [1] (Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, “Context Transfer Protocol (CXTP),” July 2005.)). For example, the CXTP NSLP CTD message is described in Figure 2:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | NSLP message type = CXTP NSLP |       reserved                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Vers.|Type= CTD|V|   Reserved  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                   MN's Previous IP Address                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                  Previous (New) AR IP Address                 ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     MN Authorization Token                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Requested Context Data Block (if present)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Next Requested Context Data Block (if present)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           ........                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: CXTP NSLP CTD message

If previous access router (pAR) and next access router (nAR) are neighbors, then no GIST discovery is needed. Thus, GIST messages defined in [2] (Schulzrinne, H. and R. Hancock, “GIST: General Internet Signaling Transport,” September 2005.) should be changed as follows:

CXTP messages between MN and pAR and between MN and nAR are specified in CXTP [1] (Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, “Context Transfer Protocol (CXTP),” July 2005.) as ICMP messages and not modified here.

If pAR and nAR are not neighbors, then standard GIST discovery is used.



 TOC 

5. Further Discussions



 TOC 

5.1. Triggers for Context Transfer

There are many possiblities to trigger Context Transfer using GIST, some of which are listed below:

These triggers can be categorized to either 1) triggers perceived at the nAR or 2) triggers perceived at the pAR. Upon a trigger of category 1), the nAR needs to send a CT-Req over the GIST MA to the pAR, and the latter in turn responds back with a CTD; then an optional CTDR can be sent from the pAR to the nAR. Upon a trigger of category 2), the pAR simply needs to send a CTD over the GIST MA to the nAR.

In either case, if a desired CTD message is not received within a certain period of time (or due to other reasons, e.g., the nAR senses that the MN moves out of its coverage before receiving a CTD), the nAR may issue a CTC to cancel the context transfer using the GIST MA.



 TOC 

5.2. Interworking with NSIS QoS and NAT/FW NSLP protocols

CXTP, especially its use over GIST, can reduce the overhead for the last hop communication between an MN and its AR. Using CXTP/GIST, the AR states related to MN-CN end-to-end communications are transferred seamlessly, without the need to reestablish from the MN.

Figure 3 illustrates an example where QoS NSLP signaling is desired from the MN to the CN. The case of NAT/FW NSLP is similar. Before the handover, QoS NSLP was used, involving steps 1)-4) and finally reaches CN. Then the MN moves to the nAR, which maintains a (secure) GIST MA with the pAR. Some trigger as described in previous subsection (e.g., either (1) or (1a) or another event) then starts the CXTP/GIST, which results in QoS NSLP state successfully transferred from the pAR to the nAR. Once the CXTP/GIST is accomplished, the nAR can then act on behalf on the MN and (re)establish the QoS NSLP state along the path towards the CN using QoS NSLP signaling.

           +-----+ (2)   +-----+
          ~| pAR |~~~~~~~| R1  |
      (1)~ +--*--+       +-----+~ (3)
        ~     *                  ~
       ~      *(CXTP/GIST)        ~+----+ (4) +----+  +----+
 +----~-+     *                    | R3 +-----+ .. +--+ CN |
 | MN   |     *               (3a)/+----+     +----+  +----+
 +------+\   \*/                 /
      (1a)\+--*--+ (2a)  +-----+/
           | nAR +-------+ R2  |
           +-----+       +-----+

      Figure 3: Interworking with NSIS QoS NSLP



 TOC 

5.3. GIST MA bootstrapping, maintenance and inter-domain context transfer issues

CXTP/GIST requires maintaining a GIST MA between neighboring ARs. In cases where ARs belonging to different administrative domains do not have a pre-established GIST MA, or an AR is newly added or rebooted, GIST MAs need to be established on demand in a secure fashion. Further versions of this document will discuss this aspect in more detail.



 TOC 

6. Security Considerations

The security considerations of both [2] (Schulzrinne, H. and R. Hancock, “GIST: General Internet Signaling Transport,” September 2005.) and [1] (Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, “Context Transfer Protocol (CXTP),” July 2005.) apply. Further security analysis is needed to consider any additional security vulnerabilities, and will be included in an updated draft.



 TOC 

7. Acknowledgements

Henning Peters provided useful comments.



 TOC 

8. References



 TOC 

8.1. Normative References

[1] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, “Context Transfer Protocol (CXTP),” RFC 4067, July 2005.
[2] Schulzrinne, H. and R. Hancock, “GIST: General Internet Signaling Transport,” draft-ietf-nsis-ntlp-08 (work in progress), September 2005.


 TOC 

8.2. Informative References

[3] Forsberg, D. and et. al, “PANA Mobility Optimizations,” draft-ietf-pana-mobopts-00 (work in progress), January 2005.
[4] Bournelle, J., “Use of Context Transfer Protocol (CxTP) for PANA,” draft-bournelle-pana-ctp-03 (work in progress), June 2005.


 TOC 

Authors' Addresses

  Xiaoming Fu
  University of Goettingen
  Institute for Informatics
  Lotzestr. 16-18
  Goettingen 37083
  Germany
Email:  fu@cs.uni-goettingen.de
  
  John Loughney
  Nokia Research Center
  Itamerenkatu 11-13
  Helsinki 00180
  Finland
Email:  john.loughney@nokia.com


 TOC 

Intellectual Property Statement

Disclaimer of Validity

Copyright Statement

Acknowledgment