Subject: RE: [seamoby] draft-ietf-seamoby-context-transfer-problem-02.txt

From: "Gary Kenward" <[email-masked]>
Date: Wed, 13 Jun 2001 15:46:26 -0400

Madjid:

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2001 2:31 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'
> Cc: 'seamoby-context'; 'Allison Mankin'
> Subject: RE: [seamoby]
> draft-ietf-seamoby-context-transfer-problem-02.txt
> Sensitivity: Confidential
> 
> 
> Gary,
> 
> Thanks for the new revision.
> 
> I had two questions:
> 
> 1- Does this mean we are ending DoS analysis?

Nothing ever ends.

What would you rather do, get a problem statement completed for approval by
the IESG, 
or debate DOS?

> 
> 2-Why are we concerned about Theft of service in a CT draft?

TOS is the primary reason for authentication. I don't know if there is a
problem 
here, and I don't want to analyze it for the ps. It's only provided as an
example.

Gary

> 
> Thanks,
> Madjid
> 
> -----Original Message-----
> From: Gary Kenward [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2001 9:40 AM
> To: 'seamoby'
> Cc: 'seamoby-context'; 'Allison Mankin'
> Subject: [seamoby] draft-ietf-seamoby-context-transfer-problem-02.txt
> Importance: High
> Sensitivity: Confidential
> 
> 
> Below is a revision of the second version of the problem 
> statement draft.
> I have tried to accommodate Allisons' wishes, as well as 
> John's concern over
> explicitly referring to DOS (I hope what I have provided is sufficient
> John).
> 
> Bash away.
> 
> Gary
> 
> ==============================================================
> ==============
> 
>       
>     Context and Micro-mobility Routing Working Group         
> O. H. Levkowetz
>     Internet Draft                                            
>           ABNW
>     draft-ietf-seamoby-context-transfer-problem-              
>  P. R. Calhoun
>     02.txt                                             Sun 
> MicroSystems, Inc
>     Expires: December 2001                                    
>     G. Kenward
>                                                               
>     H. M. Syed
>                                                              
> Nortel Networks
>                                                               
>      J. Manner
>                                                       
> University of Helsinki
>                                                               
>    M. Nakhjiri
>                                                               
>       Motorola
>                                                             
> G. Krishnamurthi
>                                                               
>      R. Koodli
>                                                               
>          Nokia
>                                                               
>    K. S. Atwal
>                                                             
> Zucotto Wireless
>                                                               
>      M. Thomas
>                                                               
>          Cisco
>                                                               
>       M. Horan
>                                                               
>        COM DEV
>                                                               
>   P. Neumiller
>                                                               
>           3Com
>                                                               
>      June 2001
>          
>          
>           Problem Description: Reasons For Performing Context 
> Transfers 
>                     Between Nodes in an IP Access Network 
>          
>      Status of This Memo 
>          
>         This document is an Internet-Draft and is in full 
> conformance with 
>         all provisions of Section 10 of RFC2026. 
>          
>         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. 
>          
>      Copyright Notice 
>          
>         Copyright (C) The Internet Society (2001). All Rights 
> Reserved. 
>          
>      Levkowetz et al.                                         
>      [Page 1] 
>        
> 
>      Internet Draft                                           
>      June 2001
> 
>                draft-ietf-seamoby-context-transfer-problem-02.txt 
>        
>      Abstract 
>          
>         There are a large number of IP access networks that 
> support mobility
> 
>         of hosts. For example, wireless Personal Area 
> Networks (PANs), 
>         wireless LANs, satellite WANs and cellular WANs. The 
> nature of this 
>         mobility is such that the communication path to the 
> host changes 
>         frequently and rapidly.  
>          
>         This Internet-Draft describes the problem encountered during 
>         mobility that requires the exchange of IP context 
> between different 
>         forwarding nodes in an access network. 
>          
>          
>      Table of Contents 
>       
>         1 
> Introduction...................................................2 
>         2 Reference 
> Definitions..........................................3 
>         3 The Need for Context 
> Transfer..................................4 
>          3.1 Scope of the Context Transfer Solution 
> .....................5 
>          3.2 Reference Architectures 
> ....................................6 
>         4 A Description of 
> Context.......................................6 
>          4.1 Feature 
> ....................................................6 
>          4.2 Feature Context 
> ............................................7 
>          4.3 Microflow Context 
> ..........................................7 
>          4.4 Common Context 
> .............................................7 
>          4.5 Examples of Feature Context 
> ................................8 
>         5 Context Transfer and 
> Mobility..................................8 
>         6 Forwarding Node 
> Capabilities...................................8 
>         7 Inter-technology Context 
> Transfers.............................8 
>         8 
> Applicability..................................................9 
>         9 Performance 
> Considerations.....................................9 
>         10 Security 
> Considerations.......................................9 
>         11 
> Recommendations..............................................10 
>          
>          
>      1 Introduction 
>          
>         There are a large number of IP access networks that 
> support hosts 
>         that are mobile. For example, wireless Personal Area Networks 
>         (PANs), wireless LANs, satellite WANs and cellular 
> WANs. The nature 
>         of this mobility is such that the communication path 
> to a host may 
>         change frequently and rapidly.  
>          
>         In networks where the hosts are mobile, the 
> forwarding path through 
>         the access network must often be redirected in order 
> to deliver the 
>         host's IP traffic to the new point of access. The 
> success of a time 
>         sensitive service such as VoIP telephony, video, 
> etc., in a mobile 
>         environment depends heavily upon the minimization of 
> the impact of 
>         this traffic redirection. In the process of 
> establishing the new 
>         forwarding path, the nodes along the new path must be 
> prepared to 
>         provide similar forwarding treatment to the IP packets.  
>        
>      Levkowetz et al.                                         
>      [Page 2] 
>        
> 
>      Internet Draft                                           
>      June 2001
> 
>                draft-ietf-seamoby-context-transfer-problem-02.txt 
>        
>          
>         The information required in support of a specific forwarding 
>         treatment provided to IP traffic is part of the 
> context for that 
>         traffic. This context is comprised of configuration and state 
>         information. To minimize the impact of a path change 
> on an IP flow, 
>         the context used at the forwarding nodes along the 
> original path, 
>         must be replicated at the forwarding nodes along the 
> new path. 
>          
>         The transfer of context information may be advantageous in 
>         minimizing the impact of host mobility on, for 
> example, AAA, header 
>         compression, QoS, Policy, and possibly sub-IP 
> protocols and services
> 
>         such as PPP. Context transfer at a minimum will be 
> used to replicate
> 
>         the configuration information needed to establish the 
> respective 
>         protocols and services. In addition, it may also provide the 
>         capability to replicate state information, allowing stateful 
>         protocols and services at the new node to be 
> activated along the new
> 
>         path with less delay and less signalling overhead. 
>          
>          
>      2 Reference Definitions 
>          
>         Mobile Node 
>          
>         An IP node capable of changing its point of attachment to the 
>         network. The mobile node is usually an end user host, 
> but may be a 
>         forwarding node for a network that is itself mobile.  
>          
>         Forwarding Node 
>          
>         A node that supports IP forwarding within the access 
> network. This 
>         includes all routers, gateways, servers and other 
> nodes within the 
>         network that have IP protocol stacks and forward IP 
> traffic to and 
>         from a mobile node. 
>          
>         A forwarding node will be connected to one or more 
> other forwarding 
>         nodes. Some forwarding nodes will be connected to 
> zero or more 
>         mobile nodes. The forwarding nodes that connect to 
> mobile nodes will
> 
>         do so through a layer two entity that supports wireless 
>         communications.  
>          
>         Microflow 
>          
>         One useful definition for the fundamental unit of IP 
> service is the 
>         microflow. RFC 2475 [1] defines a microflow as: 
>          
>         A single instance of an application-to application 
> flow of packets 
>         destined to or originated from a mobile device (MN or 
> MH), which is 
>         identified by source address, source port, 
> destination address, 
>         destination port and protocol id. 
>          
>        
>      Levkowetz et al.                                         
>      [Page 3] 
>        
> 
>      Internet Draft                                           
>      June 2001
> 
>                draft-ietf-seamoby-context-transfer-problem-02.txt 
>        
>         RFC 2207 [2] provides a definition of a microflow 
> that applies to 
>         IPSec packets. It is based on the IPSec SPI found in 
> the AH or ESP 
>         headers. Other methods for identifying for IP 
> microflows may be 
>         defined in the future, e.g. the Ipv6 flow label. 
>          
>          
>      3 The Need for Context Transfer 
>          
>         In networks where the hosts are mobile, the 
> forwarding path through 
>         the access network must often be redirected in order 
> to deliver the 
>         host's IP traffic to the new point of access. The 
> success of a time 
>         sensitive service such as VoIP telephony, video, 
> etc., in a mobile 
>         environment depends heavily upon the minimization of 
> the impact of 
>         this traffic redirection. In the process of 
> establishing the new 
>         forwarding path, the nodes along the new path must be 
> prepared to 
>         provide similar forwarding treatment to the IP packets.  
>          
>         Figure 1 and 2 below illustrate an example of a 
> handover scenario. A
> 
>         mobile node, MN7, is shown attached to the Internet 
> via an access 
>         network. The forwarding nodes, FN1 through to FN7 
> comprise a portion
> 
>         of this access network. FN1 and FN7 are the last 
> forwarding nodes 
>         before the untethered link to MN7. This last link 
> allows the nodes 
>         to move while maintaining connectivity to the edge of 
> the access 
>         network - e.g. the last link is wireless. For 
> simplicity, many 
>         details of a real access network topology have been 
> left out of the 
>         diagrams. 
>          
>         Prior to handoff, the path for MN7's traffic 
> traverses FN1 and FN2. 
>         It is presumable that FN1 and FN2 have been 
> configured to provide 
>         specific forwarding services for MN7's traffic, and 
> that some of 
>         these services may require state information to be 
> maintained. 
>          
>                                                               
>             
>                                        MN7's traffic          
>             
>                                    <------------------>       
>             
>                               -------                 ------- 
>             
>               [ MN7 ]<= = = =>| FN1 |=================| FN2 
> |========     
>                               -------                /------- 
>             
>                                                     /         
>             
>                                             -------/          
>             
>                                             | FN4 |           
>             
>                                            /-------\          
>             
>                                           /         \         
>             
>                                          /           \        
>             
>                                  -------/             
> \-------            
>                             - - -| FN7 |               | FN6 
> |----        
>                                  -------               
> -------            
>                                                               
>             
>                          Figure 1: Path Prior to Handover     
>             
>                                                               
>             
>          
>        
>      Levkowetz et al.                                         
>      [Page 4] 
>        
> 
>      Internet Draft                                           
>      June 2001
> 
>                draft-ietf-seamoby-context-transfer-problem-02.txt 
>        
>         When MN7's movement results in the link to FN1 to be 
> replaced by a 
>         link to FN7, MN7's traffic must be re-directed along a new 
>         forwarding path, illustrated in Figure 2 as the path 
> through FN7, 
>         FN4 and FN2. In many mobile networks, this handover can occur 
>         frequently, and sometimes with little or no warning. 
>                                -------                ------- 
>             
>                           - - -| FN1 |----------------| FN2 
> |========     
>                                -------              //------- 
>             
>                                                    //   MN7's 
> traffic     
>                                             -------/    
> <----------->     
>                                             | FN4 |           
>             
>                                            //------\          
>             
>                            MN7's traffic  //        \         
>             
>                            <-----------> //          \        
>             
>                                   -------/            
> \-------            
>                   [ MN7 ]<= = = =>| FN7 |              | FN6 
> |----        
>                                   -------              
> -------            
>                                                               
>             
>                  Figure 2: Path Re-Directed After Handover    
>             
>                                                               
>             
>          
>         If the forwarding treatment provided to MN7's traffic 
> is to be 
>         sustained, the support conditions at FN1 and FN2 must 
> be reproduced 
>         at FN7 and FN4. At the very least, this requires that 
> FN7 and FN4 be
> 
>         configured to provide the appropriate support to the 
> traffic flow. 
>         However, establishing forwarding support along the 
> new path through 
>         the use of IP signalling protocols would be relatively time 
>         consuming. In addition, given that some forwarding 
> services may 
>         maintain state information, simply configuring FN7 
> and FN4 would not
> 
>         circumvent disruption of the services. 
>          
>         Given that FN7 and FN4 support the same functionality 
> as FN1, it 
>         should be possible to reproduce the needed support 
> along the new 
>         forwarding path by capturing the salient information 
> at FN1 as it 
>         exists just prior to the handover, and then use that 
> information to 
>         replicate the state of FN1 at FN7 and FN4. 
>          
>          
>      3.1 Scope of the Context Transfer Solution 
>          
>         The information required to produce the necessary forwarding 
>         treatments at a node is referred to as the support 
> "context". In 
>         order to replicate the context of one forwarding node 
> at another 
>         forwarding node, an open, standard solution for 
> context transfer 
>         must be developed.  
>          
>        
>      Levkowetz et al.                                         
>      [Page 5] 
>        
> 
>      Internet Draft                                           
>      June 2001
> 
>                draft-ietf-seamoby-context-transfer-problem-02.txt 
>        
>         In addition, for a forwarding node to be able to 
> interpret the 
>         transferred context, both the syntax and the semantics of the 
>         context information must be defined. Definition of the actual 
>         context information will be specific to the support 
> feature being 
>         replicated, however, a generic container format of 
> the payload of 
>         context transfer messages is required for inter-operability. 
>          
>          
>      3.2 Reference Architectures 
>          
>         The concept of the "forwarding node" is used here to 
> describe the 
>         general context transfer problem. In different 
> networks, the actual 
>         context transfer may take place between different 
> entities within 
>         the network. In some cases the preferred context 
> transfer peers 
>         might be the routers at the edge of the access 
> network. In other 
>         situations, it may be more appropriate to transfer 
> context between 
>         wireless access points that also support forwarding 
> of IP packets. 
>          
>         The context transfer solution will be applicable to 
> any nodes that 
>         support forwarding of a mobile nodes IP traffic. 
>          
>          
>      4 A Description of Context 
>          
>         The term `
>                  `context'
>                           ' pertains to all information required by a 
>         forwarding node specific to supporting the IP traffic for a 
>         particular mobile node.  
>          
>         The context for a mobile node can be partitioned into three 
>         categories: 
>          
>                 - information required to provide generally 
> support to the  
>                   mobile node; 
>          
>                 - information required to provide common 
> support to the 
>                   mobile node's traffic; 
>          
>                 - information required to support specific 
> features of the 
>                   forwarding treatment for an IP microflow. 
>          
>          
>      4.1 Feature 
>          
>         A feature is an aspect of the IP forwarding treatment that is 
>         instantiated for each mobile node, and which may 
> support one or more
> 
>         of the mobile nodes microflows. A feature must 
> include associated 
>         configuration information: at the very least, some 
> identification 
>         information for the mobile node, such as the mobile node's IP 
>         address. A feature may have associated state information. 
>          
>        
>      Levkowetz et al.                                         
>      [Page 6] 
>        
> 
>      Internet Draft                                           
>      June 2001
> 
>                draft-ietf-seamoby-context-transfer-problem-02.txt 
>        
>         In other words, for the purpose of supporting 
> mobility the features 
>         of interest all have context pertinent to the forwarding of a 
>         specific mobile nodes IP packets. Examples of 
> features include: 
>         header compression, security, subscriber policy, and 
> quality of 
>         service. 
>          
>         Each feature is, in general, supported by an 
> amalgamation of one or 
>         more protocols and associated local support mechanisms. As an 
>         example, header compression is a feature that 
> consists of various 
>         "mechanisms" such as IP/TCP header compression and 
> IPv6/UDP/RTP 
>         header compression, operating according to 
> well-defined "protocols".
> 
>         Thus, an instance of a feature reflects the state 
> associated with 
>         protocols and the corresponding mechanisms. 
>          
>          
>      4.2 Feature Context 
>          
>         Feature context is the condition or state of an instance of a 
>         particular feature. It represents the current 
> evolution of the 
>         behaviour of that feature instance. At a given 
> instant in time, 
>         feature context is represented by the values of the 
> associated data 
>         elements. 
>          
>         Some of the data elements associated with a feature are time 
>         invariant and, thus, represent the configuration of 
> the feature 
>         instance. Other data elements, which are often 
> referred to as the 
>         "state variables" for the feature instance, change 
> value over time 
>         as a consequence of the various operations performed 
> in support of 
>         the feature instance. 
>          
>         A feature context is believed to be the smallest 
> indivisible unit of
> 
>         context that can be transferred between forwarding nodes. 
>          
>          
>      4.3 Microflow Context 
>          
>         A microflow context is the collection of the various feature 
>         contexts associated with a single IP microflow. It is 
> the smallest 
>         unit of context that must be transferred in order to 
> re-establish 
>         support for the microflow at a forwarding node. 
>          
>          
>      4.4 Common Context 
>          
>         Some of the associated feature contexts may be 
> applicable to more 
>         then one of the IP microflows comprising the mobile 
> node's traffic. 
>         An example of this might be the authentication state 
> for the mobile.
> 
>         This type of feature context is also required to support each 
>         microflow, but because of the multiplicity of the 
> relationship to 
>         the mobile node's microflows, it would seem prudent 
> to transfer one 
>         instance of the context, independent of the microflow 
> context. 
>        
>      Levkowetz et al.                                         
>      [Page 7] 
>        
> 
>      Internet Draft                                           
>      June 2001
> 
>                draft-ietf-seamoby-context-transfer-problem-02.txt 
>        
>          
>          
>      4.5 Examples of Feature Context 
>          
>         Some examples of feature contexts that are candidates 
> for context 
>         transfer are given below. This list is provided 
> solely to illustrate
> 
>         the nature of the context transfer problem domain. 
>          
>                 - encryption context; 
>                 - authentication context; 
>                 - authorization context; 
>                 - accounting context; 
>                 - header compression context; 
>                 - quality of service context; 
>                 - policy enforcement context; 
>                 - multicast group membership; 
>                 - buffer state; 
>                 - sub-network layer context (e.g. PPP context). 
>          
>          
>      5 Context Transfer and Mobility 
>          
>         Context transfer is an enhancement to a mobility 
> solution that is 
>         clearly most effective when used on a local scale 
> between forwarding
> 
>         nodes within a subnetwork. However, with due 
> consideration to the 
>         nature of the context and the requirements for 
> transfer of that 
>         context, context transfer should be applicable 
> between any two 
>         similar forwarding nodes. 
>          
>          
>      6 Forwarding Node Capabilities 
>          
>         Context transfer between two forwarding nodes is 
> worthwhile only if 
>         the receiving node's capabilities are similar enough 
> to those of the
> 
>         sending node that the received context can be 
> utilized. This does 
>         not mean that the two nodes are identical in their 
> implementation, 
>         nor does it even imply that they must have identical 
> capabilities. 
>          
>         A forwarding node that cannot make use of received 
> context could, 
>         and should, refuse the transfer. This would result in 
> a situation no
> 
>         different then mobile handover without context transfer. 
>          
>          
>      7 Inter-technology Context Transfers 
>          
>         The context transfer described here operates at the 
> IP layer, and 
>         should be applicable to situations where the 
> forwarding nodes are 
>         supporting different wireless link technologies.  
>          
>        
>      Levkowetz et al.                                         
>      [Page 8] 
>        
> 
>      Internet Draft                                           
>      June 2001
> 
>                draft-ietf-seamoby-context-transfer-problem-02.txt 
>        
>         An exception to this would be where sub-IP layer 
> context is an 
>         intrinsic part of the forwarding treatment. In this 
> situation, an 
>         interworking solution must be developed for sub-IP 
> context transfer 
>         between the two technologies. This issue is outside 
> the scope of the
> 
>         Seamoby working group. 
>          
>          
>      8 Applicability 
>          
>         The primary motivation for developing an IP context 
> transfer assumes
> 
>         that service sustainment during handover is 
> desirable. And yet, 
>         there may be situations where either the user or the 
> access network 
>         would prefer to re-establish or re-negotiate a 
> service or a service 
>         feature. For example, if the mobile node crosses 
> administration 
>         domains where the operational policies change, 
> negotiation of a 
>         different level of service may be required by the respective 
>         operators. 
>          
>         More important, the concept of context transfer also 
> assumes that 
>         the service is worth sustaining through a variety of handover 
>         scenarios, and that context transfer is the best 
> approach. The 
>         former may not be true for certain types of service - 
> for example,  
>         multicast, "push" information services. In addition, 
> even if service
> 
>         level sustainment is desirable, context transfer may 
> not be the most
> 
>         cost efficient solution. 
>          
>         Alternatives to context transfer for sustaining 
> services during 
>         handover are out of scope for the Seamoby working group. The 
>         possibility of other solutions is only noted here to 
> emphasize that 
>         context transfer is but one of possibly many approaches. 
>          
>         Finally, context transfer is an enhancement at the IP 
> level to 
>         improve upon the performance of a handover between IP 
> forwarding 
>         nodes. Many networks provide support for handover at 
> the link layer,
> 
>         within and between subnetworks, and context transfer 
> may not provide
> 
>         a significant improvement over the these link layer 
> solutions. 
>          
>          
>      9 Performance Considerations 
>          
>         The purpose of context transfer is to sustain the 
> services being 
>         provided to a mobile node's traffic during handover. It is 
>         essentially an enhancement to a mobility solution 
> that ultimately 
>         must result in an improvement in handover 
> performance. The various 
>         aspects of performance must be a prime consideration in the 
>         development of the context transfer solution. 
>          
>          
>      10 Security Considerations 
>          
>         Some of the considerations for context transfer 
> security include: 
>        
>      Levkowetz et al.                                         
>      [Page 9] 
>        
> 
>      Internet Draft                                           
>      June 2001
> 
>                draft-ietf-seamoby-context-transfer-problem-02.txt 
>        
>          
>                 - information privacy: the context may 
> contain information  
>                   which the end user would prefer to keep hidden from 
>                   unauthorized viewers. 
>          
>                 - transfer legitimacy: a false or purposely corrupted 
>                   context transfer could have a severe impact 
> upon the 
>                   operation of the receiving forwarding node, 
> and therefore 
>                   could potentially affect the operation of 
> the access 
>                   network itself; the potential threats 
> include denial of 
>                   service and theft of service attacks; 
> context transfer 
>                   must only occur between forwarding nodes 
> that have an  
>                   established trust relationship. 
>                  
>                 - security preservation: part of the context 
> transfer may 
>                   include information pertinent to a security 
> association  
>                   established between the mobile node and 
> another entity on
> 
>                   the network; for this security association 
> to be preserved
> 
>                   during handover, the transfer of the 
> security context  
>                   must include the appropriate security measures. 
>          
>         It is expected that the measures used to secure the 
> transport of 
>         information between peers in an IP network should be 
> sufficient for 
>         context transfer. However, given the above 
> considerations, there  
>         may be reason to provide for additional security 
> measures beyond the
> 
>         available IETF solutions.  
>          
>         The context transfer investigation must identify any 
> novel security
> 
>         measures required for context transfer that exceed 
> the capabilities
> 
>         of the existing or emerging IETF solutions. 
>          
>          
>      11 Recommendations 
>          
>         The Seamoby context transfer design team recommends 
> the following: 
>          
>                 - investigation into candidates for context 
> transfer - in 
>                   particular, feature context transfer, and 
> an analysis 
>                   of the transfer requirements for each candidate;  
>          
>                 - the development of a framework and 
> protocol(s) that will 
>                   support the transfer of configuration and 
> state context 
>                   between the forwarding nodes of an IP network. 
>          
>         The context transfer solution must interwork with 
> existing and 
>         emerging IP protocols, in particular, those protocols 
> supporting 
>         mobility in an IP network. 
>          
>          
>      References 
>          
>        
>      Levkowetz et al.                                         
>     [Page 10] 
>        
> 
>      Internet Draft                                           
>      June 2001
> 
>                draft-ietf-seamoby-context-transfer-problem-02.txt 
>        
>         [1] Blake, et al., "An Architecture for 
> Differentiated Services", 
>             RFC 2475, December 1998. 
>          
>         [2] Berger & O'Malley, "RSVP Extensions for IPSEC 
> Data Flows", 
>             RFC 2207, September 1997. 
>          
>      Authors' Addresses 
>         O. Henrik Levkowetz 
>         A Brand New World 
>         Osterogatan 1 
>         S-164 28 Kista   
>         SWEDEN 
>          
>         Phone: +46 8 477 9942 
>         EMail: [email-masked] 
>          
>          
>         Pat R. Calhoun 
>         Network and Security Research Center, Sun Labs 
>         15 Network Circle 
>         Menlo Park  CA 94025 
>         USA 
>          
>         Phone: +1 650-786-7733 
>         EMail: [email-masked] 
>          
>          
>         Gary Kenward 
>         Nortel Networks 
>         3500 Carling Avenue 
>         Nepean, Ontario  K2G 6J8 
>         CANADA 
>          
>         Phone: +1 613-765-1437 
>         EMail: [email-masked] 
>          
>          
>         Hamid Syed 
>         Nortel Networks 
>         100 Constellation Crescent 
>         Nepean  Ontario K2G 6J8 
>         CANADA 
>          
>         Phone: +1 613 763-6553 
>         EMail: [email-masked] 
>          
>         Jukka Manner 
>         Department of Computer Science, University of Helsinki 
>         P.O. Box 26 (Teollisuuskatu 23) 
>         FIN-00014 Helsinki 
>         FINLAND 
>        
>      Levkowetz et al.                                         
>     [Page 11] 
>        
> 
>      Internet Draft                                           
>      June 2001
> 
>                draft-ietf-seamoby-context-transfer-problem-02.txt 
>        
>          
>         Phone: +358-9-191-44210 
>         EMail: [email-masked] 
>          
>          
>         Madjid Nakhjiri 
>         Motorola 
>         1501 West Shure Drive 
>         Arlington Heights  IL 60004 
>         USA 
>          
>         Phone: +1 847-632-5030 
>         EMail: [email-masked] 
>          
>          
>         Govind Krishnamurthi 
>         Communications Systems Laboratory, Nokia Research Center 
>         5 Wayside Road 
>         Burlington  MA 01803 
>         USA 
>          
>         Phone: +1 781 993 3627 
>         EMail: [email-masked] 
>          
>          
>         Rajeev Koodli 
>         Communications Systems Lab, Nokia Research Center 
>         313 Fairchild Drive 
>         Mountain View  CA 94043 
>         USA 
>          
>         Phone: +1 650 625 2359 
>         EMail: [email-masked] 
>          
>          
>         Kulwinder S. Atwal 
>         Zucotto Wireless Inc. 
>         Ottawa  Ontario K1P 6E2 
>         CANADA 
>          
>         Phone: +1 613 789 0090 
>         EMail: [email-masked] 
>          
>          
>         Michael Thomas 
>         Cisco Systems 
>         375 E Tasman Rd 
>         San Jose  CA 95134 
>         USA 
>          
>         Phone: +1 408 525 5386 
>        
>      Levkowetz et al.                                         
>     [Page 12] 
>        
> 
>      Internet Draft                                           
>      June 2001
> 
>                draft-ietf-seamoby-context-transfer-problem-02.txt 
>        
>         EMail: [email-masked] 
>          
>          
>         Mat Horan 
>         COM DEV Wireless Group 
>         San Luis Obispo  CA 93401 
>         USA 
>          
>         Phone: +1 805 544 1089 
>         EMail: [email-masked] 
>          
>          
>         Phillip Neumiller 
>         3Com Corporation 
>         1800 W. Central Road 
>         Mount Prospect  IL 60056 
>         USA 
>          
>         EMail: [email-masked] 
>          
>          
>      Full Copyright Statement 
>          
>         Copyright (C) The Internet Society (2001). All Rights 
> Reserved. 
>          
>         This document and translations of it may be copied 
> and furnished to 
>         others, and derivative works that comment on or 
> otherwise explain it
> 
>         or assist in its implementation may be prepared, 
> copied, published 
>         and distributed, in whole or in part, without 
> restriction of any 
>         kind, provided that the above copyright notice and 
> this paragraph 
>         are included on all such copies and derivative works. 
> However, this 
>         document itself may not be modified in any way, such 
> as by removing 
>         the copyright notice or references to the Internet 
> Society or other 
>         Internet organizations, except as needed for the purpose of 
>         developing Internet standards in which case the 
> procedures for 
>         copyrights defined in the Internet Standards process must be 
>         followed, or as required to translate it into 
> languages other than 
>         English. 
>          
>         The limited permissions granted above are perpetual 
> and will not be 
>         revoked by the Internet Society or its successors or assigns. 
>          
>         This document and the information contained herein is 
> provided on an
> 
>         "AS IS" basis and THE INTERNET SOCIETY AND THE 
> INTERNET ENGINEERING 
>         TASK FORCE DISCLAIMS 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. 
>          
>      Acknowledgement 
>          
>        
>      Levkowetz et al.                                         
>     [Page 13] 
>        
> 
>      Internet Draft                                           
>      June 2001
> 
>                draft-ietf-seamoby-context-transfer-problem-02.txt 
>        
>         Funding for the RFC editor function is currently 
> provided by the 
>         Internet Society. 
>        
>      Levkowetz et al.                                         
>     [Page 14] 
> 
>