[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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