[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 RFC 4066

IETF Seamoby Working Group                             CARD Design Team
Internet Draft                                            Marco Liebsch
                                                             Ajoy Singh
                                                              (Editors)
                                                         Hemant Chaskar
                                                          Daichi Funato
draft-ietf-seamoby-card-protocol-00.txt
Expires: April 2003                                        October 2002


                     Candidate Access Router Discovery


Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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

   To view the list of Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.



Abstract

   To enable seamless IP-layer handover of a mobile node (MN) from one
   access router (AR) to another, the MN or the MN's current AR is
   required to discover the identities of candidate ARs (CARs) for
   handover, along with their capabilities, prior to the initiation of
   the IP-layer handover. The act of discovery of CARs has two aspects
   to it: Identifying the IP addresses of the CARs and finding the
   capabilities of those CARs. This process is called "candidate access
   router discovery" (CARD). At the time of IP-layer handover, that
   CAR, whose capabilities are a good match to the preferences of the
   MN, may be chosen as the target AR (TAR) for handover. This draft
   describes a solution to perform CARD.


CARD Design Team         Expires û April 2003                 [Page 1]


Internet-Draft     Candidate Access Router Discovery      October 2002




TABLE OF CONTENTS

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of CARD Protocol. . . . . . . . . . . . . . . . . . . . 4
   3.1 Reverse Address Translation. . . . . . . . . . . . . . . . . 4
   3.2 Discovery of CAR Capability. . . . . . . . . . . . . . . . . 5
4. Protocol Design Considerations . . . . . . . . . . . . . . . . . 6
   4.1 Mobile Node Types. . . . . . . . . . . . . . . . . . . . . . 6
      4.1.1 MN Type 1 . . . . . . . . . . . . . . . . . . . . . . . 6
      4.1.2 MN Type 2 . . . . . . . . . . . . . . . . . . . . . . . 6
      4.1.3 MN Type 3 . . . . . . . . . . . . . . . . . . . . . . . 6
   4.2 Availability of Security Association . . . . . . . . . . . . 6
      4.2.1 Availability of SA between AR(s). . . . . . . . . . . . 7
      4.2.2 Availability of SA between AR and MN. . . . . . . . . . 7
   4.3 Location of TAR Selection Algorithm. . . . . . . . . . . . . 7
      4.3.1 TAR Selection at the MN . . . . . . . . . . . . . . . . 7
      4.3.2 TAR Selection at the Current AR . . . . . . . . . . . . 7
5. Modes of Protocol Operation. . . . . . . . . . . . . . . . . . . 8
   5.1 Mobile Node orchestrated mode. . . . . . . . . . . . . . . . 8
      5.1.1 MN Type 1 . . . . . . . . . . . . . . . . . . . . . . . 9
      5.1.2 MN Type 2 . . . . . . . . . . . . . . . . . . . . . . . 9
   5.2 Network Assisted Mode. . . . . . . . . . . . . . . . . . . . 9
      5.2.1 MN Type 1 . . . . . . . . . . . . . . . . . . . . . . . 9
      5.2.2 MN Type 2 . . . . . . . . . . . . . . . . . . . . . . .10
6. Protocol Messages and Operation. . . . . . . . . . . . . . . . .11
   6.1 CARD Messages for the interface MN - AR. . . . . . . . . . .11
   6.2 CARD Messages for the interface between ARs. . . . . . . . .14
7. Security Considerations. . . . . . . . . . . . . . . . . . . . .14
8. Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .15



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










CARD Design Team         Expires û April 2003                 [Page 2]


Internet-Draft     Candidate Access Router Discovery      October 2002


1. Introduction

   IP mobility protocols enable mobile nodes (MNs) to execute IP-level
   handover between access routers (ARs). CAR discovery (CARD) enables
   acquiring information about the ARs that are candidates (CARs) for
   the MN's handover.

   In future wireless networks, there will be cases when a MN has a
   choice of performing IP-level handover to different CARs. The MN
   would then choose one of them as a target access router (TAR) for
   handover, based on a match between a MN's requirements and CARs'
   capabilities. The MN requires some means of obtaining information
   about the CARs so that the best decision about the TAR can be made.
   The CARD protocol enables this.

   The problem statement and requirements for CARD are discussed in [2]
   and [3] respectively. In this draft, we describe a solution to
   perform CARD. We begin by describing two main functional blocks of
   the CARD protocol. Then, we identify a number of factors that affect
   the operation of the CARD protocol in different handover scenarios.
   These factors include: MN communication capabilities, security
   association between network elements, location of execution of TAR
   selection algorithm as well as performance aspects. Then, we
   describe two modes of protocol operation that we think cover most of
   the important handover scenarios.

   This first version of the document is intended to expose the factors
   required to be considered, and alternatives available for the design
   of CARD protocol. The intent of the design team is to get working
   group consensus on these issues, so as to define the scope of CARD
   protocol design.


2. Terminology

   Mobile Node (MN)

   A Mobile Node is an IP host capable of moving its point of
   attachment to the Internet.

   Access Point (AP)

   A radio transceiver by which a MN obtains Layer 2 connectivity with
   the wired network.

   Access Router (AR)

   An IP router residing in an access network and connected to one or
   more APs. An AR offers IP connectivity to MNs.


CARD Design Team         Expires û April 2003                 [Page 3]


Internet-Draft     Candidate Access Router Discovery      October 2002



   Candidate AR (CAR)

   An AR to which a MN has a choice of performing IP-level handover.
   This implies that the MN has the right radio interface to connect to
   an AP that is served by this AR, as well as the coverage of this AR
   overlaps with that of the AR to which the MN is currently attached
   to.

   Capability of AR

   A characteristic of the service offered by an AR that may be of
   interest to a MN when the AR is being considered as a handover
   candidate.

   L2 ID

   Identifier of an AP, that uniquely identifies that AP. For example,
   in 802.11 PCF, this could be a MAC address of an AP.

   Target AR (TAR)

   An AR with which the procedures for the MN's IP-level handover are
   initiated. The TAR is selected after running a TAR Selection
   algorithm that takes into account the capabilities of CARs,
   preferences of the MN and any other local policies.



3. Overview of the CARD Protocol

   A CARD protocol consists of the following main functional building
   blocks.

3.1 Reverse Address Translation

   This functionality refers to mapping the L2 ID of a new AP that the
   MN can connect to, to the IP address of the CAR that connects to the
   new AP. In cases where the MN can acquire IP connectivity with CARs
   prior to making handover decisions, this functionality is trivially
   realized.

   However, if a MN can only listen to L2 IDs of new APs prior to
   making decision about IP-level handover to CARs, a special mechanism
   is needed for reverse address translation. This could be realized
   via cached information in the MN. Alternatively, the MN may seek the
   help of the current AR, wherein the MN sends L2 IDs of new APs to
   the current AR and expects it to resolve the L2 IDs to the IP
   address of CARs.


CARD Design Team         Expires û April 2003                 [Page 4]


Internet-Draft     Candidate Access Router Discovery      October 2002



   Note: In some networks, such as cellular networks, link-layer
   technology may be capable of delivering the L2 ID of the new AP to
   the current AR.

   Finally, few comments are in order. First, note that the new AR can
   be in a different subnet than that of the current AR (even far away
   from the current AR in terms of IP hops). Second, when the MN
   delivers L2 IDs of APs to the reverse address translation module,
   implicit is the assumption that MN is satisfied with the signal
   strength of the new APs. Lower level criteria such as signal
   strength are out of scope of capabilities that we refer to in the
   next section. Finally, establishment of a L2 security association
   between a MN and individual AP(s) is assumed to be performed in
   accordance with the relevant L2 mechanism, and is outside the scope
   of the CARD protocol.


3.2 Discovery of CAR Capability

   Information about capabilities of CARs can assist the MN in making
   optimized handover decisions. This capability information serves as
   input to the TAR selection algorithm. Some of the capability
   parameters of CARs can be static, some others can change only on a
   long time scale, while the rest can be highly dynamic. For the
   capability parameter that changes over time, a lifetime can be
   associated. Format and definition of capabilities is out of scope of
   the CARD protocol design.

   If the MN can establish solid IP connectivity with CARs before
   making handover decisions, the MN can directly ask for capability
   information from the CARs. Alternatively, certain capabilities may
   be periodically transmitted over downlink broadcast channels. In
   either case, it is natural to execute TAR selection algorithm on the
   MN.

   On the other hand, if the MN cannot establish IP connectivity with
   CARs before making handover decisions, the current AR can assist the
   MN in retrieving capability information from the CAR. Then the TAR
   selection algorithm may be executed on the current AR (assuming the
   current AR knows the MN's preferences) or on the MN. If TAR
   selection is performed on the MN, capability information about CARs
   may need to be transmitted to the MN.








CARD Design Team         Expires û April 2003                 [Page 5]


Internet-Draft     Candidate Access Router Discovery      October 2002


4. Protocol Design Considerations

   The CARD protocol design highly depends upon the characteristics of
   the underlying access technologies, MN communication capabilities,
   as well as the roaming and security policies of the network access
   service providers. This section identifies a set of parameters that
   can vary across various access technologies (or across various
   deployments of the same access technology) and MN capabilities, and
   are also important enough to be considered by the CARD protocol to
   ensure its wider deployment.

4.1 Mobile Node Types

   The design of the CARD protocol is dependent upon the communication
   characteristics of the MNs. We have classified the MNs in the
   following three categories namely, type 1, type 2 and type 3.

4.1.1 MN Type 1

   This type of MN provides IP layer connection with the current AR
   only. However, the MN is capable of listening to the L2 beacons from
   the neighboring AP(s) and thereby deducing their L2 ID(s). For
   example, 802.11 families of MN or cellular handsets with the mobile
   assisted handover capability are capable of performing the
   aforementioned functions.

4.1.2 MN Type 2

   This type of MN can support multiple IP layer connections
   simultaneously: one with the current AR and at least one with the
   CAR. MNs with multiple network interface cards can be classified as
   type 2 mobiles.

4.1.3 MN Type 3

   This type of MN supports single IP layer connection with the current
   AR. Unlike type 1, either they are not able to receive L2 beacons
   from the neighboring AP(s) or deduce the link layer ID(s) of the
   AP(s) from the received beacons. It is very difficult to design the
   CARD protocol to support this type of MN. We currently do not
   consider this type of MNs during CARD protocol design.

4.2 Availability of Security Association

   The design of the CARD protocol is also dependent upon the
   availability of the SAs among various access network elements and
   the MN. This section describes such security options.




CARD Design Team         Expires û April 2003                 [Page 6]


Internet-Draft     Candidate Access Router Discovery      October 2002


4.2.1 Availability of SA between AR(s)

   Depending upon the deployment scenarios of access networks, SA may
   or may not be available between current AR and the CAR(s). It is
   reasonable to assume availability of SA between ARs belonging to the
   same domain, but the same assumption may not be valid for ARs
   belonging to different domains.

4.2.2 Availability of SA between AR and MN

   It is implicit that the MN will have a SA with the current AR.
   However, it may or may not have the required SA(s) or ability to
   establish SA(s) with the CAR(s). This has implications on whether
   the MN can directly obtain capability information from CAR(s) in a
   secure manner.

4.3 Location of TAR Selection Algorithm

   The design of the CARD protocol should also take into consideration
   the various options for the location of the TAR selection algorithm,
   so that capability information gathered by the CARD protocol can be
   provided to the TAR selection algorithm. The TAR selection algorithm
   can either be located at the MN or the current AR.

   For instance, the TAR selection algorithm can be located at the MN
   when a type 2 or type 1 MN, by utilizing the available SAs between
   the MN and CARs, can obtain the capability information from the
   CARs. Alternatively, the TAR selection can be performed at the
   current AR when the current AR, upon receiving a request from the
   MN, can obtain the capability information from the CARs.

4.3.1 TAR Selection at the MN

   In this case, the MN receives capability information from CARs and
   selects one from the list with the best matching capabilities as the
   TAR. Depending upon the MN type, the MN can receive capability
   information directly from CARs either over the Internet and the
   current access link or over the new access link. This mode of
   operation may cause large capability traffic on access links and
   drain on MN battery power.

4.3.2 TAR selection at the Current AR

   In this case, the current AR gathers capability information about
   CARs and matches it with the MN's preferences to determine the TAR.
   Unlike the previous case, over the air capability traffic associated
   with this type of TAR selection strategy may not be large.




CARD Design Team         Expires û April 2003                 [Page 7]


Internet-Draft     Candidate Access Router Discovery      October 2002


5. Modes of Protocol Operation

   This section describes two different operational modes for the CARD
   protocol, namely the "MN Orchestrated Mode" and the "Network
   Assisted" Mode. The purpose of specifying two operational modes is
   to cover different handover scenarios dictated by factors described
   in section 4.

   During a given handover event, the operational mode used for CARD is
   necessarily governed by the physical restrictions imposed by access
   networks and MN communication capabilities. When choice is possible,
   factors such as efficiency and local policy should also be
   considered in deciding about the right CARD mode to be used in a
   given handover event.

5.1 Mobile Node Orchestrated mode

   This mode assumes that all the control for executing CARD
   functionality, such as reverse address translation and capability
   discovery, resides in the MN. CARs merely provide MNs with the
   capability information over IP connectivity on demand. This mode
   requires that the MN is able to establish IP connectivity with CARs
   while keeping the link to its current AR. In this mode it is most
   natural to perform TAR selection in the MN, as the capability
   information required for the TAR selection algorithm is readily
   available in the MN.

   The advantage of this mode is that it allows CARD to be performed
   without protocol interactions between a MN's current AR and CARs,
   since the MN directly interacts with CARs for the purpose of CARD.
   This mode requires availability of SAs between the MN and its CARs.
   SAs between the MN and CARs can either be pre-established or
   established on demand.

   This operational mode entails the transmission of capability
   information over the access link, which may be suboptimal with
   regard to meeting the requirement on efficient usage of access link
   resources as well as minimizing the drainage of a MN's battery
   energy.

   The following subsections evaluate the MN orchestrated mode for the
   different types of MNs, as addressed in section 4.1.









CARD Design Team         Expires û April 2003                 [Page 8]


Internet-Draft     Candidate Access Router Discovery      October 2002


5.1.1 MN Type 1

   For the type 1 MNs to be able to use this CARD mode, it is necessary
   to perform reverse address translation on the MN without any support
   from its current AR. After having the IP addresses of CARs resolved,
   capability discovery can be performed between the MN and the CARs
   over the current access link. Details on how to perform reverse
   address translation with type 1 mobile nodes are out of the scope of
   this document.

5.1.2 MN Type 2

   The type 2 MNs can perform CARD using this operational mode. This is
   because type 2 MNs can engage in simultaneous communication with the
   current AR as well as CARs on IP level. After connections and SAs
   have been established to CARs, CARD can be performed from the MN to
   individual CARs in parallel with the existing connection to the
   current AR.

   Access link bandwidth consumption may not be a problem for low cost
   and low traffic access links such as personal bluetooth link or
   private WLAN hot spots. For other types of access links such as
   cellular or public WLAN, this may be undesirable.


5.2 Network Assisted Mode

   This operational mode requires support from the current AR for CARD.
   Some CARD functional entities can be associated with ARs to support
   reverse address translation and discovery of CAR capabilities when
   being the current AR of the MN. This mode also requires protocol
   interactions and hence availability of trust relationship between
   the current AR and CARs. For the discovery of CARs within the same
   administrative domain as that of the current AR, security
   associations between AR and CARs could be taken for granted. In case
   of the current AR and CARs being located in different domains,
   roaming agreement may be a way to allow for security associations
   between the current AR and CARs. In any case, the security
   association between the MN and its current AR can be taken for
   granted. The TAR selection algorithm can be implemented either in
   the (current) ARs or in the MN.

5.2.1 MN Type 1

   The type 1 MN is capable of scanning other APs and obtaining their
   L2 IDs. This information is provided to the MN's current AR. The
   current AR performs reverse address translation and obtains the
   capability information from the corresponding CARs. This information
   is conveyed back to the MN in case of implementing the TAR selection


CARD Design Team         Expires û April 2003                 [Page 9]


Internet-Draft     Candidate Access Router Discovery      October 2002


   in the MN. In case of implementing the TAR selection function on the
   current AR, the MN gets information on the TAR from its current AR.
   Optionally, the TAR's capability information can be conveyed to the
   MN after TAR selection has been performed by the current AR.

5.2.2 MN Type 2

   The type 2 MNs can perform Network Assisted CARD in exactly the same
   manner as type 1 MNs. Then, the feature of type 2 MNs of being able
   to establish IP connectivity with CAR(s) is not utilized.


Capability pre-filtering:

   In case of implementing TAR selection in the MN, CAR capabilities
   are required to be conveyed to the MN as input to the TAR selection
   algorithm. The following approaches can be used for this purpose:


   (A) Providing full capability set for TAR selection

   The MN receives the full set of capability information from the
   sender of capabilities. In the MN orchestrated mode, this sender is
   the CAR, while in the network assisted mode it is the current AR.

   Since no MN preferences for capabilities are to be transmitted to
   the current AR, but the full set of capability information is to be
   conveyed to the MN, this approach is "uplink optimized".


   (B) Providing partial capability set for TAR selection

   The MN sends its preferences for capabilities to the current AR. In
   response, the AR sends a pre-filtered subset of the CARs'
   capabilities to the MN to be used as input for the TAR selection
   function.

   Since this approach considers a reduced set of capabilities to be
   sent to the MN but assumes a set of preferences to be sent
   previously to the current AR, this approach is "downlink optimized".

   As an enhancement to approach (B), context transfer (CT) framework
   [4,5] can help to avoid sending the MN's preferences for pre-
   filtering the capability information to the current AR for each
   handover event. After the MN's preferences for pre-filtering have
   been provided to the current AR once, this information can be
   transferred to the selected TAR by means of CT mechanisms.




CARD Design Team         Expires û April 2003                [Page 10]


Internet-Draft     Candidate Access Router Discovery      October 2002


6. Protocol Messages and Operation

   The process of selecting the TAR for the MN's IP-layer handover can
   be performed in two steps: Identifying the CARs along with their
   capabilities and then selecting the appropriate AR from the CAR list
   as TAR. The AR or MN invokes the CARD process when it receives an
   indication about the discovery of a new AP ID by the MN during L2
   scan process. The CARD process can take place before the L3 handover
   event, whereas the TAR selection process is invoked when the current
   AR or MN receives indication of imminent L3 handover via some L2
   triggers. For the sake of efficiency, it should be possible to
   piggyback CARD messages over IP-layer handoff signaling, whenever
   possible. At the same time, to cater to timing issues, when
   piggybacking is not feasible, it should be possible to send CARD
   messages independent of IP-layer handoff signaling and to allow for
   stand-alone deployment of CARD. A way to achieve this is to encode
   CARD messages as generic TLV-encoded ICMP options. These options can
   be piggybacked over other ICMP messages of IP-layer handoff
   signaling or can be send in separate ICMP messages.

   It is necessary to identify two main interfaces across which CARD
   messages would be sent. These are: interface between MN and AR and
   interface between AR and AR. Note here that the interface between
   the MN and AR can either be between a MN and the MN's current AR or
   between a MN and a CAR.


6.1 CARD Messages for the interface MN - AR

   The MN periodically listens to the beacons from neighboring AP(s)
   and sends a CARD request message containing the L2 ID(s) of the
   newly discovered AP(s) to the current AR, when using network
   assisted CARD. When using the MN orchestrated mode, there is no need
   to carry L2 IDs of AP(s), but preferences for capabilities need to
   be conveyed to CAR(s) by means of an appropriate parameter option in
   case of pre-filtering of capabilities at CAR(s) is deployed.

   While performing TAR selection on the current AR in network assisted
   mode, the MN needs to send its requirement to the current AR.












CARD Design Team         Expires û April 2003                [Page 11]


Internet-Draft     Candidate Access Router Discovery      October 2002


Message Format:

   One ICMP main header is defined to allow for stand-alone CARD
   operation as described above. Then two TLV-encoded ICMP options,
   namely CARD REQUEST and CARD REPLY, are defined. These two options
   carry the parameters for CARD as sub-options.



   ICMP main header
   ----------------

    - ICMP basic format, contains Type-Length-Checksum. This carrier is
      needed for CARD protocol stand-alone deployment. The main header
      does not appear for CARD protocol piggybacking.

   Encoding: ICMP standard header 32 bit (Type-Length-Checksum)

   Valid options:

   CARD ICMP options and appropriate sub-options as described below.



   Valid ICMP options for CARD
   ---------------------------

   CARD signaling is based on the following 2 ICMP options:

    - CARD REQUEST option, sent from a MN to the current AR
                   or to CARs.

   Encoding:       ICMP option, contains ->  o Sequence Number
                                             o Flags

   Sequence Number: To allow correlation of replies with requests.
   Flags: To indicate the operational mode and the interface where the
   protocol message is deployed.

   Various sub-options can be attached to the CARD REQUEST option, as
   described below.


    - CARD REPLY option, sent from the AR(s) to the MN.

   Encoding:       ICMP option, contains ->  o Sequence Number
                                             o Flags

   Meaning of Sequence Number and Flags is the same as above.


CARD Design Team         Expires û April 2003                [Page 12]


Internet-Draft     Candidate Access Router Discovery      October 2002



   Various sub-options can be attached to the CARD REPLY option, as
   described below.



   Valid sub-options for CARD
   --------------------------


   The CARD protocol specifies 5 sub-options for CARD:

    - L2 ID:        Conveys the AP identifier from MN to current AR

    - PREFERENCES:  Conveys MN preferences for pre-filtering of
                    capabilities from the MN to the current AR or CAR

    - REQUIREMENTS: Conveys MN requirements for TAR selection from the
                    MN to the current AR

    - CAPABILITY:   Container to carry CAR capabilities from the
                    current AR or CAR to the MN

    - TAR ADDRESS:  Carries the selected TAR's address

   Encoding: All sub-options are TLV-encoded and can be attached to the
   message options according to the protocol operation.



Details on the use of sub-options with CARD options:

   The following table indicates the use of individual sub-options with
   CARD options, dependent on the operational mode and the location of
   the TAR selection function.

   For network assisted CARD operation, the table additionally
   indicates a sub-option's presence by "<MN>" in case of having the
   TAR selection implemented in the MN. When TAR selection is performed
   on the current AR, a parameter's presence is indicated by "<AR>".











CARD Design Team         Expires û April 2003                [Page 13]


Internet-Draft     Candidate Access Router Discovery      October 2002



                  |   Network Assisted    |   MN Orchestrated    |
                  +-----------------------+----------------------+
                  |  CARD REQ | CARD REPL | CARD REQ | CARD REPL |
     -------------+-----------+-----------+----------+-----------+
     L2 ID        |     x     |           |          |           |
     PREFERENCES  |     x <MN>|           |     x    |           |
     REQUIREMENTS |     x <AR>|           |          |           |
     CAPABILITY   |           |     x <MN>|          |     x     |
     TAR ADDRESS  |           |     x <AR>|          |           |




6.2 CARD Messages for the interface between ARs (AR - AR)

   In general, for the interface between ARs, same messages and
   parameters can be deployed. Distinction of the interfaces, where the
   protocol message is deployed, is considered to be done in the flags
   field of the ICMP option.

   To take additional requirements for ensured reliability of control
   message transport into consideration, appropriate transport
   mechanisms are to be evaluated. This is TBD and to be discussed with
   the WG.



7. Security Considerations

   Related issues on the availability of security associations are
   discussed in section 4.2. For additional security concerns, the
   reader is referred to [3].



8. References

   [1]Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   [2]Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J. ôIssues in
      candidate access router discovery for seamless IP-level
      handoffs", draft-ietf-seamoby-cardiscovery-issues-04.txt, work in
      progress, October 2002.






CARD Design Team         Expires û April 2003                [Page 14]


Internet-Draft     Candidate Access Router Discovery      October 2002




   [3]Krishanmurti, G., ôRequirements for CAR Discovery     Protocolsö,
      draft-ietf-seamoby-card-requirements-02.txt, a work in progress,
      October 2002.

   [4]Kempf, J.,"Problem Description: Reasons For Performing Context
      Transfers Between Nodes in an IP Access Network", RFC 3374,
      September 2002.

   [5]Kenward, B.,"General Requirements for Context Transfer", draft-
      ietf-seamoby-ct-reqs-05.txt, a work in progress, October 2002.




Authors' Addresses

   Hemant Chaskar
   Nokia Research Center
   5 Wayside Road
   Burlington, MA 01803, USA
   Phone: 781 993 3785
   Email: Hemant.Chaskar@nokia.com

   Daichi Funato
   NTT DoCoMo USA Labs
   181 Metro Drive, Suite 300
   San Jose, CA 95110, USA
   Phone: +1 408-451-4736
   EMail: funato@docomolabs-usa.com

   Marco Liebsch
   NEC Network Laboratories
   Adenauerplatz 6, 69115 Heidelberg
   Germany
   Phone: +49/(0)6221 1370811
   Email: marco.liebsch@ccrle.nec.de

   Ajoy Singh
   Motorola Inc
   1501 West Shure Dr
   Phone: 847 632 6941
   Email: asingh1@email.mot.com







CARD Design Team         Expires û April 2003                [Page 15]


Internet-Draft     Candidate Access Router Discovery      October 2002





















































CARD Design Team         Expires û April 2003                [Page 16]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/