IETF Seamoby Working Group                      Govind Krishnamurthi,
INTERNET-DRAFT                                  Editor,
1 May 2002                                      Nokia Research Center



               Requirements for CAR Discovery Protocols
              draft-ietf-seamoby-card-requirements-00.txt

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 made obsolete 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.



ABSTRACT

The pre-requisite for IP based seamless mobility protocols is the
knowledge of the access router (AR) to which a mobile node can be
handed over to. Further, a handoff can be optimized if the capabilities
of the AR being considered for handoff are known. The protocol which
discovers ARs for potential handoff along with their capabilities is
called the CAR discovery protocol. In this draft we list the
requirements which are to be met by any solution for CAR Discovery.











Krishnamurthi, Editor                                        [Page i]


INTERNET-DRAFT  Requirements for CAR Discovery Protocols    May, 2002


 TABLE OF CONTENTS

    1. INTRODUCTION                                           2

    2. TERMINOLOGY                                            2

    3. REQUIREMENTS FOR CAR DISCOVERY PROTOCOLS

       3.1 IDENTIFYING THE IP ADDRESSES OF GAARs              3

       3.2 SUPPORT FOR INTER-TECHNOLOGY HANDOFFS              3

       3.3 IDENTIFYING GAARS HAVING SITE-LOCAL AND
           PRIVATE ADDRESSES                                  4

       3.4 CAPABILITY DISCOVERY                               4

       3.5 UTILIZATION OF NETWORK RESOURCES                   4

       3.6 FORMAT OF CAPABILITIES                             4

       3.7 SCOPE OF CAR DISCOVERY                             4

       3.8 INTRODUCTION OF DEDICATED NETWORK ELEMENTS FOR
           CAR DISCOVERY                                      4

       3.9 INVOLVEMENT OF NON-GAARs IN CAR DISCOVERY          5

       3.10 DEPENDENCE ON A PARTICULAR MOBILITY MANAGEMENT
            PROTOCOL                                          5

       3.11 EFFECT OF CHANGES IN NETWORK TOPOLOGY             5

       3.12 PROVIDING THE MN'S REQUIREMENTS TO THE CAR
            DISCOVERY SOLUTION                                5

       3.13 SECURITY REQUIREMENTS                             5

       3.13.1 SECURE CAPABILITY TRANSFER                      5

       3.13.2 VERIFICATION OF ROUTER AUTHENTICITY             5

       3.13.3 SECURE INTER-OPERABILITY WITH IETF PROTOCOLS    6

       3.13.4 SECURE EXPRESSION OF MN's REQUIREMENTS
              TO THE CAR DISCOVERY SOLUTION                   6






Krishnamurthi, Editor                                        [Page 1]


INTERNET-DRAFT  Requirements for CAR Discovery Protocols    May, 2002


    4. ACKNOWLEDGEMENTS                                       6

    5. REFERENCES                                             6

    6. EDITOR'S ADDRESS                                       7




1. INTRODUCTION

CAR discovery protocols perform the function of identifying the
candidate access routers along with their capabilities for a mobile
node's (MN) handoff. CAR discovery can be used by seamless handoff
protocols [1,2,3,4] to decide the access router to which the mobile
node will be handed over to. The problem statement for CAR discovery
is discussed in [5]. In this draft, we present the requirements that
any solution for CAR discovery needs to satisfy.

2. TERMINOLOGY

In this draft, we use the same terminology as described in [5].

Access Point (AP)

  A radio transceiver by which an 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 MN.

Geographically Adjacent AR (GAAR)

  An AR whose coverage area is such that an MN may move from the
  coverage area of the AR currently serving the MN into the coverage
  area of this AR. In other words, GAARs have APs whose coverage areas
  are geographically adjacent or overlap.

Capability of AR

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

Candidate AR (CAR)

  This is an AR that is a candidate for MN's handoff. CAR is necessarily
  a GAAR of the AR currently serving the MN, and also has the capability
  set required to serve the MN.

Krishnamurthi, Editor                                        [Page 2]


INTERNET-DRAFT  Requirements for CAR Discovery Protocols    May, 2002

Target AR (TAR)

  This is the AR with which the procedures for the MN's IP-level handoff
  are initiated. TAR is usually selected from the set of CARs.

TAR Selection Algorithm

  The algorithm that determines a unique TAR for MN's handoff from the
  set of CARs. The exact nature and definition of this algorithm is
  outside the scope of this document.

3. REQUIREMENTS FOR THE CAR DISCOVERY SOLUTION

In this section, we list the set of requirements that must be met
by the CAR discovery solution. Generic IETF practices such as
re-use of existing IETF protocols wherever possible MUST be adhered
to when designing the CAR discovery solution.

3.1  IDENTIFYING THE IP ADDRESS OF A GAAR

 If an AP identifier is forwarded as an input to the CAR discovery
 protocol it MUST be able to map the identifier to the IP address of the
 AR which the AP is connected to. This is motivated by the fact that,
 for example, an MN may only be able to receive the link layer
 identifier of an AP connected to potential target ARs. This has to be
 mapped to the IP address of the AR the AP is connected to. The exact
 identifiers that are advertised for different link layer technologies
 can be obtained from the appropriate standards. However, in some cases,
 the CAR discovery solution may be able to directly identify the IP
 address of the GAAR. In such a case, the previously mentioned mapping
 from the L2 identifiers to IP addresses of ARs may not be necessary.

3.2 SUPPORT FOR INTER-TECHNOLOGY HANDOFFS

Though not common now, it is possible that in the future, MNs may have
interfaces belonging to different technologies thus facilitating the
possibility of inter-technology handoffs. An example for this, among
others, is a handoff from an 802.11 based LAN to a 3G based cellular
network. The CAR discovery solution therefore MUST be able to identify
the IP addresses of GAARs connected to APs of a different technology.













Krishnamurthi, Editor                                        [Page 3]


INTERNET-DRAFT  Requirements for CAR Discovery Protocols    May, 2002


3.3 IDENTIFYING GAARS HAVING SITE-LOCAL AND PRIVATE ADDRESSES

Support for handoffs between IPv4 and IPv6 is critical in the design of
protocols dealing with mobility. Once IPv4 networks come into the
picture we have to deal with the possibility of private address spaces.
Even in the case of IPv6 networks, we have the possibility of private
spaces. For example, the policy of a particular domain may be not to
expose the globally routable IPv6 addresses of its ARs for security
reasons. To support such scenarios, the CAR discovery solution MUST be
able to discover GAARs with non globally routeable IP addresses along
with their capabilities. This is contingent on whether the operator of
the network permits such handoffs.


3.4 CAPABILITY DISCOVERY

The CAR discovery solution MUST provide functionality to discover
a GAAR's capabilities. The CAR discovery solution MUST be able
to provide the MN with GAAR information along with their capabilities.

3.5 UTILIZATION OF NETWORK RESOURCES FOR CAR DISCOVERY

The CAR discovery solution MUST be able to make efficient use of
the network resources and SHOULD avoid the transmission of unnecessary
information to the MN.


3.6 FORMAT OF CAPABILITIES

This is a requirement for inter-operability. The capabilities
of GAARs MUST be described in a standard format. The format is TBD.

3.7 SCOPE OF CAR DISCOVERY

The Internet is formed by several administrative domains  clustered
together. As explained in [5], GAARs could belong to different
administrative domains separated by large distances
in terms of IP hops. Therefore, the CAR discovery solution
MUST have an Intra-domain scope and SHOULD have Inter-domain scope.

3.8 INTRODUCTION OF DEDICATED NETWORK ELEMENTS FOR CAR DISCOVERY

The CAR discovery solution  MUST NOT introduce network elements
 dedicated to CAR discovery.







Krishnamurthi, Editor                                        [Page 4]


INTERNET-DRAFT  Requirements for CAR Discovery Protocols    May, 2002


3.9  INVOLVEMENT OF NON-GAARs IN CAR DISCOVERY

Handoffs might happen very frequently. If the CAR discovery process
introduced additional load on ARs which are not GAARs, this will impede
their performance. Therefore the CAR discovery solution SHOULD minimize
the involvement of non-GAARs.

3.10 DEPENDENCE ON A MOBILITY MANAGEMENT PROTOCOL

CAR discovery MUST NOT depend on a particular mobility management
protocol. In other words, it MUST NOT depend on a feature which is
unique to a particular mobility management protocol. The output of CAR
discovery, however, MUST be usable by mobility management protocols.
CAR discovery MUST NOT deteriorate the performance of the underlying
mobility management protocol.

3.11 EFFECT OF CHANGES IN NETWORK TOPOLOGY

Networks topology can change for several reasons, for example, network
renumbering. The CAR discovery solution MUST be adaptive to such
changes in the topology of the network.


3.12 PROVIDING THE MN's REQUIREMENTS TO THE CAR DISCOVERY SOLUTION

The CAR discovery solution MUST provide means for the MN to provide
its requirements. These requirements MUST be used in determining
the CARs for the MN. The MN preference solution SHOULD be logically
separate from the CAR information distribution solution in order to
maintain separation of security requirements.


3.13 SECURITY REQUIREMENTS

3.13.1 SECURE CAPABILITY TRANSFER

The CAR discovery solution MUST ensure that the capability information
of GAARs is transferred in a secure fashion.

3.13.2 VERIFICATION OF ROUTER AUTHENTICITY

This requirement has the following  parts:
(i) The CAR discovery solution MUST be able to verify that the router
under consideration as a GAAR is a genuine AR.
(ii) The CAR discovery solution SHOULD be able to verify that such an AR
is a GAAR. In other words, this AR has APs whose coverage areas overlap
with at least one AP of the AR the MN is currently receiving its IP
connectivity.




Krishnamurthi, Editor                                        [Page 5]


INTERNET-DRAFT  Requirements for CAR Discovery Protocols    May, 2002


3.13.3 SECURE INTER-OPERABILITY WITH IETF PROTOCOLS

Security on CAR information and capabilities distribution MUST
conform and inter operate with existing IETF security policies and
protocols on the security of routing information distribution.

3.13.4 SECURE EXPRESSION OF MN's REQUIREMENTS TO THE CAR DISCOVERY
SOLUTION

The CAR discovery solution MUST provide a secure means of expression
of the MN's requirements to the CAR discovery protocol. Security
on communication of MN preferences to ARs MUST conform and inter operate
with existing IETF security and AAA policies and protocols for host
security, where applicable.


4. ACKNOWLEDGEMENTS

The contributions (in alphabetical order) of Hemant Chaskar (Nokia),
Steve Deering (Cisco), James Kempf (DoCoMo Labs), Jari T. Malinen
(Nokia), Phil Neumiller (Mesh Networks), Hesham Soliman (Ericsson),
and Dirk Trossen (Nokia) were valuable in preparation of this document.


5. REFERENCES

[1] MIPv4 Handoffs Design Team,Low Latency Handoffs in Mobile IPv4,
    draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt,
    work in progress, February 2001.

[2] MIPv6 handoff Design Team,Fast handoffs for Mobile IPv6,
    draft-ietf-mobileip-fast-mipv6-01.txt,
    work in progress, April 2001.

[3] O. H. Levkowetz et. al.,Problem Description: Reasons For Performing
    Context Transfers Between Nodes in an IP Access Network, draft-ietf-
    seamoby-context-transfer-problem-stat-01.doc, work in progress, May
    2001.

[4] H. Sayed et. al., General requirements for a context transfer
    framework, draft-ietf-seamoby-ct-reqs-00.txt, work in progress, May
    2001.

[5] D. Trossen, G. Krishnamurthi, H. Chaskar, J. Kempf, Issues in
    candidate access   router discover for seamless IP-level handoffs,
    draft-ietf-seamoby-car-discovery-02.txt,work-in-progress, January
    2002.





Krishnamurthi, Editor                                        [Page 6]


INTERNET-DRAFT  Requirements for CAR Discovery Protocols    May, 2002




6. EDITOR'S ADDRESS

Govind Krishnamurthi
Communication Systems Laboratory
Nokia Research Center
5 Wayside Road
Burlington, MA 01803, USA

Phone:  +1 781 993 3627
Fax:  +1 781 993 1907
E-mail:  govind.krishnamurthi@nokia.com







































Krishnamurthi, Editor                                        [Page 7]