One document matched: draft-corson-triggered-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-23 05:53:33 |