idnits 2.17.1 draft-yegin-dna-l2-hints-01.txt: -(1110): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1330 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 951: '...ints are advisory only. They SHOULD be...' RFC 2119 keyword, line 958: '... MUST be ensured. This is a subject ...' 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'GPRS-AT' is defined on line 968, but no explicit reference was found in the text == Unused Reference: '80211i' is defined on line 1004, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GPRS-AT' -- Possible downref: Non-RFC (?) normative reference: ref. 'GPRS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IAPP' -- Possible downref: Non-RFC (?) normative reference: ref. '80211i' ** Obsolete normative reference: RFC 3344 (ref. 'MIPv4') (Obsoleted by RFC 5944) == Outdated reference: A later version (-18) exists of draft-ietf-dhc-dna-ipv4-05 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Alper Yegin (Editor) 3 Document: draft-yegin-dna-l2-hints-01.txt DoCoMo USA Labs 4 Expires: August 2004 Eric Njedjou 5 France Telecom R&D 6 Siva Veerepalli 7 Qualcomm, Inc 8 Nicolas Montavont 9 Thomas Noel 10 LSIIT -University Louis Pasteur 12 Link-layer Triggers and Hints for Detecting Network Attachments 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 Certain link-layer technologies are capable of providing various link 36 status information to the IP module. Link-layer event notifications 37 (triggers) along with optional auxiliary data (hints) can help the IP 38 module make expedited decisions regarding configuration changes. This 39 draft provides a non-exhaustive catalogue of triggers and hints from 40 well-known link-layer technologies. 42 Yegin et al. Expires April August 2004 43 [Page 2] L2 Triggers and Hints February 2004 45 Table of Contents 47 1.0 Introduction.................................................2 48 2.0 Terminology..................................................3 49 3.0 Link-layer Triggers and Hints in Various Systems.............6 50 3.1. GPRS........................................................6 51 3.1.1. Network Reference Model...................................7 52 3.1.2. Link-layer Events and Information.........................7 53 3.2. 3GPP2......................................................11 54 3.2.1. Network Reference Model..................................11 55 3.2.2. Link-layer Events and Information........................13 56 3.3. WLAN.......................................................14 57 3.3.1. Network Reference Model..................................15 58 3.3.2. Link-layer Events and Information........................17 59 4.0 Triggers and Hints..........................................17 60 4.1. Link-up Trigger and Associated Hints.......................18 61 4.2. Link-down Trigger..........................................18 62 5.0 Security Considerations.....................................19 63 6.0 References..................................................19 64 7.0 Acknowledgements............................................20 65 Appendix A.......................................................20 66 A.1. Routing Area and Cell Change................................20 67 A.1.1. Link-layer Information....................................21 68 A.2. Sub-link-layer Information..................................21 69 Authors' Addresses...............................................22 70 Full Copyright Statement.........................................22 72 1.0 Introduction 74 It is not an uncommon occurrence for a host to change its point-of 75 attachment to the network. This can happen due to mobile usage 76 (e.g., a mobile phone moving among base stations) or nomadic usage 77 (e.g., road-warrior case). 79 Each time a host changes its point-of attachment, it is possible 80 that it will also have to change its IP-layer configurations, such 81 as its IP address and default gateway information. In order to make 82 these changes, the IP module has to detect the new network 83 attachment, realize that the old configuration is no longer valid 84 and obtain the new configuration parameters. The network detection 85 phase can usually use network-layer indications such as a change in 86 the advertised prefixes. But generally reliance on such indications 87 does not yield rapid detection, since these indications are not 88 readily available upon a link change. 90 Link-layer event notifications to the IP are considered link-layer 91 triggers. From detecting network attachment perspective, an 93 Yegin et. al. Expires April August 2004 94 [Page 3] L2 Triggers and Hints February 2004 96 auxiliary data delivered in association with a trigger is considered 97 a hint. It has been identified that receiving explicit triggers and 98 hints from the link-layer would expedite the detection process. The 99 link-layer indicating that the host has established a new connection 100 can be used as a trigger to further probe the network for a possible 101 configuration change. Additional hints when present can be used as 102 input to this process. 104 A link-layer trigger cannot be used to positively determine the need 105 for a configuration change as it might very well be the case that 106 the host is still connected to the same IP subnet despite the link 107 change. For example, there might be several IEEE 802.11b access 108 points connected to the same access router. Moving among these 109 access points does not warrant any IP-layer configuration change. 110 This is why the link-layer triggers should be used as "advisory- 111 only" unless stated otherwise. 113 In order to enable an enhanced network attachment detection scheme, 114 we need to identify types of link-layer triggers and hints that can 115 be realistically expected from various access technologies. The 116 objective of this draft is to provide a catalogue of existing link- 117 layer triggers and hints in various architectures. 119 The document limits itself to the minimum set of link-layer triggers 120 that are necessary for detecting network attachment. These triggers 121 are considered with hosts in mind, although they may also be 122 available on the network side (e.g., on the access router). 124 2.0 Terminology 126 Some of the terminology differs among the discussed architectures. 127 An architecture name is provided in parenthesis when a term has 128 limited applicability. 130 3GPP Third Generation Partnership Project 132 3GPP2 Third Generation Partnership Project 2 134 ANID Access Network Identifier. Identifies the packet switched 135 area served by a unique combination of RAN and MSC area. 136 (3GPP2) 138 AP Access Point. An access point is an entity that provides 139 bridging between the radio link and the wired network. (WLAN) 141 APN Access Point Name. A parameter of the PDP context, in the 142 form of a logical name that is used to select the GGSN or the 143 external IP network. (3GPP) 145 AT Access Terminal. Another term used for Mobile Terminal in 146 3GPP2 networks. (3GPP2) 148 Yegin et. al. Expires April August 2004 149 [Page 4] L2 Triggers and Hints February 2004 151 BSC Base Station Controller. A BSC controls a set of BTS. (3GPP, 152 3GPP2) 154 BSS Base Station System. The system that is made up of BTSs and 155 BSCs. (3GPP) 157 BSS Basic Service Set. A BSS is composed of one AP and its 158 attached MNs. (WLAN) 160 BSSID Basic Service Set Identification. A unique identifier of a 161 BSS. In infrastructure mode, it is the MAC address of the AP. 162 (WLAN) 164 BTS Base Transceiver Station. Mobile terminal�s radio attachment 165 point to the network. A BTS is responsible for MTs within a 166 given radio cell.(3GPP, 3GPP2) 168 ESS Extended Service Set. The set composed of APs and associated 169 MNs(BSSs) that share a common distribution system. (WLAN) 171 FA Foreign Agent. A router on a mobile node's visited network 172 which provides routing services to the mobile node while 173 registered. 175 GGSN Gateway GPRS Support Node. A router between the GPRS core 176 network and an external IP network. (3GPP) 178 GMM GPRS Mobility Management. Sub-link-layer protocol between the 179 MT and the SGSN for handling MT movement. (3GPP) 181 GPRS General Packet Radio Service. Packet-switched data 182 transmission service on top of the GSM network. (3GPP) 184 GTP GPRS Tunneling Protocol. A protocol for encapsulating user 185 data traffic between the SGSN and the GGSN. (3GPP) 187 HA A router on a mobile node's home network which tunnels 188 datagrams for delivery to the mobile node when it is away 189 from home, and maintains current location information for the 190 mobile node. 192 IMSI International Mobile Subscriber Identity. A 12-digit number 193 that uniquely identifies a GPRS subscriber smart card. (3GPP) 195 LLC Logical Link Control. Data link protocol between the MT and 196 SGSN. (3GPP) 198 MN Mobile Node. A host or router that changes its point of 199 attachment from one network or subnet to another. 201 Yegin et. al. Expires April August 2004 202 [Page 5] L2 Triggers and Hints February 2004 204 MN Mobile Node. The conjunction of a Mobile Terminal, a SIM card 205 and Terminal Equipment. (3GPP) 207 MT Mobile Terminal. For example, a mobile phone handset or a 208 PCMCIA card. (3GPP) 210 MS Mobile Station. For example, a mobile phone or a combination 211 of mobile terminal (e.g., a phone) and terminal equipment 212 (e.g., a laptop). (3GPP2) 214 MUX Multiplex Layer. A link layer protocol used to multiplex 215 signaling and RLP protocols. (3GPP2) 217 NSAPI Network Layer Service Access Point Identifier. It is used to 218 identify a PDP context between MT and SGSN on top of the 219 Logical Link Control layer. It is set by the MT. (3GPP) 221 P-TMSI 222 Packet TMSI. A temporary IMSI allocated by the GPRS network 223 to the MT upon IMSI attach procedure.(3GPP) 225 PCF Packet Control Function (3GPP2) 227 PDP Address 228 Address of a MN for a given PDP context. (3GPP) 230 PDP Context 231 Soft state maintained between the Mobile Terminal, the SGSN 232 and the GGSN for guaranteeing a negotiated quality of service 233 for the IP flows exchanged between the GPRS Mobile Terminal 234 and an external Packet Data Network such as Internet. (3GPP) 236 PDSN Packet Data Serving Node. The default gateway router for MNs 237 in 3GPP2 networks. (3GPP2) 239 PLMN Public Land Mobile Network. A GPRS Network operated on a 240 national territory. (3GPP) 242 PPP Point-to-Point Protocol 244 RA Routing Area. Set of adjacent cells. A given number of RAs 245 are under the control of one SGSN. (3GPP) 247 RAN Radio Access Network. (3GPP, 3GPP2) 249 RLP Radio Link Protocol. A link-layer protocol used to improve 250 the physical-layer frame error rate over the air. (3GPP2) 252 R-P RAN-to-PDSN interface. Also known as the A10/A11 interface. 253 (3GPP2) 255 SGSN Serving GPRS Support Node. A router directly connected to the 257 Yegin et. al. Expires April August 2004 258 [Page 6] L2 Triggers and Hints February 2004 260 GPRS Radio Sub-System that handles the mobility of terminals 261 attached to the RAs under its authority. The SGSN is also the 262 Radio Sub-System interface to the GPRS IP core network. It 263 could be considered as an equivalent to the IEEE 802.11 264 access point. (3GPP) 266 SM Session Management. Sub-link-layer protocol between the MT 267 and the GGSN that handles the activation/deactivation of a 268 PDP Context. (3GPP) 270 SSID Service Set Identifier. Identifier of an ESS. (WLAN) 272 TE Terminal Equipment. A user's laptop for example. TE can 273 connect to the network via MT. (3GPP) 275 TI Transaction Identifier. This is the association between an 276 NSAPI and an identifier corresponding to an operation 277 performed on the associated PDP context. For example a 278 "Modify PDP Context Request" will be identified by a 279 Transaction Identifier. (3GPP) 281 TLLI Temporary Logical Link Identity. It is used by the SGSN to 282 identify a particular Mobile Terminal at the logical link 283 control layer. (3GPP) 285 3.0 Link-layer Triggers and Hints in Various Systems 287 This section provides an overview of various architectures and 288 discusses associated link-layer triggers and hints. 290 3.1. GPRS 292 Multi-interface terminals are changing the face of wireless IP 293 connectivity and GPRS [GPRS] is being one of the most pervasive 294 types of radio link for enabling multi-technology access to the 295 Internet. 297 GPRS is an enhancement to the GSM data transmission architecture and 298 capabilities, designed to allow for packet switching in user data 299 transmission within the GPRS network as well as for higher quality 300 of service for the IP traffic of Mobile Terminals with external 301 Packets Data Networks (PDN) such as the Internet or corporate LANs. 302 The GPRS architecture consists of a Radio Access Network and a 303 packet domain Core Network. 305 - The GPRS Radio Access Network is composed of Mobile Terminals, a 306 Base Station Subsystem (BSS) and Serving GPRS Support Nodes (SGSN). 307 The BSS is made up of radio cells called Base Transceiver Stations 308 (BTS) served under the control of Base Station Controllers (BSC). 310 Yegin et. al. Expires April August 2004 311 [Page 7] L2 Triggers and Hints February 2004 313 So-called Routing Areas are formed by the subdivision of BSCs. Each 314 SGSN in the GPRS architecture controls a set of RAs; 316 - An IP Core Network that acts as the transport backbone of user 317 datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN). The 318 GGSN ensures the GPRS IP core network connectivity with external 319 networks, such as Internet or Local Area Networks. 321 From the point of view prevailing in detecting network attachment, the 322 GPRS access network will be only seen as providing layer 1-2 323 reachability even if it is able to provide IP connectivity alone. 325 3.1.1. Network Reference Model 327 Most of the triggers described in this document come from messages 328 exchanged on top of the Logical Link Control protocol (LLC) running 329 between the Mobile Terminal and the SGSN. The messages are part of 330 the GPRS Mobility Management (GMM) and Session Management (SM) 331 protocols and ensure functionalities such as GPRS attach, detach, 332 PDP Context activation and deactivation, Routing Area update. 334 | 335 +----| <-------------GMM/SM--------------> +-----+ 336 | | <--------------LLC----------------> | | 337 | | | | 338 | | \ / | | 339 | MT | +-----+ |SGSN | 340 | | Radio interface | |<---------------->| | 341 | |<----Protocols--->| BSS | | | 342 +----+ (RLC, MAC, L1) +-----+ +-----+ 344 Figure 1. Signaling protocol stack between MT and SGSN 346 3.1.2. Link-layer Events and Information 348 In GPRS networks, only network attachment/detachment and subsequent 349 PDP context changing events will directly impact the IP 350 configurations, hence should be used as link-layer triggers by IP. 351 Other events such as routing area and cell change do not directly 352 imply potential configuration change. More details on those 353 secondary types of events can be found in Appendix A. 355 When connecting, first a GPRS attach needs to be made to the SGSN. 356 The procedure is attempted whenever a GPRS-enabled Mobile Terminal 357 is being switched on. The attachment can also take place at any time 358 while the MT is switched on, for example following a detach forced 359 by the network. The MT provides its identity during the attach 360 request to the network in the form of a so-called Packet Temporary 361 Mobile Subscriber Identity (P-TMSI). If the MT has no valid P-TMSI, 362 it provides its IMSI. 364 Yegin et. al. Expires April August 2004 365 [Page 8] L2 Triggers and Hints February 2004 367 Before the MT becomes GPRS attached, it scans for available GPRS 368 networks, as well as acquires the identities of their cells in the 369 covered area. It is also possible for the MT to obtain the radio 370 capabilities of these cells. 372 When a MT has performed the GPRS attach, it becomes in READY state. 373 In this state, the MT is reachable (using the logical link layer - 374 LLC) by the GPRS Radio Access Point called the SGSN. Otherwise, its 375 state is said to be IDLE. During the IDLE state, no IP level 376 communication is possible with an external network, such as 377 Internet. The SGSN identifies the logical link with the MT by the 378 Temporary Logical Link Identifier (TLLI) it derives from the P-TMSI 379 that was assigned to the MT. It has to be noted that the MT or SGSN 380 may initiate a detach procedure (Mobile or Network Initiated 381 Detach). The MT returns from READY to IDLE STATE upon detachment. 383 The MT is actually considered GPRS attached when it has received an 384 "Attach Accept" message from the SGSN. The MT is considered detached 385 from the GPRS Network when it has sent or received a "Detach Accept 386 message" from/to the SGSN. This is an indication that the link-layer 387 connectivity is being lost. 389 The "Detach Accept" message is also preceded by a "Detach Request" 390 message from the side initiating the detachment procedure. This 391 message is an indication that a detachment from the GPRS network is 392 about to take place. The network-layer could then anticipate the 393 loss of connectivity. 395 The "Attach Accept" message comes along with an update of the Mobile 396 Terminal Mobility Management context held at the GMM/MM level. This 397 message contains: 399 - The Packet Temporary Mobile Station Identifier (P-TMSI). The P- 400 TMSI is a temporary IMSI allocated by the GPRS network upon attach 401 (if no P-TMSI was already present). It is used for subscriber 402 location hiding purpose in substitution to the IMSI. 403 - The current Cell Identity (CI) 404 - The current Routing Area Identity (RAI) which identifies the 405 serving SGSN 406 - The ciphering algorithm, key (Kc) and sequence number (CKSN) 408 Once the GPRS MT is attached, the attached network information can 409 be sent to it via the "MM information" message that contains: 411 - The network name known as Public Land Mobile Network ID in 3GPP 412 terminology 413 - Network registration type (Home or Roaming) 415 A MN that wants to establish IP-level connections through the GPRS 416 MT should first request the GPRS network to settle the necessary 417 soft state mechanism (GPRS tunneling protocol) between its serving 419 Yegin et. al. Expires April August 2004 420 [Page 9] L2 Triggers and Hints February 2004 422 SGSN and the GGSN corresponding to the APN specified in the PDP 423 Context parameters. Only after this tunneling mechanism takes place 424 can the MN's IP packets be forwarded to and from its remote IP 425 peers. The process by which this is made possible is designated as a 426 PDP Context Request. 428 The aim of this function is also to provide IP-level configuration 429 on top of the GPRS link-layer attachment, in order for the MN to get 430 IP reachability with external networks, such as Internet. The 431 establishment of a PDP context is partially based on link-layer 432 characteristics negotiated between the MT and the GPRS network (SGSN 433 and GGSN). These characteristics include the QoS profile that will 434 be guaranteed by the SGSN and GGSN (e.g., maximum delay, link 435 reliability, peak and mean throughputs). When the MT requests a PDP 436 context, it selects a Network Service Access Point Identifier 437 (NSAPI) that it sends to the SGSN with the request. The NSAPI is 438 sent (as part of the PDP Context request message) on top the Logical 439 Link Control layer identified for that MT by the TLLI. In this way, 440 the SGSN is able to uniquely identify the PDP context. 442 A PDP context Activation procedure can also be initiated by the GGSN 443 (Network-requested PDP Context Activation) but this alternative is 444 not likely to happen so often. 446 The network may also decide to modify an existing PDP Context with a 447 given MN at any time. Such a modification might be prompted by the 448 MN's serving SGSN when it estimates that the negotiated QoS profile 449 can no longer be respected. For instance, the GPRS Network might 450 temporarily not be able to guarantee the contracted delay, in which 451 case it would force the related PDP context parameter to be 452 renegotiated. Note that, a MT can decide not to accept such an 453 update of its PDP context, in which case it should start a PDP 454 context deactivation procedure. Furthermore, a PDP context may be 455 deleted at any time at the request of the MT or the network. After a 456 PDP context is deleted, the MT returns to simply attached state 457 (READY STATE). Finally, a Mobile Terminal can hold several PDP 458 contexts, each corresponding to a different NSAPI. 460 +--------------+ 461 | PDP Context1 | +-------+ 462 | NSAPI 1 | | | 463 | ------------ | +------+ | | 464 | GPRS MT +-------+ TLLI +---------| SGSN | 465 | ------------ | +------+ | | 466 | PDP Context2 | | | 467 | NSAPI 2 | +-------+ 468 +--------------+ 470 Figure 2. NSAPI and TLLI (link identifier). 472 Yegin et. al. Expires April August 2004 473 [Page 10] L2 Triggers and Hints February 2004 475 A PDP context is considered activated on the MT side as soon as an 476 "Activate PDP Context Accept" message has been received from the 477 GGSN. The reception of this message can be considered as a trigger 478 that the GPRS network will be providing a certain link-layer 479 quality-of service for which parameters (e.g., delay, reliability, 480 throughput) are included with the messages described below. 482 When the network is about to modify a PDP Context, it informs the MT 483 by sending a "Modify PDP Context Request" message. This can also be 484 an indication at the MN's network-layer that the link-layer 485 characteristics on the GPRS attachment are about to change. The MN 486 could then be able to anticipate such a change, which would likely 487 be a drop or an increase of service quality. The "Modify PDP Context 488 Accept" message confirms the modification and is an indication that 489 the initially negotiated PDP context characteristics are no longer 490 valid. 492 A "Deactivate PDP Context Request" message is sent by the MN or 493 received from the SGSN depending on which side has initiated the 494 deactivation procedure. The transmission or reception of this 495 message can serve as a trigger that the IP configuration of the MN's 496 GPRS interface or one of its IP configuration (in case multiple PDP 497 Contexts are present on the MT), is about to be deleted. This could 498 help the MN anticipate the coming loss of IP attachment. A 499 "Deactivate PDP Context Accept" sent or received by the MT is a 500 confirmation that the PDP context is being deleted. 502 The "Activate PDP Context Accept" message comes along with a 503 modification of the GMM context that contains the following 504 information: 506 - The TI (transaction identifier) associated to the procedure of 507 activating a PDP context. It consists of the NSAPI generated by the 508 MT for that PDP context and an operation identifier, 509 - The IP address for that PDP context, 510 - The QoS Profile negotiated with the network, 511 - The Radio Priority level for data transmission. 513 The "Modify PDP Context Accept" comes along with the following 514 information: 515 -The TI associated to the procedure, 516 -The new QoS profile negotiated with the network, 517 -The radio priority level for data transmission. 519 The "Deactivate PDP Context Accept" message comes along with the TI 520 associated to the procedure. 522 Yegin et. al. Expires April August 2004 523 [Page 11] L2 Triggers and Hints February 2004 525 3.2. 3GPP2 527 3GPP2 (cdma2000) packet data services provide mobile users wide area 528 high-speed access to packet switched networks. 3GPP2 consists of 529 multiple radio access technologies, namely 1x EV, 1x EV-DO and 1x 530 EV-DV, where the order shows the evolution of technology in the 531 industry. 1x Evolution Data Only (1x EV-DO) and 1x Evolution Data- 532 Voice (1x EV-DV) are enhanced air interface technologies that are 533 optimized for higher data rates. 535 The aforementioned 3GPP2 technologies share a common core network 536 infrastructure which enables easy transition to enhanced air 537 interface technologies. 3GPP2 networks use the Point-to-Point 538 Protocol (PPP) as the link-layer protocol between the mobile node 539 and the network access server. Hence, link-layer mechanisms are 540 pretty consistent across all air interface technologies. Unless 541 specifically called out, all link-layer mechanisms specified in this 542 document apply to all 3GPP2 air interface technologies. 544 3.2.1. Network Reference Model 546 Some of the major components of the 3GPP2 packet network 547 architecture (see Figure 3) consist of: 549 - Mobile Node (also known as Mobile Station or Access Terminal in 550 3GPP2), which allows mobile access to packet-switched networks over 551 a wireless connection, 552 - Radio Access Network, which consists of the Base Station 553 Transceivers (BTS), Base Station Controllers (BSC), and the Packet 554 Control Function (PCF), 555 - Network Access Server known as the Packet Data Switching Node 556 (PDSN). The PDSN also serves as the Foreign Agent (FA), in the case 557 of Mobile IP service. 559 +-------------------------+ 560 | RAN | 561 +====+ | +=====+ +=====+ | +======+ 562 | | | | BSC/| | | | | | 563 | MN |-----------| | BTS |-------| PCF |--|-------| PDSN | 564 | | | | | A8/A9 | | |A10/A11| | 565 +====+ | +=====+ +=====+ | +======+ 566 | | 567 +-------------------------+ 569 Figure 3. Packet Network Reference Model 571 Figure 4 shows the hierarchical relationship between the RAN, 572 PDSN/FA and HA. The control and bearer interfaces between the BSC 574 Yegin et. al. Expires April August 2004 575 [Page 12] L2 Triggers and Hints February 2004 577 and PCF are known as the A9 and A8 interface respectively, while the 578 control and bearer interfaces between PCF and PDSN are known as the 579 A11 and A10 interfaces respectively. Note that, the A11/A10 580 interface is also known as the R-P interface (for RAN-PDSN 581 interface). The A9 and A11 interfaces are used to establish A8 and 582 A10 connections. The A8 and A10 connections are used to tunnel link 583 layer data (PPP frames) between the BSC and PDSN. 585 +======+ 586 | | 587 | HA | 588 | | 589 +======+ 590 | 591 | 592 +--------------+---------------+ 593 | | | 594 +======+ +======+ +======+ 595 | | | | | | 596 | PDSN | | PDSN | | PDSN | 597 | | | | | | 598 +======+ +======+ +======+ 599 / \ / \ / \ 600 A10/A11---------/---\------------/---\----------/---\--------- 601 / \ / \ / \ 602 / \ / \ / \ 603 +======+ +======+ +======+ \ / \ 604 | | | | | | +======+ +======+ 605 | PCF | | PCF | | PCF | | | | | 606 | | | | | | | PCF | | PCF | 607 +======+ +======+ +======+ | | | | 608 | / \ | +======+ +======+ 609 A8/A9 ----|--------/---\------|----------|-------------|----- 610 | / \ | | | 611 +====+ +====+ +====+ +====+ +====+ +====+ 612 | | | | | | | | | | | | 613 |BSC | |BSC | |BSC | |BSC | |BSC | |BSC | 614 | | | | | | | | | | | | 615 +====+ +====+ +====+ +====+ +====+ +====+ 617 +====+ 618 | | 619 | MS | -------> 620 | | 621 +====+ 623 Figure 4. Hierarchical relationship between RAN, PDSN and HA 625 Yegin et. al. Expires April August 2004 626 [Page 13] L2 Triggers and Hints February 2004 628 A PCF controls one or more BSCs. The area served by each PCF is 629 identified by the Access Network Identifier (ANID). This is referred 630 to as the SUBNET ID in the 1x EV-DO system. Any given BSC is 631 associated with one and only one PCF. The combination of BSC and PCF 632 is also known as the RAN. Each PCF can communicate with one or more 633 PDSNs. However, for a given mobile user, the PCF typically 634 establishes a connection with a specific PDSN. 636 Link-layer-related (e.g., handover) information is provided by the 637 RAN to the MS via 3GPP2 overhead signaling messages broadcast over 638 the air interface. 640 A number of other important components of the architecture that 641 enable call setup (such as the MSC, HLR, AC and/or AAA servers) are 642 left out for the sake of simplicity. None of these components have a 643 direct impact on the discussion of link-layer hints. 645 3.2.2. Link-layer Events and Information 647 While a PPP connection is in ESTABLISHED state at the MN and PDSN, 648 the packet data service state at the MN can be in ACTIVE or DORMANT 649 state. In the ACTIVE state, all the bearers between the MN and the 650 PDSN are in the established state. In the DORMANT state, the radio 651 link bearer and the A8 connection are torn down to conserve radio 652 resources. However, the A10 bearer still remains connected, and the 653 PPP state is maintained both at the MN and PDSN. 655 MN transitions from DORMANT to ACTIVE state when the MN has some 656 data to send or the network (PDSN) has data to send to the MN. When 657 a MN in ACTIVE packet data service state hands off from one RAN to 658 another, it results in an ANID change. An ANID change may or may not 659 result in a change in the MN point of attachment to the network 660 (i.e., PDSN). 662 If the ANID changes, but no change in the network attachment point, 663 a new A10 connection between the new PCF and serving PDSN is 664 established. If the ANID change results in a change in network 665 attachment point (i.e., PDSN), the new PDSN initiates a new PPP 666 connection setup with the MN, resulting in an update of the network 667 configuration information such as IP address and DNS server address 668 on the mobile node. In the case of Mobile IP, PPP resynchronization 669 is followed by Mobile IP registration to update the FA (PDSN) 670 address in the Mobile IP binding at the HA. 672 Hence, a PPP resynchronization from the PDSN could be viewed as a 673 link-layer event that updates network configuration information in 674 the MN and further provides an indication to the MN that Mobile IP 675 registration is required to update the binding in the HA with the 676 new FA address. 678 Yegin et. al. Expires April August 2004 679 [Page 14] L2 Triggers and Hints February 2004 681 On the other hand, when a DORMANT mobile moves, the RAN is not aware 682 of the presence of the mobile in its area (as the radio link is not 683 in established state). The RAN relies on the MN to inform it of the 684 MN's presence. The ANID for the RAN, which is broadcast on the 685 overhead channel, is used for determining RAN changes by the MN. 686 When a dormant MN moves and the ANID changes, the MN registers with 687 the RAN to initiate a new A10 connection between the new RAN and 688 PDSN. If the ANID change also results in a change in the network 689 attachment point, not only is a new A10 connection established, but 690 also a new PPP connection is established between the new PDSN and 691 MN. The RAN transitions the MN from DORMANT to ACTIVE state in order 692 to resynchronize the PPP connection. This results in an update in 693 the network layer configuration information such as IP address and 694 DNS server address in the MN. In the case of Mobile IP, PPP 695 resynchronization is followed by Mobile IP registration to update 696 the FA (PDSN) address in the Mobile IP binding at the HA. 698 As described above, a lower-layer indication (ANID change) allows a 699 MN to discover a potential change in the network point of 700 attachment. From IP's perspective, changes in the PPP link status 701 provide a trigger and hints about the network attachment change. 703 3.3. WLAN 705 WLANs are the wireless extension of the Local Area Networks. A WLAN 706 offers MNs short range network access at high rate. The maximum 707 coverage area of a node is usually from few meters indoors to more 708 than one hundred meter outdoor. The raw bandwidth varies between 709 1Mbps to 54Mbps depending on the norm used and the configuration of 710 the equipment. 712 The IEEE 802.11 series are specified by IEEE since 1997 and the 713 currently available standards are IEEE 802.11b [802.11b] and IEEE 714 802.11g [802.11g] operating in the 2.4GHz band, and IEEE 802.11a 715 [802.11a] operating in the 5GHz band. The specification defines both 716 the MAC-layer and the physical-layer (e.g., modulation techniques 717 and propagation). The MAC level is the same for all these 718 technologies. 720 Two operating modes are available in the IEEE 802.11 series. In ad- 721 hoc mode, each equipment in range may directly communicate with 722 other, i.e. without any infrastructure or intermediate hop. In 723 infrastructure mode, all link-layer frames are transmitted to an 724 access point (AP) which then forwards them to the final receiver. 726 In this section MN refers to a IEEE 802.11 station without the AP 727 functionality. 729 Yegin et. al. Expires April August 2004 730 [Page 15] L2 Triggers and Hints February 2004 732 3.3.1. Network Reference Model 734 In the infrastructure mode, the network connectivity is offered to 735 MN (IEEE 802.11 station) through an AP. An AP is a bridge between 736 the wireless domain and the wired domain. The coverage area of an AP 737 defines a cell. A BSS (Basic Service Set) is composed of one AP and 738 at least one attached MN. A common IEEE 802.11 infrastructure is 739 shown in Figure 5. 741 Access Router-----Internet-----Access Router 742 | | 743 | LAN LAN | 744 -+----+---- -+--------+------+- 745 | | | 746 | ~~~~~~~~~~~AP2~~~~~~~~~ | 747 ~~~~~~~AP1~~~~~~~~ ~~~~~~~AP3~~~~~~~~ 748 ~ ~ ~ ~ ~ ~ 749 ~ ~ ~ ~ ~ ~ 750 ~ MN ~ ~ ~ ~ ~ 751 ~ ~ ~ ~ ~ MN ~ 752 ~ ~ MN ~ ~ ~ ~ 753 ~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~ 754 BSS of AP1 ~ ~ BSS of AP3 755 ~ MN ~ 756 ~ ~ 757 ~~~~~~~~~~~~~~~~~~~~~~~ 758 BSS of AP2 760 Figure 5: Architecture of IEEE 802.11 access. 762 When several APs are connected together through a DS (Distribution 763 System), the set of all cells is called ESS for Extended Service 764 Set. The structure of the DS is not defined in the IEEE 802.11 765 standard and any technology can be used as DS medium. The document 766 IEEE 802.11f [IAPP] proposes the Inter-AP protocol (IAPP) to be used 767 between APs of the same ESS. Some information on attached MNs may be 768 exchanged in an ESS in order to enable context transfers and enhance 769 MN's roaming. 771 When a MN moves out of the coverage area of its current AP, it may 772 attach to a new AP. The new AP can be connected to the same access 773 network as well as it can be connected to a different access 774 network, this makes no difference at the link layer. However, if the 775 new AP is connected to the same subnet as the old AP, the MN can 776 continue its IP communication through the new AP without any 777 configuration change at the network-layer. But if the new AP is 778 connected to a different subnet, the MN needs to configure a new IP 779 address valid for the new subnet and use some additional mechanism 780 to maintain its ongoing communication sessions, such as Mobile IP 781 [MIPv4, MIPv6]. 783 Yegin et. al. Expires April August 2004 784 [Page 16] L2 Triggers and Hints February 2004 786 A MN must be associated and authenticated with an AP in order to 787 send and receive data frames. At any given time, a MN can be 788 associated with only one AP on each IEEE 802.11 radio interface. 789 When a MN moves between two APs, it has to switch into promiscuous 790 mode to discover and initiate a connection with a new AP. A MN 791 cannot send IP packets during the establishment of a connection with 792 an AP. In an RSN (Robust Secure Network [802.11i]) the data packets 793 are still blocked until the IEEE 802.1X authentication and key 794 management is successfully completed. 796 Being associated implies that the MN has established a relationship 797 with the AP. 799 In a WLAN that does not support RSNA (RSN Association), three 800 different steps are required for the MN to be associated with an AP. 801 First the MN evaluates the potential APs in its range. In active 802 mode, the MN scans its default channel to identify the available APs 803 (exchange of Probe Request and Probe Response). If the MN does not 804 receive any response from AP (e.g., no APs are operating in this 805 channel), the MN switches to the next channel and continues the 806 scanning. In passive mode, the MN only listens to beacons sent by AP 807 to discover the potential APs. 809 Once the MN discovers its target AP and its parameters, an 810 authentication phase begins (exchange of Authentication 811 Request/Response). 813 When a MN succeeds the authentication process, it can associate with 814 the AP (exchange of Association Request/Response). The MN sends its 815 different link-layer parameters and the AP may accept to include the 816 MN in the BSS. A MN may also issue a Re-association Request when the 817 new AP belongs to the same ESS as the old AP of the MN. The 818 Re-association message contains the MAC address of the old AP of the 819 MN, allowing the new AP to inform old AP that the MN will now be 820 associated with it. Note that even if the two APs belong to the same 821 ESS, they can be on different IP subnets. No assumption is made on 822 the location of APs in IEEE 802.11 series. 824 In a IEEE 802.11 RSN, IEEE 802.1X might be used as the 825 authentication and key management mechanism. In this framework, the 826 authentication is performed after the MN is connected to the AP by 827 utilizing protocols above the MAC layer. The process to be 828 associated with an AP is the same as in the model described above, 829 except that authentication at the MAC layer must not take place. The 830 (re-)association of a MN is mapped to an IEEE 802.1X port on the AP, 831 and the controlled IEEE 802.1X port blocks every data packets. Only 832 the EAPOL packets are authorized to be sent through the uncontrolled 833 IEEE 802.1X port. Once the authentication successfully completes, 834 the 4-way handshake protocol takes place. The 4-way handshake 835 consists of four EAPOL messages sent between the MN and the AP which 836 guarantee the liveness of both the AP and the MN, the freshness and 838 Yegin et. al. Expires April August 2004 839 [Page 17] L2 Triggers and Hints February 2004 841 the synchronization of the session key. This triggers the change of 842 the state of the IEEE 802.1X port from blocked to unblocked. 843 Subsequently, data packets can be exchanged on the link. 845 3.3.2. Link-layer Events and Information 847 The roaming of MNs between APs is managed by the link-layer protocol 848 and is known as link-layer handover. As long as the MN moves between 849 APs in the same access network, the IP layer is not involved in the 850 movement management. However, when the MN handovers to a new AP in 851 another IP subnet, the MN needs to perform operations to maintain 852 its existing communications [MIPv4, MIPv6]. Therefore, even if a 853 link-layer handover occurs at the link layer, it doesn't necessarily 854 imply a network-layer handover. 856 In a WLAN that does not support RSN, upon reception of the 857 Association (or Re-association) response message from the AP 858 indicating that the association is accepted, the MN is associated to 859 the AP. It can then transmit and receive data packets through this 860 AP. This association is valid as long as the MN does not receive a 861 De-authentication message or a De-association message from its AP, 862 or the MN moves to a new AP. 864 So the reception of a (Re-)Association Response that completes a 865 successful association conveys that the MN's point of attachment to 866 the network may have changed. There is no mechanism at the link- 867 layer that allows the MN to know if it has also changed the IP 868 subnet. 870 In a RSN, data packets between the MN and the AP are allowed upon 871 successful completion of a 4-way handshake. In this case, the 872 reception of a (Re-)Association Response does not imply the link is 873 established yet. 875 When the MN receives a De-authentication message (in the case of the 876 MAC layer authentication) or a Disassociation message, it means that 877 the MN is no longer authenticated or associated with the AP that 878 sent the message. So this message indicates that IP packets can not 879 be sent through this link until the reception of a subsequent 880 (Re)Association Response or 4-way handshake. 882 4.0 Triggers and Hints 884 A small set of useful link-layer triggers and hints can be 885 identified based on the technologies described in Section 3.0. This 886 document limits the scope to those that are relevant to network- 887 layer configuration changes. 889 Yegin et. al. Expires April August 2004 890 [Page 18] L2 Triggers and Hints February 2004 892 4.1. Link-up Trigger and Associated Hints 894 This trigger is asynchronously provided to IP when a new link 895 instance is created. This trigger may be generated even when the 896 host does not change its physical point-of attachment but creates a 897 new link instance with the current link-layer access device. 899 Network-layer may interpret this trigger as a sign of possible 900 configuration change. It may react to link-up trigger by 901 reconfirming its current configuration (e.g.: sending a router 902 solicitation in the case of stateless IPv6 address auto- 903 configuration). The detailed use of link-up trigger for detecting 904 network attachment is outside the scope of this draft. 906 Creation of a new PDP context can be used to generate a link-up 907 trigger in GPRS networks. Similarly, a new PPP link establishment 908 can lead to a trigger in 3GPP2 networks. Both of these mechanisms 909 also provide network-layer configuration on the host. The IP 910 addresses configured via these mechanisms can be considered as link- 911 layer hints. In fact, this type of strong hint simplifies the task 912 of detecting network attachment at the network-layer. This hint 913 indicates the already configured parameters, hence further network 914 attachment detection is generally not necessary. 916 Association and re-association events in non-RSN, and completion of 917 4-way handshake in RSN can be used to generate a link-up trigger in 918 IEEE 802.11 networks. Unlike the technologies used in 3GPP and 919 3GPP2, network�layer configuration is not provided as part of link- 920 layer establishment in IEEE 802.11 networks. Aside from not 921 providing the IP address configuration, this link-layer does not 922 present a useful hint to be used with the network attachment 923 detection process either. This is due to lack of a one-to-one 924 mapping between IP subnets and link-layer parameters. See Appendix A 925 of [DNA4] for a detailed discussion. 927 4.2. Link-down Trigger 929 This trigger is asynchronously provided to IP when an existing link 930 instance is removed. 932 Network-layer may interpret this trigger as a sign of possible 933 configuration change. This trigger might be followed by a link-up 934 trigger in the case of a handover. The detailed use of link-down 935 trigger for detecting network attachment is outside the scope of 936 this draft. 938 The deactivation of PDP context in GPRS networks can be used to 939 generate the link-down trigger. Bringing down a PPP connection in 940 3GPP2 would have the same effect. De-authentication and 941 disassociation events in IEEE 802.11 non-RSN, and disassociation 943 Yegin et. al. Expires April August 2004 944 [Page 19] L2 Triggers and Hints February 2004 946 event in IEEE 802.11 RSN can be used to generate a link-down trigger 947 being sent to IP. 949 5.0 Security Considerations 951 The link-layer triggers and hints are advisory only. They SHOULD be 952 used as indications of possible network-layer configuration change, 953 not an absolute change. When used in this context, potential 954 security threats from their use is limited but not necessarily 955 completely eliminated. A faked link-layer trigger can still be used 956 to launch a denial-of service attack on the host and the associated 957 network. Secure generation and delivery of these triggers and hints 958 MUST be ensured. This is a subject for lower-layer designs and 959 therefore it is outside the scope of this document. 961 6.0 References 963 [3GPP2/TIA] "IS-835 - cdma2000 Wireless IP Network Standard" 965 [3GPP2/TIA] "IS-2001 � Interoperability Specification (IOS) for 966 cdma2000 Access Network Interfaces" 968 [GPRS-AT] "Digital cellular telecommunications system (Phase 2+); AT 969 command set for GPRS Mobile Equipment (ME), (GSM 07.07 version 7.8.0 970 Release 98). 972 [GPRS] "Digital cellular telecommunications system (Phase 2+); 973 General Packet Radio Service (GPRS) Service description; Stage 2", 974 (3GPP TS 03.60 version 7.9.0 Release 98). 976 [GPRS-LINK]"Digital cellular telecommunications system (Phase 2+); 977 Radio subsystem link control", (GSM 03.05 version 7.0.0 Release 98). 979 [IAPP] IEEE Std. 802.11f/D3, Draft supplement to IEEE Std 802.11, 980 1999 Edition, "Recommanded Practice for Multi-Vendor Access Point 981 Interoperability via an Inter-Access Point Protocol Across 982 Distribution Systems Supporting IEEE 802.11 Operation", January 983 2002. 985 [802.11b] IEEE Std 802 Part 11, "Information technology - 986 Telecomunications anbd information exchange between systems - Local 987 and metropolitan area networks - Specific requirements - Part 11: 988 Wireless Lan Medium Access Control (MAC) And Physical Layer (PHY) 989 Specifications", August 1999. 991 [802.11a] IEEE Std 802.11a-1999, supplement to IEEE Std 802.11-1999, 992 "Part 11: Wireless MAN Medium Access Control (MAC) and Physical 993 Layer (PHY) specifications: High-speed Physical Layer in the 5 GHZ 994 band, September 1999. 996 Yegin et. al. Expires April August 2004 997 [Page 20] L2 Triggers and Hints February 2004 999 [802.11g] IEEE Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999 1000 edition, "Part 11: Wireless "Part 11: Wireless MAN Medium Access 1001 Control (MAC) and Physical Layer (PHY) specifications. Amendemnt 4: 1002 Further Higher Data Rate Extension in the 2.4 GHz Band, June 2003. 1004 [80211i] IEEE Draft 802.11I/D5.0, "Draft Supplement to STANDARD FOR 1005 Telecommunications and Information Exchange between Systems � 1006 LAN/MAN Specific Requirements - Part 11: Wireless Medium Access 1007 Control (MAC) and physical layer specifications: Specification for 1008 Enhanced Security", August 2003. 1010 [MIPv4] Perkins, C., "IP Mobility Support for IPv4", RFC3344, August 1011 2002. 1013 [MIPv6] Perkins, C. and J. Arko, "Mobility Support in IPv6", I-D 1014 draft-ietf-mobileip-ipv6-24.txt, June 2003. 1016 [DNA4] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", 1017 I-D draft-ietf-dhc-dna-ipv4-05.txt, January 2004. 1019 7.0 Acknowledgements 1021 The authors would like to acknowledge Sanjeev Athalye (Qualcomm) and 1022 Muhammad Mukarram bin Tariq (DoCoMo USA Labs) for their useful 1023 comments and suggestions. 1025 Appendix A 1027 This section describes the additional events and the associated 1028 information with the GPRS networks. Unlike the PDP context changes, 1029 the following events do not directly imply potential IP 1030 configuration change. 1032 A.1. Routing Area and Cell Change 1034 The GPRS Radio Sub-System is organized in sets of Routing Areas 1035 (RAs), each set managed by a unique SGSN. The RAs are in turn 1036 divided into cells. 1038 A GPRS MT detects that it has entered a new cell by comparing the 1039 cell's identity just received with the cell identity stored in the 1040 MT's Mobility Management context. A cell update procedure with the 1041 network then takes place between the MT and the SGSN. 1043 If the new cell is inside a new RA, the MT detects it by 1044 periodically comparing the RA identifier stored in its MM context 1045 with that just received from the new cell and initiates a RA update 1046 procedure with the SGSN. If the SGSN receiving the RA update request 1047 realizes that the old RA is not handled by itself, then it knows 1049 Yegin et. al. Expires April August 2004 1050 [Page 21] L2 Triggers and Hints February 2004 1052 that an inter-SGSN RA update is required. Necessary updates are 1053 performed in the GPRS Network Sub-System: 1055 - The new SGSN starts a handover procedure whereby it requests and 1056 receives the MM and PDP contexts from the old SGSN of the MT, before 1057 packet tunneling can start to the GGSN. 1058 - The MT location is updated in the network. 1060 A.1.1. Link-layer Information 1062 The MT initiates the RA update procedure by sending a "Routing Area 1063 Update Request" to the new SGSN. This is potentially an indication 1064 of 1065 an imminent SGSN change (GPRS Access Point). 1067 The network confirms that it has updated the RA (SGSN) by sending a 1068 "Routing Area Update Accept" to the MT. The MN can utilize this 1069 message as an indication that the MT's SGSN has changed following 1070 the handover procedure. 1072 The accept message comes along with an update of the MM context with 1073 new information as described below: 1075 - New P-TMSI 1076 - New Cell Identity 1077 - New RA Identity 1078 - New ciphering algorithm, key and sequence number 1080 A.2. Sub-link-layer Information 1082 Some of the information, such as the signal quality (e.g., channel's 1083 Bit Error Rate) and signal level, are not link-layer information but 1084 rather GPRS Radio Link Control (RLC) parameters. Nonetheless, their 1085 knowledge at the network-layer might be useful to assess the 1086 pertinence of deciding to attach in the case where their values are 1087 below the limits which are deemed necessary or required for the 1088 attachment. 1090 The RLC parameters corresponding to the two identified information 1091 are: 1093 - RXLEV, the received signal strength 1094 - RXQUAL, the received signal quality 1096 Yegin et. al. Expires April August 2004 1097 [Page 22] L2 Triggers and Hints February 2004 1099 Authors' Addresses 1101 Alper E. Yegin 1102 DoCoMo Communications Laboratories USA, Inc. 1103 181 Metro Drive, Suite 300 Phone: +1 408 451 4743 1104 San Jose, CA 95110 Fax: +1 408 451 1090 1105 USA email: alper@docomolabs-usa.com 1107 Eric Njedjou 1108 France Telecom R & D 1109 4, Rue du Clos Courtel BP 91226 Phone: +33 299124202 1110 35512 Cesson-S�vign� email: eric.njedjou@france-telecom.com 1111 France 1113 Siva Veerepalli 1114 Qualcomm, Incorporated. 1115 5775 Morehouse Drive Phone : +1 858 658 4628 1116 San Diego, CA 92131 Fax : +1 734 661 1812 1117 USA email : sivav@qualcomm.com 1119 Nicolas Montavont 1120 LSIIT - University Louis Pasteur Phone: (33) 390244587 1121 Pole API, bureau C430 email: montavont@dpt-info.u-strasbg.fr 1122 Boulevard Sebastien Brant URI: www-r2.u-strasbg.fr/~montavont 1123 Illkirch 67400 1124 France 1126 Thomas Noel 1127 LSIIT - University Louis Pasteur Phone: (33) 390244592 1128 Pole API, bureau C428 email: noel@dpt-info.u-strasbg.fr 1129 Boulevard Sebastien Brant URI: www-r2.u-strasbg.fr/~noel/ 1130 Illkirch 67400 1131 France 1133 Full Copyright Statement 1135 Copyright (C) The Internet Society (2004). All Rights Reserved. 1137 This document and translations of it may be copied and furnished 1138 to others, and derivative works that comment on or otherwise 1139 explain it or assist in its implementation may be prepared, copied, 1140 published and distributed, in whole or in part, without 1141 restriction of any kind, provided that the above copyright notice 1142 and this paragraph are included on all such copies and derivative 1143 works. However, this document itself may not be modified in any 1144 way, such as by removing the copyright notice or references to the 1145 Internet Society or other Internet organizations, except as needed 1146 for the purpose of developing Internet standards in which case the 1147 procedures for copyrights defined in the Internet Standards 1148 process must be followed, or as required to translate it into 1149 languages other than English. 1151 Yegin et. al. Expires April August 2004 1152 [Page 23] L2 Triggers and Hints February 2004 1154 The limited permissions granted above are perpetual and will not 1155 be revoked by the Internet Society or its successors or assigns. 1157 This document and the information contained herein is provided on 1158 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1159 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1160 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1161 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1162 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1164 Yegin et. al. Expires April August 2004