[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Personal                                                M. Scott Corson
                                                   Flarion Technologies
Internet Draft
Title: draft-corson-triggered-00.txt
Category: Informational                                        May 2002
Expires : November 2002


                         A Triggered Interface
                    <draft-corson-triggered-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 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.

Abstract

   Layer 2 interfaces fundamentally operate as either broadcast or
   point-to-point.  From these primitives, additional layer 3 interface
   constructs such as non-broadcast multiple access and point-to-
   multipoint are created as necessary.  This approach has served the
   wired Internet well.  However this memo argues that a third type of
   layer 2 interface is necessary to seamlessly extend IP over dynamic
   networks, principally wireless.  This interface, here termed a
   "triggered" interface, combines traditional broadcast interface
   addressing semantics (i.e. support for unicast, multicast and
   broadcast link layer addresses) with layer 2 trigger support for the
   dynamic creation of peer-to-peer interface associations within an
   otherwise broadcast interface.  Its intended domain of applicability
   covers cellular, WLAN, MANET, etc; in short all currently envisioned
   forms of dynamic wireless networking.


Corson                                                               1
Internet Draft          A Triggered Interface                May 2002


1. Introduction

   IP networking has long been used in wireless communications
   beginning with early work on packet radio networks.  Nowadays it is
   common to send IP data over a variety of wireless technologies, both
   fixed and mobile.  Traditionally this has consisted of "best effort"
   data communications, with the accompanying assumptions on packet
   loss and latency.  While voice and other forms of low-latency IP
   data are also sometimes transported over wireless to end hosts,
   these services are not yet widely available on a commercial basis.

   Increasingly there is commercial interest in transporting all forms
   of data over IP over wireless, especially voice.  The use of
   wireless technologies is desirable due to the ubiquity of access
   they enable as well as their ability to support mobility.  Meeting
   the stringent requirements on packet loss and delivery latency for
   voice traffic (and other forms of low latency data) places many
   requirements on a wireless network; one of which is the ability to
   quickly and efficiently determine the existence (or non-existence)
   of a link, as this is central to determining IP reachability.

   This capability is needed most commonly as a consequence of
   movement-induced changes in network topology.  Mobile handoff,
   whether in cellular or WLAN contexts, generally requires that the
   entire process complete within 10's of milliseconds is seamless
   voice service is to be maintained.  This requires very fast
   detection of changes in link status.  Oftentimes the change in the
   status of a link (its UP or DOWN status) is associated with movement
   or variation in physical channel conditions, but this need not be
   the case.  Other factors such as authentication and quality of
   service considerations may impact the status of a link.

   Two general approaches are available to detect changes in link
   status at the IP layer: the direct use of layer 3 (L3 or IP layer)
   mechanisms and the use of layer 2 (L2 or link layer) triggers to
   inform IP.  Each approach has advantages and disadvantages.


1.1. L3 Link Detection

   The usage of L3 mechanisms is advantageous in that they are generic
   and work across all link layers.  Their usage is also practically
   expedient in that their standardization is only required in one
   standards body, the IETF, as opposed to across both the IETF and
   other link layer standards bodies such as the IEEE.  Consequently
   their usage is generally preferred when practical.

   Unfortunately in many instances a pure L3 approach may not work well
   enough and thus, perversely, may not be generally applicable.  Link
   layers vary greatly in both form and function.  Some are connection-
   oriented (e.g. Bluetooth) while others are not (e.g. 802.11).  Some
   are bandwidth-constrained (e.g. cellular) while others are less so
   (e.g. WLAN).  Some are continuously beaconing (e.g. HIPERLAN1) while

Corson                                                               2
Internet Draft          A Triggered Interface                May 2002


   others may not (e.g. energy-constrained sensor networks).  In order
   to quickly detect a link status change (in the low 10's of
   milliseconds), frequent, periodic L3 messaging is required on the
   order of 100-200 messages per second in each direction.  This may
   not be practical for many bandwidth or energy-constrained wireless
   technologies.  Such an algorithm may also need heuristic tuning for
   each link layer given each technology's unique characteristics,
   which then breaks the notion that the IP layer should be generic and
   L2-agnostic.

1.2 L2 Link Detection

   An alternative to this is the use of L2 triggers.  A link layer best
   knows its current link status.  It is a peer-to-peer relationship
   between a pair of interfaces at the link layer.  The principle of
   separation of concerns suggests that IP allow the link layer to
   ascertain its own status (in many cases it will do this anyway) and
   report this to IP.  It is true that not all link layers dynamically
   ascertain link status between pairs of adjacent interfaces.  These
   link layers are therefore best viewed as either traditional point-
   to-point or broadcast, and over these L2's IP should be configured
   to detect link status via its own mechanisms as is commonly done.

   However, for those link layers that do ascertain link status (the
   majority), use of L2 trigger information is usually the only
   feasible manner to quickly determine link status and, hence, IP
   connectivity.  By necessity a pure L3 detection approach provides a
   *lagging* indicator.  For IP messages to flow (or to stop flowing),
   the link itself will *already* be UP (or DOWN), and the link layer
   establishment processing has already added delay of its own.
   Consequently IP can only begin to determine what has happened
   *after* it has happened at the link layer.  In virtually all cases
   this will be too late to support seamless voice and low latency data
   service.  In cases where the link layer ascertains its own status,
   the use of L2 triggers can inform the IP layer without ambiguity or
   delay in the event of a link status change.

   The observation that L2 trigger support is necessary for a variety
   of link layers begs the question as to how this support should be
   realized.

1.3. Incorporating L2 Triggers into IP

   Up to now, support for mobility within the Internet has been an
   afterthought.  Standardized support for intra-domain, mobile,
   prefix/host-based native routing does not exist.  The only present
   standard alternative is to use tunneling with Mobile IP.

   Mobile IP would perhaps have been better named "Portable IP", as its
   original design was intended to support remote access-based
   operation in support of inbound IP reachability for "road warriors"
   equipped with portable devices connecting while *away* from their
   home subnet.  Insufficient consideration was given to supporting

Corson                                                               3
Internet Draft          A Triggered Interface                May 2002


   true mobility, resulting in the recent flurry of activity in the MIP
   and other WGs to address these shortcomings.  These solutions cannot
   function effectively for many link layers without the additional
   support of L2 triggers.

   Mobile Ad hoc Networking represents a dynamic form of IP networking
   where the entire network infrastructure may potentially be mobile.
   Many link layers exist from which MANETs may be formed.  Many of
   these link layers dynamically detect the presence/absence of
   neighbors within those link layers.  It is not only desirable to
   make use of this information when known, it is typically required
   for these link layers if seamless internetworking of voice and other
   demanding applications is to be achieved.

   Recognition of the limitations of the existing L2-oblivious IP
   approach is essential before first class support for mobility can be
   incorporated within IP's purview.  Currently IP does not give
   mobility appropriate treatment and its performance over mobile
   networks suffers without non-standard modifications.  In order a
   fully integrate mobility support within IP, reconsideration is
   required of the proper relationship between IP and the vast array of
   dynamic link layer technologies that now exist and will exist going
   forward.  Dynamic interfaces (principally wireless) require a modest
   level of recognition from the IP stack for efficient internetworking
   to occur.  Modification of IP kernels to support the minimal
   functionality described here would fundamentally enhance the
   Internet's capability going forward.

   There are several ways one might consider adding support for L2
   triggers into IP.  This memo now argues that definition of a new
   "triggered" L2 interface type is the most appropriate architectural
   solution.  This memo describes how this simple interface abstraction
   can handle the case of network-level mobility within a fixed
   infrastructure (e.g. Mobile IP-based connectivity) and mobility of
   an infrastructure itself (e.g. MANET-based connectivity).


2. 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
   [RFC2119].


3. A Triggered Interface

   Layer 2 interfaces fundamentally operate as either "broadcast" or
   "point-to-point".  This holds true even for recent work on
   unidirectional satellite links [RFC3077] wherein a broadcast link is
   emulated through the use of link layer tunneling. From these two
   primitives, additional layer 3 interface constructs such as non-

Corson                                                               4
Internet Draft          A Triggered Interface                May 2002


   broadcast multiple access (NBMA) and point-to-multipoint are created
   as necessary.  This approach has served the existing Internet well.

   However, to support many existing and emerging link layer
   technologies, this memo argues that a third type of layer 2
   interface is necessary to seamlessly extend IP over dynamic
   networks.  This interface, here termed a "triggered" interface,
   combines traditional broadcast interface addressing semantics with
   layer 2 trigger support for the dynamic creation of peer-to-peer,
   link layer interface associations within an otherwise broadcast
   interface.

   A triggered interface type would retain the addressing and
   transmission behavior of a broadcast interface (i.e. support for
   unicast, multicast and broadcast MAC addresses).  Thus behavior akin
   if not equivalent to ARP/RARP would be required for resolving
   unicast MAC addresses.  Also, a mapping of IP multicast to link
   layer multicast addressing is required, as is support for MAC
   broadcast.

   A triggered interface would also support a dynamic set of link layer
   associations.  An "association" or "link" is defined as a peer-to-
   peer relationship between two link layer interfaces that can
   *directly* and *bi-directionally* communicate with each other.  The
   status (i.e. the existence or non-existence) of these associations
   (or links) would be determined by the link layer, and signaled by
   the link layer thru the triggered interface to the IP stack using L2
   triggers.

   In a fixed infrastructure, from an IP Base Station's (BS)
   perspective, the interface would generally have multiple Mobile
   Node's (MN) associated with it at the link layer (1-to-N), while
   from the MN's perspective it would oftentimes have only one link to
   the BS (1-to-1) as shown in the following figure.


                            BS                1-to-N (one BS to N MNs)
                           / | \
                          /  |  \
                        MN  MN  MN            1-to-1 (one MN to one BS)

        Figure 1: Typical Cellular/WLAN View (Base Stations and Mobile
   Nodes)


   In the future cellular/WLAN link layers will also likely exist that
   permit a MN to simultaneously connect to multiple BSs as shown in
   Figure 2, so this possibility should be considered as well.






Corson                                                               5
Internet Draft          A Triggered Interface                May 2002




                    BS      BS                1-to-N (one BS to N MNs)
                   /  \    / | \
                  /    \  /  |  \
                 MN     MN  MN  MN            1-to-N (one MN to N BSs)

        Figure 2: Future Cellular/WLAN View (Base Stations and Mobile
   Nodes)


   In an ad hoc network, Mobile Routers (MR) will generally have
   multiple neighboring mobile routers, so the 1-to-N relation would
   hold as well.



                        MR    MR
                          \  /   \
                   MR------MR-----MR          1-to-N (one MR to N MRs)
                          /      /  \
                        MR     MR    MR

                 Figure 3: Ad hoc Network View (Mobile Routers)


   So going forward the general case in both cellular, WLAN and MANET
   contexts is 1-to-N, with 1-to-1 being a special case.

   The exact composition of an L2 trigger is also not specified here.
   An L2 trigger MUST contain the MAC address of the adjacent neighbor
   interface. Its reception at the IP stack would signal that a bi-
   directional link layer communication capability exists (a link has
   come UP) or ceases to exist (a link has gone DOWN) between two
   adjacent interfaces.  The MAC address presented to IP MUST remain
   constant while the link is UP.

   The behavior of an IP stack to the reception of these triggers is
   not specified here.  Whether any mandatory behaviors are required is
   an open issue.  The potential exists for an IP stack to immediately
   issue a Reverse ARP (RARP) request for the adjacent interface.

   Additional IP stack behavior modification on top of the support for
   L2 triggers may also be required.  The proper treatment of broadcast
   and multicast traffic on this interface type should to be
   reconsidered as well.  The traditional treatment of IP multicast
   over broadcast interfaces is not appropriate for MANETs or future
   cellular and WLAN contexts.  IP multicast traffic is typically not
   rebroadcast out the broadcast interface over which it was received,
   however this would often be required for triggered interfaces.




Corson                                                               6
Internet Draft          A Triggered Interface                May 2002


   The triggered interface type would be useful for both IPv4 and IPv6.
   However the commercial will to undertake the necessary IP stack
   modifications may only be present for IPv6.

   The intended usage of this interface type is straightforward.  It
   appears that this simple interface abstraction can support many
   existing and envisioned link layers.  It maps well onto cellular,
   WLAN, PAN and MANET interfaces as we now illustrate with simple
   examples.


3.1. Cellular

   Cellular communications occur between BSs and MNs.  Note that I am
   now describing IP-based networks, where both base stations and
   mobiles are IP elements.

   Circuit-oriented air interfaces establish point-to-point links at
   the physical layer, and typically run PPP or equivalent to establish
   IP connectivity.  This approach is sensible for the delivery of
   unicast data, but is very inefficient for the delivery of broadcast
   and multicast traffic given that the base station's transmissions
   are inherently broadcast at the physical layer.  To deliver these
   forms of traffic, ATM-like NBMA or point-to-multipoint interfaces
   are required at an IP base station (assuming IP is brought directly
   to the base station, now also a router), and the triggered interface
   discussion does not apply.

   To deliver bandwidth-efficient services as well as high levels of
   statistical multiplexing over the air, emerging packet-oriented
   cellular technologies offer support for broadcast and multicast
   addressing at the link layer in addition to unicast communications.
   Consequently a broadcast-oriented interface is used.

   In both cases (circuit or packet-orientation), cellular link layers
   typically have the property that the establishment or loss of a link
   is immediately known at both ends, and can be signaled to the IP
   stacks on the MN and BS.  This is a typically consequence of their
   physical and MAC layer designs as well as the general need to
   perform link layer authentication.

   The triggered interface is sufficiently generic to handle all
   cellular air interfaces in terms of addressing and L2 trigger
   support.


3.2. 802.11 (Infrastructure mode) and HIPERLAN2

   Both HIPERLAN2 and 802.11 in Infrastructure mode operate in a
   fashion synonymous to emerging packet-based cellular technologies,
   and would benefit from the use of triggered interfaces in hosts as
   well as BS (integrated IP Access Router/Access Point) boxes.


Corson                                                               7
Internet Draft          A Triggered Interface                May 2002


   802.11 interfaces are currently defined as broadcast interfaces.
   Re-classification as triggered interfaces in end hosts would not
   change addressing practice, but would enable cleaner support for L2
   triggers by enabling existing link layer "association/de-
   association" signals to be passed up to the end host IP stack in a
   generic fashion as standard L2 triggers.  These signals are
   generated automatically at the BS and MN ends of a link when a BS is
   operating in infrastructure mode.


3.3. HIPERLAN1

   HIPERLAN1 was originally developed as a 20Mbps multi-hop, ad hoc
   networking technology employing broadcast transmissions with omni-
   directional antennas.  The MAC protocol was designed explicitly to
   support neighbor detection and utilizes beaconing at the MAC layer.
   Hence HIPERLAN1 (and any future similar MAC layers) would map well
   into a triggered interface type.


3.4. Bluetooth

   The Bluetooth MAC is connection-oriented and TDMA-based.  Its
   interfaces automatically detect each other and form peer-to-peer
   associations at the MAC layer in addition to using broadcast and
   unicast addressing while communicating.  Thus a triggered interface
   classification suits Bluetooth quite well and L2 triggers can be
   easily supported.


3.5. 802.11 (Ad hoc mode)

   802.11 nodes operating in ad hoc mode (in the absence of an Access
   Point) do not automatically sense MAC layer neighbor adjacency.
   Hence support is not readily available for L2 triggers in the
   existing standard.  Explicit configuration (in the knowledge of no
   L2 trigger support) would be required to then effectively treat this
   interface as a broadcast interface.

   In this case the triggered interface abstraction does not apply.
   The MAC simply does not enable support of L2 triggers.  This is
   principally because support for ad hoc networking is a *secondary*
   mode in 802.11, and the standard is not optimized for this mode of
   operation. It is possible that support for L2 triggers could be
   added to future versions of the 802.11 MAC if support for them
   exists at the IP layer.

   Presently L3 messaging is required to detect neighbor adjacency in
   MANET routing protocols operating over ad hoc 802.11.  Given the
   increasing bandwidth of these standards (e.g. future 802.11 variants
   intend to support much higher rates), L3 neighbor detection may be
   feasible in these networks, although still at a cost.


Corson                                                               8
Internet Draft          A Triggered Interface                May 2002



3.6. MANET

   In general, MANET interfaces would benefit from operating as
   triggered interfaces rather than broadcast interfaces.  The ability
   for a MANET router to dynamically learn about peer-to-peer MAC
   associations thru accurate and timely L2 triggers would increase the
   performance of MANET systems.


3.7. Future Technologies

   New wireless technologies will continue to appear.  Many of these
   will require the use of L2 triggers to support seamless mobility.
   Failure of the IP protocol stack to recognize and make use of L2
   trigger support when available on these technologies fundamentally
   hinders the ability to IP to effectively internetwork these
   technologies, and thus runs contrary to IP's fundamental purpose.
   Consequently, this memo recommends that minimally necessary
   standards work be undertaken to build the support for a triggered
   interface type into IP.


4. Acknowledgement

   I would like to acknowledge contributions herein from discussions
   with my colleagues Vincent Park, George Tsirtsis, Michaela
   Vanderveen and Alan O'Neill at Flarion Technologies.


Author's Address

   M. Scott Corson
   Flarion Technologies
   Bedminster One
   135 Route 202/206 South
   Bedminster, NJ 07921
   Phone: +1 908 947 7033
   Email: corson@flarion.com


Full Copyright Statement

   Copyright (C) The Internet Society (2002). 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


Corson                                                               9
Internet Draft          A Triggered Interface                May 2002


   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.






































Corson                                                              10