idnits 2.17.1 draft-guri-seamoby-paging-triggers-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** 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.) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (October 2001) is 8222 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 95 looks like a reference -- Missing reference section? '3' on line 141 looks like a reference -- Missing reference section? '16' on line 146 looks like a reference -- Missing reference section? '4' on line 244 looks like a reference -- Missing reference section? '8' on line 176 looks like a reference -- Missing reference section? 'EUI-64' on line 179 looks like a reference -- Missing reference section? '2' on line 243 looks like a reference -- Missing reference section? '5' on line 249 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Seamoby Working Group S. Gurivireddy 3 Internet Draft B. Sarikaya 4 Document:draft-guri-seamoby-paging-triggers-00.txt Vinod Choyi 5 Category: Informational Xiaofeng Xu 6 Alcatel USA 7 October 2001 9 Layer-2 API for Paging 10 draft-guri-seamoby-paging-triggers-00.txt 12 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC 2026. This is an 15 individual draft for consideration by the Mobile IP Working 16 Group. 18 Internet Drafts are working documents of the Internet 19 Engineering Task Force (IETF), its areas and its working 20 groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by 25 other documents at any time. It is inappropriate to use 26 Internet-Drafts as reference material or to cite them other 27 than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed 32 at http://www.ietf.org/shadow.html 34 Convention used in this draft 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 37 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 38 "OPTIONAL" in this document are to be interpreted as 39 described in RFC-2119. 41 Abstract: 43 This draft defines a layer-2 API in C-language for IP paging. 44 API is presented in the form of callback functions. Whenever 45 a significant event takes place in layer-2, upper layers are 46 notified using triggers, which can be implemented using 47 callback functions. Network and upper layer protocols can use 48 these callbacks to fine tune layer-3 protocols. Paging API 49 defines callback functions for dormant mode related 50 information, sent from layer-2 to layer-3. API also defines a 51 set of attributes, which define static properties of the 52 underlying network. Each layer-2 technology may use this 53 hierarchy to specify its properties and limitations. 55 Gurivireddy, et al. 1 56 Layer-2 API for Paging October 2001 58 Table of Contents: 60 1. Introduction 61 2. Basic structures used in API 62 2.1. Format of data types 63 2.2. Ipv4/Ipv6 addressing structure 64 2.3. Layer-2 address and paging area ID 65 2.4. Return codes 66 3. Paging API 67 3.1. MN paged 68 3.2. New paging area 69 3.3. New paging mode 70 3.4. Dormant Host reachable/ not reachable 71 4. Identified attributes 72 5. References 73 6. Authors' addresses 75 1. Introduction 77 Link layer (L2 or layer 2) API for paging specifies the 78 services, related to paging, provided by layer-2 to layer-3 79 in mobility networks. Layer-2 can serve upper layers by 80 sending triggers to them during layer-2 paging events. 81 Possible events in layer-2 are early notice of an upcoming 82 change in the dormant mode status of mobile node [1] or the 83 change in paging area of mobile node. This document defines 84 an API for the services related to dormant mode provided by 85 layer-2. Defining a layer-2 API for paging helps in writing 86 standard layer-3 paging protocols. 88 API is specified in 'C' language. API is a combination of 89 attributes and triggers. The difference between attributes 90 and triggers is that attributes are static information about 91 the network, where as triggers carry dynamic information 92 which depends on the current state of the network. API, 93 discussed in this document, is defined for IPv6. 95 A trigger MAY be implemented in many ways [1]. 97 -A hardware interrupt MAY be an indication of event on 98 layer- an application or protocol stack may catch this 99 interrupt. 101 -An operating system may provide a system call interface or a 102 callback feature in device drivers for the applications to 103 catch these triggers. 105 -If this trigger information is available at one place in the 106 network and if it's needed at some other entity or node, the 107 information can be passed using an upper layer protocol. 109 Gurivireddy, et al. Expires April 2002 2 110 Layer-2 API for Paging October 2001 112 Each trigger is characterized by its name, time when it 113 occurs, to whom the trigger is delivered and the parameters 114 included in the trigger. 116 2. Basic structures used in API 118 Triggers are defined as callback functions. Applications 119 register with these callback functions which in turn notify 120 as soon as layer-2 trigger is fired. The trigger functions 121 are blocking, in the sense the applications are blocked at 122 the point they call these trigger API, until the trigger is 123 fired. 125 API assumes that characters are 8-bit wide and integers are 126 16-bit wide. Characters follow ASCII format. All the strings 127 (or) array of characters used in API are standard null 128 terminated 'C' strings. We used callbacks to define API. A 129 library of callbacks can be defined, each representing one 130 function of Layer-2 API. Concurrency in processing these 131 triggers can easily be provided by using threads or 132 processes. The data types of structure elements given in this 133 draft are intended to be examples, not strict requirements. 135 2.1. Format of data types 137 Primitive data types, used in this document, follow the POSIX 138 format. E.g. uintN_t means an unsigned integer of exactly 'N' 139 bits. 141 2.2. IPv6/IPv4 Address [3] 143 For IPv6, layer-3 address is defined as 145 struct in6_addr{ 146 uint8_t s6_addr[16]; 147 }; 149 This data structure contains an array of sixteen 8-bit 150 elements, which make up one 128-bit Ipv6 address. IPv6 151 address is stored in network byte order. 153 For IPv4, layer-3 address is defined as 155 struct in4_addr{ 156 unit8_t s4_addr[4]; 157 }; 159 Typecast "network_addr" to the addressing structure, used in 160 the system as follows: 162 Gurivireddy, et al. Expires April 2002 3 163 Layer-2 API for Paging October 2001 165 #ifdef PF_INET6 166 typedef struct in6_addr struct network_addr; 167 #endif 169 #ifdef PF_INET4 170 typedef struct in4_addr struct network_addr; 171 #endif 173 2.3 Layer-2 address and paging area ID 175 struct l2_addr{ 176 uint8_t link_addr[8]; 177 } 178 This structure assumes that the size of layer-2 address is 64 179 bits [EUI-64]. If a specific L2 has a different size it 180 should be defined accordingly 182 typedef uint8_t paging_area_ID 183 API assumes that paging area ID is of size 64 bits. If the 184 size of paging area ID is different, it should be changed 185 accordingly. 187 2.4. Return codes 189 A list of error codes, which may be returned by callbacks 191 typedef enum 192 { 193 L2_TRIGGER_RETURN = 0, 194 L2_TRIGGER_ERR_NOT_DEFINED = 1, 195 L2_TRIGGER_ERR_SECURITY = 2, 196 L2_TRIGGER_ERR_NOT_SUPPORTED = 3, 197 L2_TRIGGER_ERR_CANNOT_REGISTER_HERE = 4, 198 L2_TRIGGER_ERR_TIMED_OUT = 5, 199 L2_TRIGGER_ERR_ALREADY_REGISTERED = 6, 200 } L2APIReturnCode; 202 The following is a description of the reasons when the error 203 codes are returned. 205 2.4.1. L2_TRIGGER_RETURN: 206 This code is returned if the trigger is successfully caught. 208 2.4.2. L2_TRIGGER_ERR_NOT_DEFINED: 209 This code is returned when a function tries to register an 210 undefined trigger. 212 2.4.3. L2_TRIGGER_ERR_SECURITY: 213 This error is returned, if L2 prevents L3 from catching the 214 trigger for security reasons 216 Gurivireddy, et al. Expires April 2002 4 217 Layer-2 API for Paging October 2001 219 2.4.4. L2_ERR_NOT_SUPPORTED: 220 This error code is returned when L3 tries to register a 221 well-defined trigger, which is not supported by the 222 underlying L2. 224 2.4.5. L2_TRIGGER_ERR_CANNOT_REGISTER_HERE: 225 This error code is returned if the callback of trigger is 226 not allowed at the place, this function was called. 228 2.4.6. L2_TRIGGER_TIMED_OUT: 229 This error code is returned, if the trigger did not occur for 230 certain amount of time after the callback was registered. L2 231 does not remember this callback any more. 233 2.4.7. L2_TRIGGER_ALREADY_REGISTERED: 234 This error code is returned if an application has already 235 registered this callback and if the same callback cannot be 236 registered by two or more applications. 238 3. Paging API 240 Triggers related to paging are introduced in an earlier 241 Internet draft [4]. Paging API is defined to be used in 242 layer-3 dormant mode host alerting protocol, based on the 243 requirements document [2]. Though the API defined in this 244 document is based on the triggers defined in [4], any layer 3 245 paging protocol can make use of these layer 2 triggers. 247 3.1. New paging area 249 Layer 2 informs layer 3 at tracking agent[5] and mobile host 250 whenever MN changes layer 2 paging area in dormant mode. This 251 callback MUST be returned at layer 3 of tracking agent and 252 mobile host. New paging area ID is replied back to the 253 calling function. 255 Callback function at MN is defined as 256 Paging_Area_ID new_paging_area(L2APIReturnCode* code); 258 Callback function at tracking agent is defined as 259 Paging_Area_ID new_paging_area(L2_address* MN, 260 L2APIReturnCode* code); 262 3.2. New paging mode 264 Layer-3 at MN and AR MUST be informed by layer-2 whenever MN 265 changes its mode (Dormant/Active/Inactive). If this trigger 266 can be used then the paging registration messages can be 267 avoided. 269 Gurivireddy, et al. Expires April 2002 5 270 Layer-2 API for Paging October 2001 272 Callback at MN is defined as 273 int new_paging_mode_trigger(L2APIReturnCode* code); 275 Callback at tracking agent is defined as 276 int new_paging_mode_trigger(L2_address* MN_address, 277 L2APIReturnCode* code); 279 MN's address is returned in the address referenced by 280 MN_address. The return values of the callbacks are defined as 281 0 for dormant mode 282 1 for Active mode 283 2 for inactive mode 285 3.3. Dormant Host reachable 287 Dormant host reachable trigger is sent to layer 3 of tracking 288 agent when MN is paged and reply is received from MN. 290 Callback function for this trigger is defined as 291 void pagingReply((L2_address* MN, L2APIReturnCode* code); 293 3.4. Dormant Host not reachable 295 Dormant host not reachable trigger is sent to layer 3 of 296 tracking agent when MN is paged and no reply is received from 297 MN within "MAX_PAGING_TIME". 299 Callback function for this trigger is defined as 300 void pagingTimeOut((L2_address* MN, L2APIReturnCode* code); 302 4. Attributes 304 Attributes convey information about the behavioral properties 305 of the network, such as their processing speed limitations, 306 time taken to do specific tasks and the specific mechanisms 307 they follow. They don't change with time. This document 308 defines a set of attributes related to paging. Attributes are 309 not for managing the network; instead, they define the 310 properties of the network. Layer-3 can get a rough idea of 311 limitations and properties of the layer-2 from these 312 attributes. 314 The work related to defining the attribute is incomplete and 315 only basic set of attributes is defined in this draft. 317 4.1. Identified attributes 319 4.1.1. SUPPORT_FOR_DORMANT_MODE (1) 320 -1 if the layer-2 has support for paging. 321 -0 otherwise 322 4.1.2. MAX_PAGING_TIME (2) 324 Gurivireddy, et al. Expires April 2002 6 325 Layer-2 API for Paging October 2001 327 This field is represented in microseconds. 328 4.1.3. PAGING_TYPE (3) 329 -0 if it uses time slotted paging 330 -1 Otherwise i.e. if paging can be done at any time 331 4.1.4. SUPPORT_FOR_BROADCAST_PAGING 332 -0 if MN requires a dedicated channel for paging 333 -1 Otherwise i.e. MN can also respond to broadcast paging 335 4.2. API for accessing attributes 337 char* get_L2_attrribute(int id); 339 The ID of the attribute should be as argument to the callback 340 function. The manner in which these attributes are stored is 341 out of scope of this document. They MAY typically be stored 342 in a file sequentially one after the other. 344 5. References 346 1. James Kempf et al. "Bidirectional Edge Tunnel Handover for 347 IPv6", draft-kempf-beth-ipv6-02.txt, June 2001, work-in- 348 progress. 350 2. James Kempf et al. "Requirements for Layer 2 Protocols to 351 Support Optimized Handover for IP Mobility", draft-manyfolks- 352 l2-mobilereq-00.txt, July 2001, work-in-progress. 354 3. R.Gilligan et al. "Basic Socket Interface Extensions for 355 Ipv6, RFC 2113, March, 1999. 357 4. S.Gurivireddy et al. "Layer-2 aided mobility independent 358 dormant host alerting protocol", September 2001. 360 5. James Kempf, "Requirements and Functional Architecture for 361 an IP Host Alerting Protocol", RFC 3154, August 2001. 363 6. Author's addresses 364 The working group can be contacted via the current chairs: 365 Pat R. Calhoun 366 Black Storm Networks 367 250 Cambridge Avenue 368 Suite 200 369 Palo Alto, CA 94306 370 USA 371 Tel. 1-650-617-2932 372 Email: pcalhoun@btormnetworks.com 374 James Kempf 375 DoCoMo Communications 377 Gurivireddy, et al. Expires April 2002 7 378 Layer-2 API for Paging October 2001 380 Laboratories USA, Inc. 381 181 Metro Drive, Suite 300 Phone: +1 408 451 382 San Jose, CA 95110 Fax: +1 408 573 1090 383 USA Email: 384 Questions about the memo can be directed to 386 Sridhar Gurivireddy, 387 Network Strategic Group, Mobile Networking team 388 Alcatel USA 389 1201 E.Campbell Rd. 390 Richardson, TX 75081-1536 USA 391 E-mail: sridhar.gurivireddy@alcatel.com 392 Phone: (972) 996.2048 394 Behcet Sarikaya, 395 Network Strategic Group, Mobile Networking team 396 Alcatel USA 397 1201 E.Campbell Rd. 398 Richardson, TX 75081-1536 USA 399 E-mail: behcet.sarikaya@alcatel.com 400 Phone: (972) 996.5075 402 Vinod Choyi 403 Network Strategic Group, Mobile Networking team 404 Alcatel USA 405 1201 E.Campbell Rd. 406 Richardson, TX 75081-1536 USA 407 E-mail: vinod.choyi@alcatel.com 408 Phone: (972) 996.2788 410 Xiafeng Xu 411 Network Strategic Group, Mobile Networking team 412 Alcatel USA 413 1201 E.Campbell Rd. 414 Richardson, TX 75081-1536 USA 415 E-mail: xiaofeng.xu@alcatel.com 416 Phone: (972) 996.2047 418 Gurivireddy, et al. Expires April 2002 8