INTERNET DRAFT                                               Pete McCann
Category:                                                     Tom Hiller
Title: draft-mccann-thema-00.txt                                Jin Wang
Date: March 1999                                          Alessio Casati
                                                     Lucent Technologies
                                                      Charles E. Perkins
                                                          Pat R. Calhoun
                                                   Sun Laboratories, Inc


                Transparent Hierarchical Mobility Agents
                                (THEMA)

                       draft-mccann-thema-00.txt

Status of this Memo

   This document is an Internet Draft and is in full compliance 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.  Internet Drafts 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.


Abstract

   For various reasons it may be desirable to separate the
   functionality of a mobility agent, such as the home and foreign
   agents in Mobile IP [Perkins96], from their link-layer presence on a
   given network.  This draft outlines mechanisms based on the Tunnel
   Establishment Protocol [Calhoun98a] for accomplishing this.  The
   tunnels so established will not be visible to a mobile node and
   therefore provide a transparent way to build hierarchies of mobility
   agents, which can lessen the frequency of Mobile IP re-
   registrations.





McCann et al.               Expires 09/99                            1
INTERNET DRAFT                  THEMA                       March 1999


1.  Introduction

   The Mobile IP protocol [Perkins96] and its extensions define the
   notions of Home Agent (HA) and Foreign Agent (FA) and assume that
   the FA is deployed with link-layer connectivity to some visited
   network and the HA is deployed with link-layer connectivity to some
   home network.  For various reasons, carriers who actually deploy
   such agents may wish to separate the agent's functionality from the
   link-layer presence on the proper network.  This may allow the agent
   functionality to be shared over a wider area, which could lower the
   cost of deployment.  Service providers may also have administrative
   or other reasons for centralizing mobile agent functionality.

   For example, market forces may drive a carrier to buy equipment that
   terminates the link-layer from one vendor and hardware that
   implements FA functionality from another.  Alternatively, a carrier
   may wish to deploy an FA near its controlling authentication,
   authorization, and accounting (AAA) server for security reasons,
   which could place it far from the actual links on which mobile nodes
   will connect.  Also, by creating networks of surrogate agents in a
   foreign network, a carrier can form a hierarchy that lessens the
   frequency of Mobile IP registrations.  By confining local mobility
   events to the local carrier network, handoff can often be completed
   without waiting for a round-trip through the Internet and the
   associated cryptographic AAA processing.  Also, the computational
   burden on FAs and HAs will be reduced.  This is possible using THEMA
   because after a local handoff, tunnels can often be established back
   to a common ancestor in the hierarchy of surrogate agents or to the
   original FA, obviating the need for Mobile IP re-registration.

   A home network may also desire to position an HA several network
   hops away from a MNs home link.  This may be so that the HA can be
   co-located with AAA functionality just behind a firewall.  The
   actual presence on the home link can be supported by a surrogate
   home agent that complies exactly with basic Mobile IP [Perkins96]
   and need not interact with a AAA server.  This option might be
   attractive to a private network operator with an installed base of
   basic Mobile IP home agents who, with the addition of a special home
   agent at the firewall, wishes to provide service to users roaming
   outside the firewall.  This draft describes such a scenario and
   shows how an HA can interact with a surrogate agent to provide
   transparent access to the home link.

   To accomplish separation of the link-layer termination point from
   mobility agent functionality, this draft draws on ideas from the
   Tunnel Establishment Protocol [Calhoun98a].  It allows the link-
   layer termination point to play the role of a surrogate agent, which
   tunnels packets to the real mobility agent and de-tunnels packets
   that arrive from the mobility agent.  To the agent software at the
   mobility agent itself, the tunnel endpoint should appear to be a
   link-layer address to which packets can be sent or from which
   packets may be received.  The creation of the tunnel is completely

McCann et al.               Expires 09/99                            2
INTERNET DRAFT                  THEMA                       March 1999


   transparent to mobile nodes (MNs), which means it can be deployed
   without changing the Mobile IP client software to be aware of the
   hierarchies, as is the case in other proposals [Calhoun98b].  Also,
   we support the use of private, potentially overlapping addresses
   with an FA-located care-of address, which is not a capability of
   [Valko98].

   THEMA can be the basis for the design of an access network between
   MNs and FAs.  When deployed in this manner, THEMA tunnels are
   established immediately after the MNs link-layer connection is
   brought up, and before any Mobile IP registration or agent
   solicitation messages are sent.  They provide the MN and FA with the
   illusion of direct, link-layer connectivity, although this
   connectivity is actually via one or more GRE tunnels that each
   potentially span several network routing hops.  Because the tunnels
   are established using only information available at link
   establishment time, there is no interaction between THEMA
   establishment and the subsequent Mobile IP registration messages.
   After THEMA tunnels are established, the MN and FA may engage in
   Mobile IP registration as normal.  Solicitations, Registrations, and
   Replies are carried through the GRE tunnel in the same way as any
   other IP packets between the MN and FA.

   While THEMA tunnels do preserve link-layer information, they carry
   only network-layer packets, not link-layer frames.  THEMA assumes
   that the link-layer will be terminated as early as possible in a
   carrier network, in order to support the tight integration needed to
   support quality of service guarantees over potentially complex
   wireless media types.  THEMA provides a degree of separation between
   the mobility agent functionality and the specific link-layer
   technology used and allows packets in tunnels to be reordered by
   intervening routers.  THEMA is therefore a more natural choice for
   standardization compared to proposals that tunnel link-layer frames
   [Valencia98].

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in RFC 2119
   [Bradner97].


1.1  Terminology

   Mobile Node (MN)
      As in Mobile IP [Perkins96].

   Correspondent Node (CN)
      As in Mobile IP [Perkins96].

   Home Agent (HA)
      As in Mobile IP [Perkins96].


McCann et al.               Expires 09/99                            3
INTERNET DRAFT                  THEMA                       March 1999


   Foreign Agent (FA)
      As in Mobile IP [Perkins96].

   Surrogate Agent (SA)
      A mobility agent that is neither a home nor a foreign agent.  In
      this draft, SAs will be placed between the MNs link-layer
      termination point and the FA, and between the HA and the home
      link.

   Authentication, Authorization, and Accounting (AAA) Server
      A server implementing a protocol such as DIAMETER [Calhoun98c]
      which can authenticate users and serve as a repository for
      accounting information.


2.  Architectural Assumptions

   We assume that the MN has a link-layer connection to some entity in
   the carrier network.  Also, this entity is one or more network hops
   away from a node that implements foreign agent functionality.  This
   scenario is depicted in Figure 1.

           MN  --- Link-Layer  --- Intermediate --- Foreign
                   Termination       Hop (SA)        Agent
                      (SA)

          Figure 1.  The MNs link-layer is terminated at a point
          distant from the FA.

   The nodes marked SA will play the role of Surrogate Agents, a term
   borrowed from [Calhoun98a] which is usually applied to nodes between
   the FA and HA but here is applied to nodes between the MN and FA and
   between the HA and home link.  We assume that a MN connects to the
   first hop SA through means specific to the given link-layer
   technology used.  In a cellular environment, for instance, this
   would mean connecting via a base-station to some Inter-Working
   Function; in a wireless LAN environment, it might mean simply
   wandering into the coverage area of some wireless LAN device.

   Similarly, the home agent may be located one or more network hops
   away from the home link, as depicted in Figure 2.

                   Home  --- Intermediate --- Home Link
                   Agent       Hop (SA)         (SA)

               Figure 2.  The MNs home link is distant from the
               HA functionality.

   We assume that the SAs in Figure 1 belong to the same administrative
   domain as the FA, and that the SAs in Figure 2 belong to the same
   administrative domain as the HA.  As we will see below, this
   simplifies the registration process because there may be pre-

McCann et al.               Expires 09/99                            4
INTERNET DRAFT                  THEMA                       March 1999


   arranged security associations between these entities.  Also,
   authentication of the registration messages outlined in this draft
   may not be necessary at all because the tunnel establishment happens
   between entities in a mutual trust relationship.  These assumptions
   allow us to place the burden of authentication of Mobile IP
   registration messages originating from the MN on the actual FA and
   HA.  These mobility agents can offload this task to AAA servers
   which are suitably connected via a roaming consortium, but the SAs
   will not necessarily require any such AAA service and do not need
   any authenticated access identifiers from the MN.


3.  Summary of Operation

   The goal of THEMA is to provide transparent link-layer connectivity
   between a MN and FA and between the HA and home link.  THEMA is
   based on Mobile IP [Perkins96] with some of the extensions from TEP
   [Clahoun98a].

   When a MN arrives in a visited network, that network transparently
   establishes a tunnel from the MNs attachment point back to an FA.
   The first-hop SA where the link-layer is terminated begins the
   process by setting up a tunnel to its neighbor SA or directly to the
   FA, passing along any link-layer identification information.  This
   creates a chain of tunnels, each of which carries a Tunnel
   Identifier that can be used to distinguish traffic from a given MN.

   The use of THEMA on the home network is triggered by receipt of a
   successful Mobile IP Registration Request at the HA sitting at the
   boundary of the home network.  It establishes a tunnel back to the
   home link, which may be separated by several network hops.  The SA
   sitting on the home link then forwards packets from the home network
   back to the HA and receives packets from the HA which it
   decapsulates and delivers.  This gives the HA a virtual presence on
   the home link.

   We will describe each leg of operation separately, beginning with
   the MN - FA connection and finishing with the HA - home link.


3.1  MN - FA

   In what follows, we will use the term "upstream" to refer to nodes
   closer to the FA and the term "downstream" to refer to nodes closer
   to the MN.

   First, assume the MN opens a link-layer connection to the first hop
   SA in Figure 1.  If the link is connection oriented, the SA will
   have an immediate indication that the MN is present.  Otherwise, the
   SA may need to use lower layer indications or simply wait for the
   first message from the MN, such as a Mobile IP Agent Solicitation.
   The SA should now have available some kind of link-layer address,

McCann et al.               Expires 09/99                            5
INTERNET DRAFT                  THEMA                       March 1999


   such as the IMSI of a mobile phone or the hardware address of an
   Ethernet adapter. The SA then establishes a tunnel to another SA
   (the Intermediate Hop in Figure 1) or to the FA itself by sending a
   Registration Request.  The choice of intermediate node or FA may be
   static or dynamic.  This is essentially a routing problem, where the
   SA must find the next hop on a path to some FA which is "good"
   according to some metric which may involve hop count, frequency of
   registration messages, and load balancing considerations.  The exact
   mechanism for discovering or maintaining routes is outside the scope
   of this draft.  If the FA function were available at the link-layer
   termination point, a simpler solution would be to use a regionalized
   registration approach [Calhoun98b].

   Registration Request messages are sent over UDP to port 434, and
   formatted as in basic Mobile IP.  When sent from an SA to an FA or
   intermediate SA, the 'S' bit MAY be set, indicating simultaneous
   registrations; the 'G' bit MUST be set, indicating GRE
   encapsulation; all other flag bits MUST be set to '0'.  The Home
   Address field SHOULD be set to zero (0.0.0.0).  This field is not
   needed by THEMA and should be ignored by the receiver.  The Home
   Agent field MUST be set to the recipient's IP address, and the Care-
   of Address field MUST be set to the sender's IP address.  In a Link-
   Layer Address extension to the Registration Request, the SA SHOULD
   identify the link-layer address information it has for the MN.
   Also, the SA MUST use the Tunnel Identifier extension, setting the
   first 16 bits to a locally unique value.  The Lifetime field SHOULD
   be set to an appropriate number of seconds.

   Upon reception of a Registration Request, the receiving SA or FA
   determines if this is a new tunnel or a refresh of an old tunnel.  A
   refresh of an old tunnel can be detected by looking for an existing
   tunnel with the same downstream SA address, the same 16 most
   significant bits in the Tunnel Identifier field, and the same Link-
   Layer Address extension in the Registration Request.  If this is a
   new tunnel, the SA or FA MUST complete the Tunnel Identifier
   extension with a locally unique 16 bit number, and create a new
   tunnel endpoint.  Otherwise, the SA or FA MUST continue to use the
   same Tunnel Identifier and tunnel endpoint.  In either case the SA
   or FA notes the requested Lifetime, sets an expiration timer for the
   tunnel, and immediately sends a Registration Response to the SA that
   sent the Registration Request.  Success or failure of the
   registration can be indicated as in Mobile IP [Perkins96].  The
   Reply MUST have its Home Agent field set to the sender's address and
   SHOULD have the Home Address field set to zero (0.0.0.0).  Again,
   the Home Address field is not needed by THEMA and should be ignored.

   If this is a new tunnel, an Intermediate Hop SA then immediately
   sends a Registration Request to the next upstream SA or FA,
   containing an appropriate Lifetime.  Otherwise, the Intermediate Hop
   SHOULD merely refresh the upstream tunnel as needed while downstream
   tunnels are active.  Tunnels are refreshed by sending a new
   Registration Request with an appropriate Lifetime field.  By

McCann et al.               Expires 09/99                            6
INTERNET DRAFT                  THEMA                       March 1999


   adjusting the Lifetime fields used by each layer of a hierarchy, a
   carrier can adjust the frequency of re-registration.  In general
   nodes closer to the FA should use longer Lifetimes, as these tunnels
   are expected to be more stable.

   An SA will then have established one link in a chain of concatenated
   tunnels, and begins to serve as a forwarding point for traffic.
   Packets originating from the MN are encapsulated by the first SA in
   a GRE tunnel to the next hop agent using the Tunnel Identifier that
   was negotiated.  If the next hop is also an SA, it maps the incoming
   Tunnel Identifier to an outgoing Tunnel Identifier and agent IP
   address, and re-encapsulates the packet in a GRE header containing
   the new tunnel identifier.  Finally, if the next hop is an FA, it
   decapsulates the packet and processes it exactly as if it had been
   received on a local link.

   If the 'S' bit was set in the Registration Request, a given agent
   may have more than one downstream tunnel opened for a given link-
   layer address at a time.  Any packets that arrive on either
   downstream tunnel should be forwarded to the same upstream tunnel,
   and packets that arrive on the corresponding upstream tunnel should
   be "forked" and a duplicate packet sent to each downstream tunnel.

   If the first hop SA has an indication that the link-layer connection
   to the MN has been disconnected, and after waiting a sufficient
   amount of time for the MN to reconnect, the upstream tunnel SHOULD
   be torn down by sending a new Registration Request with a Lifetime
   of 0.  As with all Registration Requests, the SA retransmits the
   request as necessary, waiting for a Registration Reply acknowledging
   the tunnel tear-down.  Lack of a reply after several retransmissions
   may indicate that the upstream node has crashed in which case the
   tunnel MAY be torn down and an error MUST be logged.

   If all downstream tunnels corresponding to a given link-layer
   address are torn down by the downstream SAs, this indicates that the
   MN has disconnected.  The first hop SA MAY also use idle timers to
   detect that a MN has disconnected, which may be the only mechanism
   available if the MN is using a connectionless medium.  In either
   case the upstream tunnel SHOULD be torn down as specified above.

   If a downstream tunnel's lifetime expires without the receipt of any
   new Registration Requests, it may indicate that the downstream node
   has crashed.  In this case the downstream tunnel MAY be torn down
   without notification of the downstream node and an error MUST be
   logged.  If this is the last downstream tunnel corresponding to a
   given link-layer address, the corresponding upstream tunnel MUST
   then be torn down as specified above.

   The first hop SA should monitor the Lifetime of the tunnel.  When it
   is about to expire, but the SA has an indication that the MN is
   still connected, it MUST initiate a tunnel refresh operation by


McCann et al.               Expires 09/99                            7
INTERNET DRAFT                  THEMA                       March 1999


   sending a new Registration Request upstream with an appropriate
   Lifetime.

   Disconnection of a link-layer tunnel at the FA MUST NOT trigger
   expiration of the corresponding Mobile IP binding.  Expiration of
   this binding should occur as specified in RFC 2002 [Perkins96].  The
   MN may simply have left the coverage area momentarily and may
   reappear soon, perhaps at a different SA.  The FA should be able to
   recognize the link-layer address as matching the existing binding
   and should begin forwarding datagrams along the new tunnel.

   Depending on the medium type connecting the MN to the first hop SA,
   link-layer specific procedures may be necessary to complete the
   illusion of direct connectivity to the FA.  For example, an Ethernet
   deployment would require the SA to implement Proxy ARP on behalf of
   the FA.


3.2  HA - Home Link

   In addition to separating the FA from the visited link, there may
   also be reasons to separate the HA from the home link.  For
   instance, the HA may sit just behind a firewall, while the home link
   is distant by several IP routing hops.  However, putting intervening
   tunnel endpoints between the HA and the home link, analogous to the
   Intermediate Hops in the foreign network case, is not likely to be
   useful, because the HA is not likely to change over the course of
   the data session.  Therefore, we consider only the case of direct
   interaction between the HA and the SA, the latter of which is
   assumed to be directly connected to the MN's home link.

   First, assume that the MN sends a Mobile IP Registration Request to
   the HA.  Assuming that the registration is otherwise successful, the
   HA must arrange to intercept packets destined to the MN home
   address. Normally this is impossible if the HA is not co-located on
   the MNs home link.  However, this can be accomplished with the use
   of an SA on the home link.  The HA sends a Registration Request to
   the SA.  The 'S' bit must be set, and the 'B' bit must be set if and
   only if the corresponding bit was set in the original Mobile IP
   Registration Request from the MN.  The other flag bits may or may
   not be set depending on the scenario in which the HA and SA are
   deployed.  The Home Address may be zero if the address is to be
   allocated by the home-link SA, but must be the home address of the
   MN otherwise.  The Home Agent field must be set to the address of
   the SA. The Care-of address must be set to the internal address of
   the HA.  Upon receipt of the request, the SA allocates an address,
   if necessary, sends a Registration Response, and begins to intercept
   packets destined for that address and forward them to the HA.  The
   Response must have a Home Agent address set to the SA's address, and
   the Home Address field must be set to the address of the MN.



McCann et al.               Expires 09/99                            8
INTERNET DRAFT                  THEMA                       March 1999


   De-registrations, retransmissions, and time-outs should be handled
   as in Mobile IP [Perkins96].


4.  Link-Layer Address Extension

   This draft defines a new extension for use in THEMA Registration
   Request messages.  This extension is not intended for use in
   Registration Requests that originate from MNs; it should appear only
   in the surrogate registrations sent from SAs.  Within this
   extension, we define two possible link-layer address formats.
   Additional message types may be defined in the future for other
   link-layer technologies.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |          Link Type            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Address Information...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Type

            TBD - Link-Layer Address

         Length

            Indicates the total length (in octets) of the Link Type and
            Address Information fields.

         Link Type

            Indicates the type of address contained in the Address
            Information field.  Allowed values are:

               TBD - Ethernet address
               TBD - International Mobile Station Identifier (IMSI)

         Address Information

            A variable length sequence of octets representing the
            link-layer address of the MN on behalf of whom this tunnel
            is being requested.

   Below we define formats for several specific instances of link-layer
   technologies, but it is not necessary for the FAs or SAs (except for
   the first hop SA that actually terminates the link-layer) to
   understand the semantics of a given link-layer or the encapsulation
   formats of that link-layer.  The agent can simply use the tuple
   (Link Type, Address Information) as an opaque identifier that
   uniquely identifies a MN interface.

McCann et al.               Expires 09/99                            9
INTERNET DRAFT                  THEMA                       March 1999




4.1  Ethernet Address Extension

   Ethernet hardware addresses are 48-bit numbers uniquely identifying
   an Ethernet adapter.  This extension applies to both wired and
   wireless Ethernet.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |          Link Type            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Ethernet Address                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Ethernet Address (con't)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Type

            TBD - Link-Layer Address

         Length

            8 (0x08)

         Link Type

            TBD - Ethernet address

         Address Information

            The six octet Ethernet address being used by the MNs
            Ethernet adapter.


4.2  International Mobile Station Identifier (IMSI) Extension

   Mobile cellular telephones and data-only devices designed to connect
   to the global cellular infrastructure are expected to be uniquely
   identified by their IMSI.  This identifier may be either 40, 50, or
   56 bits in length, depending on whether the underlying technology is
   CDMA, TDMA, or GSM.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |          Link Type            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             IMSI                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           IMSI (cont)                         |

McCann et al.               Expires 09/99                           10
INTERNET DRAFT                  THEMA                       March 1999


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Session ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Type

            TBD - Link-Layer Address

         Length

            12 (0x0c)

         Link Type

            TBD - International Mobile Station Identifier (IMSI)

         Address Information

           This is the 40, 50, or 56 bit number which identifies a
           cellular telephony device.  The IMSI field is padded with
           leading zeros, so the LSB of the IMSI is always the 64th
           bit.

         Session ID

            Because many cellular technologies can accommodate multiple
            open sessions simultaneously, this extra two bytes of
            information is included to distinguish them.  When a MN
            moves to a new SA, each virtual link-layer interface on the
            MN should retain the same session ID.  This ID may be
            inferred from technology-dependent procedures when the MN
            connects to the new SA or it may be supplied explicitly by
            the MN, such as during link-layer negotiation.  The exact
            means is outside the scope of this draft.


5.  Security

   Mechanisms for ensuring that a given MN actually does possess a
   given link-layer address are particular to each technology and are
   outside the scope of this document.  THEMA provides only the amount
   of security given by the underlying link-layer, and it is up to the
   FA to carry out network-layer authentication.  If a given technology
   permits either "snooping" or "spoofing" of link-layer addresses,
   then higher security may be obtained by network-layer encryption
   between the MN and FA.

   Throughout this document, we assume that the FA and HA will be
   connected to AAA servers, which will process NAI Extensions as
   outlined in [Calhoun98d], but that this will not be necessary for
   the SAs.  They may be configured with static security associations


McCann et al.               Expires 09/99                           11
INTERNET DRAFT                  THEMA                       March 1999


   or no security at all, provided they are in a protected part of a
   private network.


6.  Discussion

   The proposal outlined here preserves the link-layer address
   information through several hops all the way back to the FA. These
   addresses do not actually appear in tunneled packets; the Tunnel
   Identifier key acts as a replacement.  Essentially, the MN is given
   a link-layer connection to the FA that is independent of any
   particular link-layer technology.  This has advantages over other
   layer-2 tunneling schemes, such as L2TP [Valencia98], that are tied
   to PPP.  Also, because the tunneled datagrams are IP packets, not
   layer-2 frames, we don't need to include sequence numbers.  Packets
   can be re-ordered to support Quality of Service requirements.

   No new extensions were necessary for the successful separation of
   the HA from the SA on the home link.  This case is very similar to
   the base Mobile IP protocol and in fact the home link SA can comply
   completely with the requirements for a home agent laid out in basic
   Mobile IP [Perkins96].


7.  References

   [Calhoun98a] Calhoun, Montenegro, Perkins, "Tunnel Establishment
   Protocol", draft-ietf-mobileip-calhoun-tep-01.txt, March 1998.
   Work In Progress.

   [Calhoun98b] Calhoun, Montenegro, Perkins, "Mobile IP Regionalized
   Tunnel Management", draft-ietf-mobileip-reg-tunnel-00.txt,
   November 1998.  Work In Progress.

   [Calhoun98c] Calhoun, Rubens, "DIAMETER Base Protocol",
   draft-calhoun-diameter-04.txt, July 1998.  Work In Progress.

   [Calhoun98d] Calhoun, Perkins, "DIAMETER Mobile IP Extensions",
   draft-calhoun-diameter-mobileip-01.txt, November 1998.
   Work In Progress.

   [Perkins96] C. Perkins, Editor, "IP Mobility Support", RFC 2002,
   October 1996.

   [Valencia98] Valencia, Hamzeh, Rubens, Kilar, Littlewood, Townsley,
   Taarud, Pall, Palter, Verthein, "Layer Two Tunneling Protocol
   (L2TP)", draft-ietf-pppext-l2tp-12.txt, October 1998.  Work In
   Progress.

   [Valko98] Valko, Campbell, Gomez, "Cellular IP", draft-valko-
   cellularip-00.txt, November 1998.  Work In Progress.


McCann et al.               Expires 09/99                           12
INTERNET DRAFT                  THEMA                       March 1999



8.  Author's Addresses

   Questions about this memo can be directed to:

         Peter J. McCann
         Lucent Technologies
         Rm 2Z-305
         263 Shuman Blvd
         Naperville, IL  60566
         USA
         email: mccap@lucent.com
         phone: +1 630 713 9359
         fax:   +1 630 713 4982

         Tom Hiller
         Lucent Technologies
         Rm 2F-218
         263 Shuman Blvd
         Naperville, IL  60566
         USA
         email: tomhiller@lucent.com
         phone: +1 630 979 7673
         fax:   +1 630 713 3663

         Jin Wang
         Lucent Technologies
         Rm 1Q-305
         1000 E Warrenville Rd
         Naperville, IL  60566
         USA
         email: jinwang@lucent.com
         phone: +1 630 713 5292
         fax:   +1 630 979 3983

         Alessio Casati
         Lucent Technologies
         Sigma Building
         Windmill Hill Business Park
         Wiltshire, SN5 6P
         United Kingdom
         email: acasati@lucent.com
         phone: +44 179388 3861

         Charles E. Perkins
         Sun Laboratories, Network and Security Research Center
         Sun Microsystems, Inc.
         15 Network Circle
         Menlo Park, CA  94025
         USA
         email: charles.perkins@eng.sun.com
         phone: +1 650 786 6464

McCann et al.               Expires 09/99                           13
INTERNET DRAFT                  THEMA                       March 1999


         fax:   +1 650 786 6445

         Pat R. Calhoun
         Sun Laboratories, Network and Security Research Center
         Sun Microsystems, Inc.
         15 Network Circle
         Menlo Park, CA  94025
         USA
         email: pcalhoun@eng.sun.com
         phone: +1 650 786 7733
         fax:   +1 650 786 6445










































McCann et al.               Expires 09/99                           14