Personal M. Scott Corson Flarion Technologies Internet Draft Title: draft-corson-triggered-00.txt Category: Informational May 2002 Expires : November 2002 A Triggered Interface 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