idnits 2.17.1 draft-corson-triggered-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2002) is 7826 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2119' on line 200 looks like a reference -- Missing reference section? 'RFC3077' on line 205 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Personal M. Scott Corson 2 Flarion Technologies 3 Internet Draft 4 Title: draft-corson-triggered-00.txt 5 Category: Informational May 2002 6 Expires : November 2002 8 A Triggered Interface 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 Layer 2 interfaces fundamentally operate as either broadcast or 39 point-to-point. From these primitives, additional layer 3 interface 40 constructs such as non-broadcast multiple access and point-to- 41 multipoint are created as necessary. This approach has served the 42 wired Internet well. However this memo argues that a third type of 43 layer 2 interface is necessary to seamlessly extend IP over dynamic 44 networks, principally wireless. This interface, here termed a 45 "triggered" interface, combines traditional broadcast interface 46 addressing semantics (i.e. support for unicast, multicast and 47 broadcast link layer addresses) with layer 2 trigger support for the 48 dynamic creation of peer-to-peer interface associations within an 49 otherwise broadcast interface. Its intended domain of applicability 50 covers cellular, WLAN, MANET, etc; in short all currently envisioned 51 forms of dynamic wireless networking. 53 1. Introduction 55 IP networking has long been used in wireless communications 56 beginning with early work on packet radio networks. Nowadays it is 57 common to send IP data over a variety of wireless technologies, both 58 fixed and mobile. Traditionally this has consisted of "best effort" 59 data communications, with the accompanying assumptions on packet 60 loss and latency. While voice and other forms of low-latency IP 61 data are also sometimes transported over wireless to end hosts, 62 these services are not yet widely available on a commercial basis. 64 Increasingly there is commercial interest in transporting all forms 65 of data over IP over wireless, especially voice. The use of 66 wireless technologies is desirable due to the ubiquity of access 67 they enable as well as their ability to support mobility. Meeting 68 the stringent requirements on packet loss and delivery latency for 69 voice traffic (and other forms of low latency data) places many 70 requirements on a wireless network; one of which is the ability to 71 quickly and efficiently determine the existence (or non-existence) 72 of a link, as this is central to determining IP reachability. 74 This capability is needed most commonly as a consequence of 75 movement-induced changes in network topology. Mobile handoff, 76 whether in cellular or WLAN contexts, generally requires that the 77 entire process complete within 10's of milliseconds is seamless 78 voice service is to be maintained. This requires very fast 79 detection of changes in link status. Oftentimes the change in the 80 status of a link (its UP or DOWN status) is associated with movement 81 or variation in physical channel conditions, but this need not be 82 the case. Other factors such as authentication and quality of 83 service considerations may impact the status of a link. 85 Two general approaches are available to detect changes in link 86 status at the IP layer: the direct use of layer 3 (L3 or IP layer) 87 mechanisms and the use of layer 2 (L2 or link layer) triggers to 88 inform IP. Each approach has advantages and disadvantages. 90 1.1. L3 Link Detection 92 The usage of L3 mechanisms is advantageous in that they are generic 93 and work across all link layers. Their usage is also practically 94 expedient in that their standardization is only required in one 95 standards body, the IETF, as opposed to across both the IETF and 96 other link layer standards bodies such as the IEEE. Consequently 97 their usage is generally preferred when practical. 99 Unfortunately in many instances a pure L3 approach may not work well 100 enough and thus, perversely, may not be generally applicable. Link 101 layers vary greatly in both form and function. Some are connection- 102 oriented (e.g. Bluetooth) while others are not (e.g. 802.11). Some 103 are bandwidth-constrained (e.g. cellular) while others are less so 104 (e.g. WLAN). Some are continuously beaconing (e.g. HIPERLAN1) while 105 others may not (e.g. energy-constrained sensor networks). In order 106 to quickly detect a link status change (in the low 10's of 107 milliseconds), frequent, periodic L3 messaging is required on the 108 order of 100-200 messages per second in each direction. This may 109 not be practical for many bandwidth or energy-constrained wireless 110 technologies. Such an algorithm may also need heuristic tuning for 111 each link layer given each technology's unique characteristics, 112 which then breaks the notion that the IP layer should be generic and 113 L2-agnostic. 115 1.2 L2 Link Detection 117 An alternative to this is the use of L2 triggers. A link layer best 118 knows its current link status. It is a peer-to-peer relationship 119 between a pair of interfaces at the link layer. The principle of 120 separation of concerns suggests that IP allow the link layer to 121 ascertain its own status (in many cases it will do this anyway) and 122 report this to IP. It is true that not all link layers dynamically 123 ascertain link status between pairs of adjacent interfaces. These 124 link layers are therefore best viewed as either traditional point- 125 to-point or broadcast, and over these L2's IP should be configured 126 to detect link status via its own mechanisms as is commonly done. 128 However, for those link layers that do ascertain link status (the 129 majority), use of L2 trigger information is usually the only 130 feasible manner to quickly determine link status and, hence, IP 131 connectivity. By necessity a pure L3 detection approach provides a 132 *lagging* indicator. For IP messages to flow (or to stop flowing), 133 the link itself will *already* be UP (or DOWN), and the link layer 134 establishment processing has already added delay of its own. 135 Consequently IP can only begin to determine what has happened 136 *after* it has happened at the link layer. In virtually all cases 137 this will be too late to support seamless voice and low latency data 138 service. In cases where the link layer ascertains its own status, 139 the use of L2 triggers can inform the IP layer without ambiguity or 140 delay in the event of a link status change. 142 The observation that L2 trigger support is necessary for a variety 143 of link layers begs the question as to how this support should be 144 realized. 146 1.3. Incorporating L2 Triggers into IP 148 Up to now, support for mobility within the Internet has been an 149 afterthought. Standardized support for intra-domain, mobile, 150 prefix/host-based native routing does not exist. The only present 151 standard alternative is to use tunneling with Mobile IP. 153 Mobile IP would perhaps have been better named "Portable IP", as its 154 original design was intended to support remote access-based 155 operation in support of inbound IP reachability for "road warriors" 156 equipped with portable devices connecting while *away* from their 157 home subnet. Insufficient consideration was given to supporting 158 true mobility, resulting in the recent flurry of activity in the MIP 159 and other WGs to address these shortcomings. These solutions cannot 160 function effectively for many link layers without the additional 161 support of L2 triggers. 163 Mobile Ad hoc Networking represents a dynamic form of IP networking 164 where the entire network infrastructure may potentially be mobile. 165 Many link layers exist from which MANETs may be formed. Many of 166 these link layers dynamically detect the presence/absence of 167 neighbors within those link layers. It is not only desirable to 168 make use of this information when known, it is typically required 169 for these link layers if seamless internetworking of voice and other 170 demanding applications is to be achieved. 172 Recognition of the limitations of the existing L2-oblivious IP 173 approach is essential before first class support for mobility can be 174 incorporated within IP's purview. Currently IP does not give 175 mobility appropriate treatment and its performance over mobile 176 networks suffers without non-standard modifications. In order a 177 fully integrate mobility support within IP, reconsideration is 178 required of the proper relationship between IP and the vast array of 179 dynamic link layer technologies that now exist and will exist going 180 forward. Dynamic interfaces (principally wireless) require a modest 181 level of recognition from the IP stack for efficient internetworking 182 to occur. Modification of IP kernels to support the minimal 183 functionality described here would fundamentally enhance the 184 Internet's capability going forward. 186 There are several ways one might consider adding support for L2 187 triggers into IP. This memo now argues that definition of a new 188 "triggered" L2 interface type is the most appropriate architectural 189 solution. This memo describes how this simple interface abstraction 190 can handle the case of network-level mobility within a fixed 191 infrastructure (e.g. Mobile IP-based connectivity) and mobility of 192 an infrastructure itself (e.g. MANET-based connectivity). 194 2. Conventions used in this document 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 198 this document are to be interpreted as described in RFC-2119 199 [RFC2119]. 201 3. A Triggered Interface 203 Layer 2 interfaces fundamentally operate as either "broadcast" or 204 "point-to-point". This holds true even for recent work on 205 unidirectional satellite links [RFC3077] wherein a broadcast link is 206 emulated through the use of link layer tunneling. From these two 207 primitives, additional layer 3 interface constructs such as non- 208 broadcast multiple access (NBMA) and point-to-multipoint are created 209 as necessary. This approach has served the existing Internet well. 211 However, to support many existing and emerging link layer 212 technologies, this memo argues that a third type of layer 2 213 interface is necessary to seamlessly extend IP over dynamic 214 networks. This interface, here termed a "triggered" interface, 215 combines traditional broadcast interface addressing semantics with 216 layer 2 trigger support for the dynamic creation of peer-to-peer, 217 link layer interface associations within an otherwise broadcast 218 interface. 220 A triggered interface type would retain the addressing and 221 transmission behavior of a broadcast interface (i.e. support for 222 unicast, multicast and broadcast MAC addresses). Thus behavior akin 223 if not equivalent to ARP/RARP would be required for resolving 224 unicast MAC addresses. Also, a mapping of IP multicast to link 225 layer multicast addressing is required, as is support for MAC 226 broadcast. 228 A triggered interface would also support a dynamic set of link layer 229 associations. An "association" or "link" is defined as a peer-to- 230 peer relationship between two link layer interfaces that can 231 *directly* and *bi-directionally* communicate with each other. The 232 status (i.e. the existence or non-existence) of these associations 233 (or links) would be determined by the link layer, and signaled by 234 the link layer thru the triggered interface to the IP stack using L2 235 triggers. 237 In a fixed infrastructure, from an IP Base Station's (BS) 238 perspective, the interface would generally have multiple Mobile 239 Node's (MN) associated with it at the link layer (1-to-N), while 240 from the MN's perspective it would oftentimes have only one link to 241 the BS (1-to-1) as shown in the following figure. 243 BS 1-to-N (one BS to N MNs) 244 / | \ 245 / | \ 246 MN MN MN 1-to-1 (one MN to one BS) 248 Figure 1: Typical Cellular/WLAN View (Base Stations and Mobile 249 Nodes) 251 In the future cellular/WLAN link layers will also likely exist that 252 permit a MN to simultaneously connect to multiple BSs as shown in 253 Figure 2, so this possibility should be considered as well. 255 BS BS 1-to-N (one BS to N MNs) 256 / \ / | \ 257 / \ / | \ 258 MN MN MN MN 1-to-N (one MN to N BSs) 260 Figure 2: Future Cellular/WLAN View (Base Stations and Mobile 261 Nodes) 263 In an ad hoc network, Mobile Routers (MR) will generally have 264 multiple neighboring mobile routers, so the 1-to-N relation would 265 hold as well. 267 MR MR 268 \ / \ 269 MR------MR-----MR 1-to-N (one MR to N MRs) 270 / / \ 271 MR MR MR 273 Figure 3: Ad hoc Network View (Mobile Routers) 275 So going forward the general case in both cellular, WLAN and MANET 276 contexts is 1-to-N, with 1-to-1 being a special case. 278 The exact composition of an L2 trigger is also not specified here. 279 An L2 trigger MUST contain the MAC address of the adjacent neighbor 280 interface. Its reception at the IP stack would signal that a bi- 281 directional link layer communication capability exists (a link has 282 come UP) or ceases to exist (a link has gone DOWN) between two 283 adjacent interfaces. The MAC address presented to IP MUST remain 284 constant while the link is UP. 286 The behavior of an IP stack to the reception of these triggers is 287 not specified here. Whether any mandatory behaviors are required is 288 an open issue. The potential exists for an IP stack to immediately 289 issue a Reverse ARP (RARP) request for the adjacent interface. 291 Additional IP stack behavior modification on top of the support for 292 L2 triggers may also be required. The proper treatment of broadcast 293 and multicast traffic on this interface type should to be 294 reconsidered as well. The traditional treatment of IP multicast 295 over broadcast interfaces is not appropriate for MANETs or future 296 cellular and WLAN contexts. IP multicast traffic is typically not 297 rebroadcast out the broadcast interface over which it was received, 298 however this would often be required for triggered interfaces. 300 The triggered interface type would be useful for both IPv4 and IPv6. 301 However the commercial will to undertake the necessary IP stack 302 modifications may only be present for IPv6. 304 The intended usage of this interface type is straightforward. It 305 appears that this simple interface abstraction can support many 306 existing and envisioned link layers. It maps well onto cellular, 307 WLAN, PAN and MANET interfaces as we now illustrate with simple 308 examples. 310 3.1. Cellular 312 Cellular communications occur between BSs and MNs. Note that I am 313 now describing IP-based networks, where both base stations and 314 mobiles are IP elements. 316 Circuit-oriented air interfaces establish point-to-point links at 317 the physical layer, and typically run PPP or equivalent to establish 318 IP connectivity. This approach is sensible for the delivery of 319 unicast data, but is very inefficient for the delivery of broadcast 320 and multicast traffic given that the base station's transmissions 321 are inherently broadcast at the physical layer. To deliver these 322 forms of traffic, ATM-like NBMA or point-to-multipoint interfaces 323 are required at an IP base station (assuming IP is brought directly 324 to the base station, now also a router), and the triggered interface 325 discussion does not apply. 327 To deliver bandwidth-efficient services as well as high levels of 328 statistical multiplexing over the air, emerging packet-oriented 329 cellular technologies offer support for broadcast and multicast 330 addressing at the link layer in addition to unicast communications. 331 Consequently a broadcast-oriented interface is used. 333 In both cases (circuit or packet-orientation), cellular link layers 334 typically have the property that the establishment or loss of a link 335 is immediately known at both ends, and can be signaled to the IP 336 stacks on the MN and BS. This is a typically consequence of their 337 physical and MAC layer designs as well as the general need to 338 perform link layer authentication. 340 The triggered interface is sufficiently generic to handle all 341 cellular air interfaces in terms of addressing and L2 trigger 342 support. 344 3.2. 802.11 (Infrastructure mode) and HIPERLAN2 346 Both HIPERLAN2 and 802.11 in Infrastructure mode operate in a 347 fashion synonymous to emerging packet-based cellular technologies, 348 and would benefit from the use of triggered interfaces in hosts as 349 well as BS (integrated IP Access Router/Access Point) boxes. 351 802.11 interfaces are currently defined as broadcast interfaces. 352 Re-classification as triggered interfaces in end hosts would not 353 change addressing practice, but would enable cleaner support for L2 354 triggers by enabling existing link layer "association/de- 355 association" signals to be passed up to the end host IP stack in a 356 generic fashion as standard L2 triggers. These signals are 357 generated automatically at the BS and MN ends of a link when a BS is 358 operating in infrastructure mode. 360 3.3. HIPERLAN1 362 HIPERLAN1 was originally developed as a 20Mbps multi-hop, ad hoc 363 networking technology employing broadcast transmissions with omni- 364 directional antennas. The MAC protocol was designed explicitly to 365 support neighbor detection and utilizes beaconing at the MAC layer. 366 Hence HIPERLAN1 (and any future similar MAC layers) would map well 367 into a triggered interface type. 369 3.4. Bluetooth 371 The Bluetooth MAC is connection-oriented and TDMA-based. Its 372 interfaces automatically detect each other and form peer-to-peer 373 associations at the MAC layer in addition to using broadcast and 374 unicast addressing while communicating. Thus a triggered interface 375 classification suits Bluetooth quite well and L2 triggers can be 376 easily supported. 378 3.5. 802.11 (Ad hoc mode) 380 802.11 nodes operating in ad hoc mode (in the absence of an Access 381 Point) do not automatically sense MAC layer neighbor adjacency. 382 Hence support is not readily available for L2 triggers in the 383 existing standard. Explicit configuration (in the knowledge of no 384 L2 trigger support) would be required to then effectively treat this 385 interface as a broadcast interface. 387 In this case the triggered interface abstraction does not apply. 388 The MAC simply does not enable support of L2 triggers. This is 389 principally because support for ad hoc networking is a *secondary* 390 mode in 802.11, and the standard is not optimized for this mode of 391 operation. It is possible that support for L2 triggers could be 392 added to future versions of the 802.11 MAC if support for them 393 exists at the IP layer. 395 Presently L3 messaging is required to detect neighbor adjacency in 396 MANET routing protocols operating over ad hoc 802.11. Given the 397 increasing bandwidth of these standards (e.g. future 802.11 variants 398 intend to support much higher rates), L3 neighbor detection may be 399 feasible in these networks, although still at a cost. 401 3.6. MANET 403 In general, MANET interfaces would benefit from operating as 404 triggered interfaces rather than broadcast interfaces. The ability 405 for a MANET router to dynamically learn about peer-to-peer MAC 406 associations thru accurate and timely L2 triggers would increase the 407 performance of MANET systems. 409 3.7. Future Technologies 411 New wireless technologies will continue to appear. Many of these 412 will require the use of L2 triggers to support seamless mobility. 413 Failure of the IP protocol stack to recognize and make use of L2 414 trigger support when available on these technologies fundamentally 415 hinders the ability to IP to effectively internetwork these 416 technologies, and thus runs contrary to IP's fundamental purpose. 417 Consequently, this memo recommends that minimally necessary 418 standards work be undertaken to build the support for a triggered 419 interface type into IP. 421 4. Acknowledgement 423 I would like to acknowledge contributions herein from discussions 424 with my colleagues Vincent Park, George Tsirtsis, Michaela 425 Vanderveen and Alan O'Neill at Flarion Technologies. 427 Author's Address 429 M. Scott Corson 430 Flarion Technologies 431 Bedminster One 432 135 Route 202/206 South 433 Bedminster, NJ 07921 434 Phone: +1 908 947 7033 435 Email: corson@flarion.com 437 Full Copyright Statement 439 Copyright (C) The Internet Society (2002). All Rights Reserved. 441 This document and translations of it may be copied and furnished to 442 others, and derivative works that comment on or otherwise explain it 443 or assist in its implementation may be prepared, copied, published 444 and distributed, in whole or in part, without restriction of any 445 kind, provided that the above copyright notice and this paragraph 446 are included on all such copies and derivative works. However, this 447 document itself may not be modified in any way, such as by removing 448 the copyright notice or references to the Internet Society or other 449 Internet organizations, except as needed for the purpose of 450 developing Internet standards in which case the procedures for 451 copyrights defined in the Internet Standards process must be 452 followed, or as required to translate it into languages other than 453 English. 455 The limited permissions granted above are perpetual and will not be 456 revoked by the Internet Society or its successors or assigns. 458 This document and the information contained herein is provided on an 459 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 460 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 461 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 462 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 463 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 465 Corson 10