Internet DRAFT - draft-guri-seamoby-paging-triggers
draft-guri-seamoby-paging-triggers
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
