Seamoby Working Group S. Gurivireddy Internet Draft B. Sarikaya Document:draft-guri-seamoby-paging-triggers-00.txt Vinod Choyi Category: Informational Xiaofeng Xu Alcatel USA October 2001 Layer-2 API for Paging draft-guri-seamoby-paging-triggers-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. This is an individual draft for consideration by the Mobile IP Working Group. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Convention used in this draft The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Abstract: This draft defines a layer-2 API in C-language for IP paging. API is presented in the form of callback functions. Whenever a significant event takes place in layer-2, upper layers are notified using triggers, which can be implemented using callback functions. Network and upper layer protocols can use these callbacks to fine tune layer-3 protocols. Paging API defines callback functions for dormant mode related information, sent from layer-2 to layer-3. API also defines a set of attributes, which define static properties of the underlying network. Each layer-2 technology may use this hierarchy to specify its properties and limitations. Gurivireddy, et al. 1 Layer-2 API for Paging October 2001 Table of Contents: 1. Introduction 2. Basic structures used in API 2.1. Format of data types 2.2. Ipv4/Ipv6 addressing structure 2.3. Layer-2 address and paging area ID 2.4. Return codes 3. Paging API 3.1. MN paged 3.2. New paging area 3.3. New paging mode 3.4. Dormant Host reachable/ not reachable 4. Identified attributes 5. References 6. Authors' addresses 1. Introduction Link layer (L2 or layer 2) API for paging specifies the services, related to paging, provided by layer-2 to layer-3 in mobility networks. Layer-2 can serve upper layers by sending triggers to them during layer-2 paging events. Possible events in layer-2 are early notice of an upcoming change in the dormant mode status of mobile node [1] or the change in paging area of mobile node. This document defines an API for the services related to dormant mode provided by layer-2. Defining a layer-2 API for paging helps in writing standard layer-3 paging protocols. API is specified in 'C' language. API is a combination of attributes and triggers. The difference between attributes and triggers is that attributes are static information about the network, where as triggers carry dynamic information which depends on the current state of the network. API, discussed in this document, is defined for IPv6. A trigger MAY be implemented in many ways [1]. -A hardware interrupt MAY be an indication of event on layer- an application or protocol stack may catch this interrupt. -An operating system may provide a system call interface or a callback feature in device drivers for the applications to catch these triggers. -If this trigger information is available at one place in the network and if it's needed at some other entity or node, the information can be passed using an upper layer protocol. Gurivireddy, et al. Expires April 2002 2 Layer-2 API for Paging October 2001 Each trigger is characterized by its name, time when it occurs, to whom the trigger is delivered and the parameters included in the trigger. 2. Basic structures used in API Triggers are defined as callback functions. Applications register with these callback functions which in turn notify as soon as layer-2 trigger is fired. The trigger functions are blocking, in the sense the applications are blocked at the point they call these trigger API, until the trigger is fired. API assumes that characters are 8-bit wide and integers are 16-bit wide. Characters follow ASCII format. All the strings (or) array of characters used in API are standard null terminated 'C' strings. We used callbacks to define API. A library of callbacks can be defined, each representing one function of Layer-2 API. Concurrency in processing these triggers can easily be provided by using threads or processes. The data types of structure elements given in this draft are intended to be examples, not strict requirements. 2.1. Format of data types Primitive data types, used in this document, follow the POSIX format. E.g. uintN_t means an unsigned integer of exactly 'N' bits. 2.2. IPv6/IPv4 Address [3] For IPv6, layer-3 address is defined as struct in6_addr{ uint8_t s6_addr[16]; }; This data structure contains an array of sixteen 8-bit elements, which make up one 128-bit Ipv6 address. IPv6 address is stored in network byte order. For IPv4, layer-3 address is defined as struct in4_addr{ unit8_t s4_addr[4]; }; Typecast "network_addr" to the addressing structure, used in the system as follows: Gurivireddy, et al. Expires April 2002 3 Layer-2 API for Paging October 2001 #ifdef PF_INET6 typedef struct in6_addr struct network_addr; #endif #ifdef PF_INET4 typedef struct in4_addr struct network_addr; #endif 2.3 Layer-2 address and paging area ID struct l2_addr{ uint8_t link_addr[8]; } This structure assumes that the size of layer-2 address is 64 bits [EUI-64]. If a specific L2 has a different size it should be defined accordingly typedef uint8_t paging_area_ID API assumes that paging area ID is of size 64 bits. If the size of paging area ID is different, it should be changed accordingly. 2.4. Return codes A list of error codes, which may be returned by callbacks typedef enum { L2_TRIGGER_RETURN = 0, L2_TRIGGER_ERR_NOT_DEFINED = 1, L2_TRIGGER_ERR_SECURITY = 2, L2_TRIGGER_ERR_NOT_SUPPORTED = 3, L2_TRIGGER_ERR_CANNOT_REGISTER_HERE = 4, L2_TRIGGER_ERR_TIMED_OUT = 5, L2_TRIGGER_ERR_ALREADY_REGISTERED = 6, } L2APIReturnCode; The following is a description of the reasons when the error codes are returned. 2.4.1. L2_TRIGGER_RETURN: This code is returned if the trigger is successfully caught. 2.4.2. L2_TRIGGER_ERR_NOT_DEFINED: This code is returned when a function tries to register an undefined trigger. 2.4.3. L2_TRIGGER_ERR_SECURITY: This error is returned, if L2 prevents L3 from catching the trigger for security reasons Gurivireddy, et al. Expires April 2002 4 Layer-2 API for Paging October 2001 2.4.4. L2_ERR_NOT_SUPPORTED: This error code is returned when L3 tries to register a well-defined trigger, which is not supported by the underlying L2. 2.4.5. L2_TRIGGER_ERR_CANNOT_REGISTER_HERE: This error code is returned if the callback of trigger is not allowed at the place, this function was called. 2.4.6. L2_TRIGGER_TIMED_OUT: This error code is returned, if the trigger did not occur for certain amount of time after the callback was registered. L2 does not remember this callback any more. 2.4.7. L2_TRIGGER_ALREADY_REGISTERED: This error code is returned if an application has already registered this callback and if the same callback cannot be registered by two or more applications. 3. Paging API Triggers related to paging are introduced in an earlier Internet draft [4]. Paging API is defined to be used in layer-3 dormant mode host alerting protocol, based on the requirements document [2]. Though the API defined in this document is based on the triggers defined in [4], any layer 3 paging protocol can make use of these layer 2 triggers. 3.1. New paging area Layer 2 informs layer 3 at tracking agent[5] and mobile host whenever MN changes layer 2 paging area in dormant mode. This callback MUST be returned at layer 3 of tracking agent and mobile host. New paging area ID is replied back to the calling function. Callback function at MN is defined as Paging_Area_ID new_paging_area(L2APIReturnCode* code); Callback function at tracking agent is defined as Paging_Area_ID new_paging_area(L2_address* MN, L2APIReturnCode* code); 3.2. New paging mode Layer-3 at MN and AR MUST be informed by layer-2 whenever MN changes its mode (Dormant/Active/Inactive). If this trigger can be used then the paging registration messages can be avoided. Gurivireddy, et al. Expires April 2002 5 Layer-2 API for Paging October 2001 Callback at MN is defined as int new_paging_mode_trigger(L2APIReturnCode* code); Callback at tracking agent is defined as int new_paging_mode_trigger(L2_address* MN_address, L2APIReturnCode* code); MN's address is returned in the address referenced by MN_address. The return values of the callbacks are defined as 0 for dormant mode 1 for Active mode 2 for inactive mode 3.3. Dormant Host reachable Dormant host reachable trigger is sent to layer 3 of tracking agent when MN is paged and reply is received from MN. Callback function for this trigger is defined as void pagingReply((L2_address* MN, L2APIReturnCode* code); 3.4. Dormant Host not reachable Dormant host not reachable trigger is sent to layer 3 of tracking agent when MN is paged and no reply is received from MN within "MAX_PAGING_TIME". Callback function for this trigger is defined as void pagingTimeOut((L2_address* MN, L2APIReturnCode* code); 4. Attributes Attributes convey information about the behavioral properties of the network, such as their processing speed limitations, time taken to do specific tasks and the specific mechanisms they follow. They don't change with time. This document defines a set of attributes related to paging. Attributes are not for managing the network; instead, they define the properties of the network. Layer-3 can get a rough idea of limitations and properties of the layer-2 from these attributes. The work related to defining the attribute is incomplete and only basic set of attributes is defined in this draft. 4.1. Identified attributes 4.1.1. SUPPORT_FOR_DORMANT_MODE (1) -1 if the layer-2 has support for paging. -0 otherwise 4.1.2. MAX_PAGING_TIME (2) Gurivireddy, et al. Expires April 2002 6 Layer-2 API for Paging October 2001 This field is represented in microseconds. 4.1.3. PAGING_TYPE (3) -0 if it uses time slotted paging -1 Otherwise i.e. if paging can be done at any time 4.1.4. SUPPORT_FOR_BROADCAST_PAGING -0 if MN requires a dedicated channel for paging -1 Otherwise i.e. MN can also respond to broadcast paging 4.2. API for accessing attributes char* get_L2_attrribute(int id); The ID of the attribute should be as argument to the callback function. The manner in which these attributes are stored is out of scope of this document. They MAY typically be stored in a file sequentially one after the other. 5. References 1. James Kempf et al. "Bidirectional Edge Tunnel Handover for IPv6", draft-kempf-beth-ipv6-02.txt, June 2001, work-in- progress. 2. James Kempf et al. "Requirements for Layer 2 Protocols to Support Optimized Handover for IP Mobility", draft-manyfolks- l2-mobilereq-00.txt, July 2001, work-in-progress. 3. R.Gilligan et al. "Basic Socket Interface Extensions for Ipv6, RFC 2113, March, 1999. 4. S.Gurivireddy et al. "Layer-2 aided mobility independent dormant host alerting protocol", September 2001. 5. James Kempf, "Requirements and Functional Architecture for an IP Host Alerting Protocol", RFC 3154, August 2001. 6. Author's addresses The working group can be contacted via the current chairs: Pat R. Calhoun Black Storm Networks 250 Cambridge Avenue Suite 200 Palo Alto, CA 94306 USA Tel. 1-650-617-2932 Email: pcalhoun@btormnetworks.com James Kempf DoCoMo Communications Gurivireddy, et al. Expires April 2002 7 Layer-2 API for Paging October 2001 Laboratories USA, Inc. 181 Metro Drive, Suite 300 Phone: +1 408 451 San Jose, CA 95110 Fax: +1 408 573 1090 USA Email: Questions about the memo can be directed to Sridhar Gurivireddy, Network Strategic Group, Mobile Networking team Alcatel USA 1201 E.Campbell Rd. Richardson, TX 75081-1536 USA E-mail: sridhar.gurivireddy@alcatel.com Phone: (972) 996.2048 Behcet Sarikaya, Network Strategic Group, Mobile Networking team Alcatel USA 1201 E.Campbell Rd. Richardson, TX 75081-1536 USA E-mail: behcet.sarikaya@alcatel.com Phone: (972) 996.5075 Vinod Choyi Network Strategic Group, Mobile Networking team Alcatel USA 1201 E.Campbell Rd. Richardson, TX 75081-1536 USA E-mail: vinod.choyi@alcatel.com Phone: (972) 996.2788 Xiafeng Xu Network Strategic Group, Mobile Networking team Alcatel USA 1201 E.Campbell Rd. Richardson, TX 75081-1536 USA E-mail: xiaofeng.xu@alcatel.com Phone: (972) 996.2047 Gurivireddy, et al. Expires April 2002 8