Network Working Group Request for Comments: DRAFT - Release 0.3 Category: Informational November, 1* *999 Location & Status Notification Services (LSNS) for Mobile Devices in the Wireless Data & Voice Networks Contents 1 Introduction * * 3 1.1 General Use of Status Notification and Location Information . . . . . .* * . . . . . . . . . . . 4 1.1.1 General Model for Status Notification . . . . . . . . . . . . . .* * . . . . . . . . . . . 4 1.2 Common Scenarios for using LSNS . . . . . . . . . . . . . . . . . . . .* * . . . . . . . . . . 6 1.3 Requirements for LSNS . . . . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . 8 1.4 Messaging Examples for LSNS . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . 9 1.5 General Usage Characteristics . . . . . . . . . . . . . . . . . . . . .* * . . . . . . . . . . . . 11 1.6 Scope Of This Specification . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . . 11 2 Status Notification Service Overview * * 11 2.1 Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .* * . . . . . . . . . . . . . 12 2.2 Use of ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . . 13 2.3 LSNS Basic Subprofile . . . . . . . . . . . . . . . . . . . . . . . . .* * . . . . . . . . . . . . 13 2.3.1 Encoding Rules . . . . . . . . . . . . . . . . . . . . . . . . .* * . . . . . . . . . . . 13 2.3.2 Use of ESROS . . . . . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . 14 2.3.3 Use of UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . .* * . . . . . . . . . . . 14 3 Use Of LSNS Protocols * * 14 3.1 Corresponding End Systems: . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . 14 3.2 Mobile End Systems . . . . . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . 14 4 Generalized LSNS Protocol * * 15 4.1 LSNS Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . . 15 4.2 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .* * . . . . . . . . . . . . . 15 4.2.1 Status Query . . . . . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . 15 4.2.2 Status Notification Request . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . 17 4.2.3 Status Notification Report . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . 19 4.2.4 Desire to Communicate Request . . . . . . . . . . . . . . . . . .* * . . . . . . . . . . 19 4.2.5 Desire to Communicate Notification . . . . . . . . . . . . . . . * *. . . . . . . . . . . 21 4.3 LSNS Common Information Objects . . . . . . . . . . . . . . . . . . . .* * . . . . . . . . . . 21 4.3.1 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . . 22 4.3.2 DateTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . 22 4.3.3 AsciiPrintableString . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . 22 4.3.4 UpperBounds . . . . . . . . . . . . . . . . . . . . . . . . . . .* * . . . . . . . . . . . 23 5 Implementation Considerations * * 23 5.1 General System Model . . . . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . 23 RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 A Applying LSNS to the CDPD Network * * 25 A.1 CDPD LSNS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . 25 A.2 LSNS Procedures For The CDPD Network . . . . . . . . . . . . . . . . .* * . . . . . . . . . 28 A.2.1 Invoking statusNotificationRequest by the C-ES . . . . . . . . . .* * . . . . . . . . . . 28 A.2.2 Performing statusNotificationRequest by the LSNS . . . . . . . . * *. . . . . . . . . . 28 A.2.3 Invoking statusNotificationReport by the LSNS (going active) . . * *. . . . . . . . . . 28 A.2.4 Invoking statusNotificationReport by the LSNS (going inactive) . * *. . . . . . . . . . 32 A.2.5 Performing statusNotificationReport Procedures . . . . . . . . .* * . . . . . . . . . . 32 B Applying LSNS to the Cellular Voice Network * * 32 C Abbreviations * * 32 List of Figures 1 Location & Status Notification Service Architecture . . . . . . . . . .* * . . . . . . . . . . . . 5 2 Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . . . 7 3 Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . . . 8 4 Example of Messaging to an OC-ES . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . 9 5 Another Example of Messaging to an OC-ES . . . . . . . . . . . . . . . * *. . . . . . . . . . 10 6 LSNS Interfaces and Protocols - (b) and (d) are of our interest. . . . * *. . . . . . . . . . . . . 12 7 System Model Block Diagram . . . . . . . . . . . . . . . . . . . . . . * *. . . . . . . . . . . 24 8 Detailed interface diagram for the CDPD LSNS Network . . . . . . . . . * *. . . . . . . . . . 26 9 Modifications Required for LSNS . . . . . . . . . . . . . . . . . . . .* * . . . . . . . . . . . 27 10 Modifications Required for LSNS with desireToCommunicate . . . . . . . * *. . . . . . . . . 27 11 C-ES invoking statusNotificationRequest . . . . . . . . . . . . . . . . * *. . . . . . . . . . . . 29 12 LSNS performing statusNotificationRequest . . . . . . . . . . . . . . .* * . . . . . . . . . . . 30 13 LSNS invoking statusNotificationReport, going active . . . . . . . . . .* * . . . . . . . . . . . 31 14 LSNS invoking statusNotificationReport, going inactive . . . . . . . . .* * . . . . . . . . . . . 33 15 C-ES performing statusNotificationReport . . . . . . . . . . . . . . . * *. . . . . . . . . . . . 34 List of Tables 1 Invoked and Performed Operations by the LSNS, C-ES, and M-ES . . . . . * *. . . . . . . . . 15 Informational [P* *age 2] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 STATUS OF THIS MEMO This memo provides information for the Internet community. It does not specify * *an Internet standard of any kind. Distribution of this memo is unlimited. This document is being prepared by Neda Communications, Inc. for Xypoint Corpor* *ation based on matterial previously prepared by Neda. Known Deficiencies This document is mostly complete and is subject to review and criticism. Features which have not been fully developed and described in this revision of * *the document include: fflThe location reporting features are preliminary. fflThe Cellular Voice Network specific features are incomplete. fflThe ASN.1 specification of the protocol has not been machine verified. 1 Introduction In wireless data & voice networks, many of the Mobile End Systems (M-ESs) may b* *e unavailable at any given time. There are two main reasons for this: 1.User's choice of not having his/her device connected to the network. 2.Unavailability of service (e.g. in an airplane). Current methods for dealing with the transient nature of M-ESs involve periodic* * polling or repeated attempts to deliver a message to a recipient which might be unavailable, and these are c* *ostly in network traffic and delivery delays. The occasionally connected nature of M-ESs introduces the challenge of deliveri* *ng information to the devices in a timely and efficient manner. Existing solutions to this problem are genera* *lly inefficient. We attempt to address this problem in an efficient and timely manner by introducing the Loact* *ion & Status Notification Service (LSNS), where the current status (active/inactive) and the general loca* *tion of the M-ES is determined and communicated to those parties which should be provided access to such infor* *mation. LSNS allows the state and the general location of the intended recipient to be * *known, and for notification of changes of that status. This allows messages to be sent only when the recipi* *ent is available, and quick delivery of pending messages when an M-ES becomes available. The status and general location of an M-ES is sensitive information subject to * *privacy restrictions which should be under the control of the M-ES owner. For this reason, control of acce* *ss to this information is an integral part of this document. Informational [P* *age 3] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Basic concept and capabilities of LSNS are relevant to networks which support m* *obility. Such mobile and wireless networks include CDPD, Mobile-IP and the cellular voice network. 1.1 General Use of Status Notification and Location Information In the traditional information exchange model the originator of information ass* *umes that the recipient is ready and willing to accept the information. The introduction of occasionally-connect* *ed devices which are often disconnected from the network invalidates this assumption because the occasiona* *lly-connected devices are often not available for information exchange. Attempting to communicate with an occasionally-connected device suffers from th* *e inherent problems of efficient and timely notification of the availability and desire of the communi* *cating parties. The originator needs to know whether or not the intended (occasionally-connected) recipient wi* *ll be likely to successfully receive the data. Similarly the recipient needs to know about the originator's * *intent to transmit data to it. Most networks supporting mobility have end systems which are only occasionally * *connected. The problem of end system status notification is particularly relevant in these networks. In local area networks (LANs) and high bandwidth networks the problem of end sy* *stem status notification is insignificant because a failed attempt to transmit data between end systems is * *inexpensive in terms of resource conception. However, in wide area networks (WAN) environments, a failed data tr* *ansmission is much more costly in terms of resource consumption and thus the problem of status notifica* *tion is quite significant. Both device and network performance is greatly enhanced if the originator knows* * the current status (e.g., reachable or unreachable) of the occasionally-connected recipient and if the oc* *casionally-connected recipient knows that the originator desires communication with it. This service provides * *a mechanism by which each of the communicating parties is efficiently notified about the status of its co* *mmunications peer. 1.1.1 General Model for Status Notification In the most general case, a corresponding end system (C-ES) communicates with a* *n occasionally-connected end system (OC-ES) using information provided by the Location & Status Notifica* *tion Service (LSNS). A corresponding end system may be any system other than the originating end syste* *m (O-ES). An example of a corresponding end system would be a mail server which is always available and* * which can communicate to OC-ES on behalf of the originating end system (i.e., sender of e-mail). Traditional application layer (layer 7 of OSI Reference Model) associations are* * bi-lateral. To make commu- nication with occasionally connected end systems more efficient, this system in* *troduces a tri-lateral commu- nication model. We introduce a Status Notification Service that facilitates com* *munication with occasionally connected end systems. The status notification service can contain information * *regarding the status of OC-ES and can inform the C-ES as soon as the OC-ES becomes reachable. The status noti* *fication server can contain information regarding the C-ES's desire to communicate while the OC-ES was unre* *achable and can inform the OC-ES as soon as it becomes reachable. The crux of the status notification problem, and of this service, lies in the c* *ommunication between the C-ES and the OC-ES. If the C-ES is unaware of the availability, location and recepti* *veness of the OC-ES, it must either wait for a poll from the OC-ES or broadcast the fact that it desires to * *communicate with the OC-ES. Informational [P* *age 4] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Figure 1: Location & Status Notification Service Architecture Informational [P* *age 5] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Similarly, if the OC-ES is unaware of the C-ES's desire to communicate with it,* * it must either poll the C-ES or await a broadcast by the C-ES indicating a desire to communicate with the OC* *-ES. However, if a Location & Status Notification Service (LSNS) is available which * *always knows the current state of the OC-ES, it could be used to enable efficient communication between * *the C-ES and the OC-ES. Two basic mechanisms to accomplish this are provided by this service. Both of t* *hese mechanisms involve the establishment of an association at the application layer between the C-ES a* *nd the LSNS. This association provides the means by which the LSNS informs the C-ES about the status of the O* *C-ES. It likewise provides the means by which the C-ES notifies the LSNS of its desire to communicate with* * the OC-ES. Mechanism 1: Whenever the OC-ES changes state, the LSNS notifies the C-ES of th* *is event. A state change could involve the availability of the OC-ES, the ability of the OC-ES to commun* *icate (with the C-ES), etc. Based on its knowledge of the OC-ES (which it receives from the LSNS), the C-ES* * may initiate, terminate or continue an application layer association with the OC-ES. This mechanism is ill* *ustrated in Figure 1, Figure 2, and Figure 4. Mechanism 2: Whenever the C-ES receives data destined for the OC-ES, it notifie* *s the LSNS of its desire to communicate with the OC-ES. When the OC-ES becomes available, the LSNS notif* *ies it of the C-ES's desire to communicate. The OC-ES then establishes an application layer associa* *tion with the C-ES for communication. This mechanism is illustrated in Figure 3 and Figure 5. The Status Notification Service includes the application layer association betw* *een the C-ES and the LSNS by which the C-ES is notified of the status of the OC-ES and the desire of the * *C-ES to communicate with the OC-ES. This service provides the means for efficient communication with occ* *asionally-connected end systems. 1.2 Common Scenarios for using LSNS Scenario 1: C-ES initiates association with OC-ES when the OC-ES becomes reacha* *ble. Figure 2 depicts the relationships between the LSNS, the C-ES and the OC-ES. The line connecting* * the LSNS and the C-ES represents application layer association between these entities. The dashed lin* *e connecting the LSNS and the OC-ES - going through the network which supports the OC-ES - represents communi* *cation between these entities. The line connecting the C-ES and the OC-ES represents the application* * layer association between these entities. It exists for the duration of the data transmission between the* *se devices. The following time sequence scenario is depicted in Figure 2. 1.C-ES attempts to communicate with OC-ES. The association fails because the* * OC-ES is unreachable. 2.C-ES requests from LSNS to be notified of the OC-ES status. This may have * *a number of parameters associated with it, including a "duration of interest" period. 3.The OC-ES becomes reachable. This in turn triggers a number of internal ne* *twork events resulting into notification to the LSNS of the OC-ES's reachable status. 4.The LSNS notifies the C-ES of the now reachable status of the OC-ES. 5.The C-ES uses this information to establish an association with the OC-ES. Informational [P* *age 6] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Figure 2: Scenario 1 Informational [P* *age 7] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Figure 3: Scenario 2 Scenario 2: The OC-ES initiates the association. Refer to Figure 3 which, as i* *n Figure 1.2, depicts the relationships between the LSNS, the C-ES and the OC-ES. The following time sequence scenario is depicted in Figure 3. 1.C-ES attempts to communicate with OC-ES. The association fails because the* * OC-ES is unreachable. 2.C-ES communicates to LSNS its desire to communicate with the OC-ES. This m* *ay have a number of parameters associated with it, including a "duration of interest" period. 3.The OC-ES becomes reachable. This in turn triggers a number of internal ne* *twork events resulting into notification to the LSNS of the OC-ES's reachable status 4.The LSNS notifies the OC-ES of the C-ES's desire to communicate with the O* *C-ES. 5.The OC-ES uses this information to establish an association with the C-ES. 1.3 Requirements for LSNS The requirements which must be met by a Status Notification Service include: 1.LSNS is an optional service which applications may take advantage of. Informational [P* *age 8] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Figure 4: Example of Messaging to an OC-ES 2.Allow a C-ES to determine the current status of one or more M-ES entities * *in a quick and efficient manner. 3.Allow a C-ES to request notification when one or more M-ES entities change* * status, either becoming active and eligible for communication or inactive and unavailable. 4.Provide status change notifications to the C-ES entities which have reques* *ted notification. 5.Timely and reliable delivery of status change notifications, as this direc* *tly affects the quality of service when a C-ES is waiting. 6.Provide notification to an M-ES that a C-ES desires to communicate with it* *. This is to allow the M-ES to initiate communications at its option. 7.Location tracking. Capabilities specifically not included in a Status Notification Service include: 1.Guarantee of device accessibility. 1.4 Messaging Examples for LSNS The first mechanism supporting C-ES communication with the OC-ES can be applied* * to messaging (e.g., email) applications. The steps involved in sending an e-mail message from an or* *iginator to a recipient OC- ES via a message-delivery-system (C-ES), are identified in Figure 4. The following time sequence scenario is depicted in Figure 4. Informational [P* *age 9] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Figure 5: Another Example of Messaging to an OC-ES 1.The message originator sends a message which arrives at the recipient's me* *ssage-delivery-system (i.e., mail-box). The message-delivery-system attempts to deliver the message to * *the recipient but the asso- ciation between the C-ES (message-delivery-system) and OC-ES (Message Reci* *pient) fails. 2.The message-delivery-system (C-ES) requests from the LSNS to be notified o* *f the Message Recipient's status. Note that this step could either precede or follow Step 1. 3.The OC-ES becomes reachable. The LSNS notifies the C-ES of the OC-ES's rea* *chable status. 4.The C-ES uses this information to send the message to its recipient (OC-ES* *). The second mechanism supporting communication between a C-ES and an OC-ES can a* *lso be applied to messaging applications. The steps involved in sending an e-mail message from an* * originator to a recipient OC-ES, via a mailbox (C-ES), are identified in Figure 5. The following time sequence scenario is depicted in Figure 5. 1.The message originator sends a message which arrives at the recipients mes* *sage-delivery-system. The message-delivery-system attempts to deliver the message to the recipient b* *ut the association between the C-ES (mail-box) and OC-ES (Message Recipient) fails. 2.The message-delivery-system (C-ES) communicates to LSNS its desire to comm* *unicate with the Mes- sage recipient (OC-ES). Note that this step could either precede or follow* * Step 1. 3.The OC-ES becomes reachable. The LSNS notifies the Message Recipient (OC-E* *S) of the message- delivery-system's (C-ES) desire to communicate. Informational [Pa* *ge 10] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 4.The Message Recipient (OC-ES) uses this information to retrieve its messag* *e. 1.5 General Usage Characteristics Use of the LSNS service generally revolves around the following key concepts: fflThe Status Notification Server always knows when a device is registered o* *n the network. fflThe Status Notification Server can notify different applications of the s* *tatus (active or non-active) of an Occasionally Connected End System. fflCorresponding End-Systems (e.g. Message Centers) and many other applicati* *ons can operate more efficiently if they know when an Occasionally Connected End-System (e.g. a* * mobile unit) is registered and ready. fflAdditionally, the Status Notification Server can notify an Occasionally C* *onnected System of an appli- cation's desire to communicate. 1.6 Scope Of This Specification The specification outlined in this document defines the protocol between the St* *atus Notification Service, the Corresponding End System, and the Occasionally Connected System. The protocol w* *ill be based on the Efficient Short Remote Operation Services (see [4]). This chapter has presented an introduction to the main ideas of status notifica* *tion. Chapter 2 provides an overview of the LSNS protocol. Network specific aspects of the protocol are included as attachments to the doc* *ument. 2 Status Notification Service Overview An overview of the Status Notification Service for a Wireless Data & Voice netw* *ork, and the various interface protocols (which make use of ASN.1 and Basic Encoding Rules) are shown in Figur* *e 6. The annotations for Figure 6 are: a.Registration Reporting Protocol (RRP). This could be an Application Progra* *mming Interface (API) or a protocol. b.Mobile Status Notification Protocol (MSNP). This is an operation oriented * *protocol which will be connection-less. It can also be used to ask the Status Notification Servic* *e to notify the Mobile System about the need to poll the Message Center. c.API to provide access to MSNP. d.Application Information Notification to the Mobile Protocol (AINMP). Informational [Pa* *ge 11] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Figure 6: LSNS Interfaces and Protocols - (b) and (d) are of our * *interest. e.API for (4). f.Mobile Network Registration Protocol (MNRP). This document will focus on the global protocols between the LSNS and the Corre* *sponding and Occasionally Connected End Systems, i.e., protocols (b) and (d) in Figure 6. These protocols* * will make use of the Efficient Short Remote Operation Services as outlined in [4]. Interfaces (a), (c), and (e* *), are internal to the LSNS, C-ES, and OC-ES and beyond the scope of the specifications in this document. 2.1 Elements Primary elements of the LSNS system are those highlighted in Figure 6. These co* *mprise: fflAn Occasionally-Connected End System - also called a Mobile End Systems (* *M-ES). Informational [Pa* *ge 12] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 fflThe Network Agent for Location and Status (NALS) , which is the M-ES's an* *chor in the network and is always aware of M-ES's status. The Status Notification Agent may be rea* *lized as a function within the Network Agent for Location and Status real system. fflThe Corresponding End System (C-ES), which is a real system capable of su* *pporting Status Notifica- tion Service. 2.2 Use of ASN.1 Basic Encoding Rules (BER) [2] provides an encoding mechanism to enable transfe* *r of information expressed in ASN.1. BER uses the Type-Length-Value (TLV) concept for its encoding, The Packed Encoding Rules (PER) of ASN.1 [X.691] [3] is a recent International * *Standard. PER is a much more compact set of encoding rules than BER, but the amount of compaction varie* *s based upon the subtype notation. It does simple things such as omitting transmitting tags or transmitt* *ing lengths when the length is known not to vary, but it also relies heavily on the subtype notation to achiev* *e maximum compaction. The document number is ITU-T Rec. X.691 _ ISO/IEC 8825-2. ASN.1 is designed to be independent of the specific encoding rules that are in * *use. A properly designed service which uses BER today can easily convert to using PER in the future with* *out much engineering effort. LSNS protocols which use ASN.1 will initially use Basic Encoding Rules. 2.3 LSNS Basic Subprofile This section defines the "LSNS Basic Subprofile" which is a building block for * *implementation of Messaging systems that support protocols specified in this specification. 2.3.1 Encoding Rules Use of Basic Encoding Rules is mandatory for both Format Standards and Submissi* *on and Delivery Protocol. In order to enable the smallest amount of data transfer, the following restrict* *ions shall be maintained in the formatting of PDUs: 1.PDUs shall be encoded in the fewest number of octets possible, regardless * *of the encoding rules in use. 2.Specifically, when ASN.1 Basic Encoding Rules are being used: 3.Only the "Definite" form of Length encoding shall be used, 4.The "Short" form of Length encoding shall be used whenever possible (i.e. * *when the Length is less than 128), and 5.OCTET STRING and BIT STRING values, and any other native ASN.1 types which* * may be encoded as either "Primitive" or "Constructed", shall always be encoded as "Primit* *ive" and shall never be "Constructed". Informational [Pa* *ge 13] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 2.3.2 Use of ESROS Efficient Short Remote Operation (ESRO) Service Access Point Selectors 6, 7, 8,* * and 9 shall be used by the EMSD-SDP. See [4]. 2.3.3 Use of UDP Port Number 2002 shall be used by the ESRO Protocol. 3 Use Of LSNS Protocols There are two basic categories of users: Corresponding End Systems (C-ESs) and * *Mobile End Systems (M- ESs). 3.1 Corresponding End Systems: A corresponding end system may be any system other than the originating end sys* *tem (O-ES). An example of a corresponding end system would be a mail server which is always available * *and which can communicate to M-ES on behalf of the originating end system (i.e., sender of e-mail). A Cor* *responding End System uses the LSNS through the protocols specified in [SNS-P]. It invokes the following o* *perations: fflstatusQuery, fflstatusNotificationRequest, ffldesireToCommunicateRequest, and performs the following: fflstatusNotificationReport. 3.2 Mobile End Systems This is an end system that is only occasionally connected. Example is a system * *that may be down during specified hours, or not have access to the network for any other reason, for in* *stance while being in an airplane (unavailability of service). A Mobile End System uses the LSNS through the prot* *ocols specified in [SNS-P], and performs the following operation: ffldesireToCommunicateNotification Informational [Pa* *ge 14] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 _____________________________________________________ |_Operation_/_Systems_________C-|ES__|LSNS__|_M-ES__|_ |_statusQuery_________________i|nvokepe|rform_|_____|_ |_statusNotificationRequest___invok|epe|rform_|_____|_ |_statusNotificationReport___perfor|m_|invoke__|____|_ |_desireToCommunicateRequest__in|vokepe|rform_|_____|_ |_desireToCommunicateNotification_|_|_invoke_p|erform_| Table 1: Invoked and Performed Operations by the LSNS, C-ES, and M-* *ES 4 Generalized LSNS Protocol The general aspects of he LSNS Protocols are specified in this section. Network specific aspects are included as attachments to this specification. 4.1 LSNS Protocols This Specification defines the following services that comprise the Status Noti* *fication Service. A summary of the operations invoked and/or performed by the various entities (C* *-ES, M-ES, and LSNS), is given in Table 1. This specification expresses information objects using ASN.1 * *[1] and expresses Remote Operations based on the model of ESROS as specified in [4]. 4.2 Operations Definition and details of the operations that are invoked by the C-ES are prese* *nted below. 4.2.1 Status Query The Status Query Operation enables a C-ES to invoke a request to LSNS to inquir* *e about the status of one or more M-ESs. The successful completion of this operation results in the delivery of status i* *nformation on one or more M-ESs to the C-ES by the LSNS. _______________________________________________________________________________* *__ Invoked by C ES to SNS, seeking the status of one or more M ES's statusQuery OPERATION ARGUMENT StatusQueryArgument RESULT StatusQueryResult ERRORS - accessControlViolated, Informational [Pa* *ge 15] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 securityError, insufficientResources, * *10 unwillingToPerform, genericError " ::= 1; StatusQueryArgument ::= SEQUENCE - -- Security features security [0] IMPLICIT SecurityElement OPTIONAL, * *20 -- List of M-ES's whose status is being sought by the C ES subjectNameOrAddress [1] SEQUENCE SIZE (0..ub subjects) OF NameOrAddress g; StatusQueryResult ::= SEQUENCE f Status information of one or more M ES's subjectStatusInfo SEQUENCE SIZE (0..ub-subjects) * *30 OF SubjectStatusInfo "; NameOrAddress ::= CHOICE - -- IP address of an End System ipAddress [0] IMPLICIT OCTET STRING (SIZE (4)), -- Domain name of an End System domainName [1] IMPLICIT PrintableString, * *40 -- NSAP address of an End System nsapAddress [2] IMPLICIT NsapAddress, -- Distinguished name of an End System distinguishedName [3] IMPLICIT PrintableString, -- List of different IP addresses [e.g., machines on a network] ipRange [4] IMPLICIT IpRange "; * *50 IpAddress ::= OCTET STRING (SIZE (4)); NsapAddress ::= OCTET STRING (SIZE (20)); IpRange ::= SEQUENCE - begin [0] IMPLICIT IpAddress, end [1] IMPLICIT IpAddress "; * *60 SubjectStatusInfo ::= SEQUENCE Informational [Pa* *ge 16] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 - -- M-ES name or address subjectNameOrAddress NameOrAddress, -- M-ES Status information reported date and time reportGenerated DateTime, * *70 -- Current status of M-ES currentStatus Status, -- Last date and time for which the M-ES status was known lastSeen DateTime OPTIONAL, -- Last M-ES status at last date and time lastStatus Status OPTIONAL "; * *80 -- M-ES status: either active, inactive or invalid Status ::= ENUMERATED - active (0), inactive (1), invalid (2), -- Circuit Switched specific Status cs-active (3), cs-inactive (4), * *90 cs-unknown (5) "; _______________________________________________________________________________* *__ 4.2.2 Status Notification Request _______________________________________________________________________________* *__ - Invoked by C-ES to SNS to request or cancel notification statusNotificationRequest OPERATION ARGUMENT StatusNotificationRequestArgument RESULT StatusNotificationRequestResult ERRORS - accessControlViolated, securityError, insufficientResources, * *10 unwillingToPerform, genericError " ::= 2; StatusNotificationRequestArgument ::= SEQUENCE - - Security features security [0] IMPLICIT SecurityElement OPTIONAL, Informational [Pa* *ge 17] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 * *20 - List of M-ES's whose status is being sought by the C-ES subjectNameOrAddress [1] SEQUENCE SIZE (0..ub-subjects) OF NameOrAddress, -- Durations of time during which the C-ES is interested in -- knowing the status of one or more M-ES's durationOfInterest [2] SEQUENCE SIZE (0..ub durations) OF Duration, Type of request submitted to SNS by C ES: either invoke, or cancel * *30 requestType [3] RequestStatus, Name or address of the C ES seeking the status of ME S's notificationGoesTo [4] NameOrAddress, -- Criteria under which the C-ES is to be notified of the status of -- the M-ES's notificationCriteria [5] NotificationCriteria g; * *40 StatusNotificationRequestResult ::= NULL; Begin time and end time of the duration during which the C ES is interested in knowing the status of one or more M ES's -- While there is no such value as "forever", a date of a relatively -- distant future can accomplish the same idea Duration ::= SEQUENCE - startTime DateTime, * *50 endTime DateTime "; -- Criteria which result in the C-ES being notified of the status of the M-ES's: When the M ES becomes Active from Inactive or the M ES is Active when the durationOfInterest begins and=or When the M ES becomes Inactive from Active or the M ES is Inactive when the durationOfInterest begins * *60 NotificationCriteria ::= BIT STRING f active (0), inactive (1) g (SIZE (0..1)); RequestStatus ::= ENUMERATED f invoke (0), cancel (1) * *70 g; Informational [Pa* *ge 18] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 _______________________________________________________________________________* *__ 4.2.3 Status Notification Report _______________________________________________________________________________* *__ Invoked by SNS to C ES to send notification statusNotificationReport OPERATION ARGUMENT StatusNotificationReportArgument RESULT StatusNotificationReportResult ERRORS f accessControlViolated, securityError, insufficientResources, * *10 unwillingToPerform, genericError g ::= 3; StatusNotificationReportArgument ::= SEQUENCE f Security features security [0] IMPLICIT SecurityElement OPTIONAL, Status information of one or more M ES's * *20 subjectStatusInfo [1] SEQUENCE SIZE (0..ub-subjects) OF SubjectStatusInfo "; StatusNotificationReportResult ::= NULL; _______________________________________________________________________________* *__ 4.2.4 Desire to Communicate Request _______________________________________________________________________________* *__ - Invoked by C-ES to SNS desireToCommunicateRequest OPERATION ARGUMENT DesireToCommunicateRequestArgument RESULT DesireToCommunicateRequestResult ERRORS - accessControlViolated, securityError, insufficientResources, * *10 unwillingToPerform, genericError " ::= 4; DesireToCommunicateRequestArgument ::= SEQUENCE - - Security features security [0] IMPLICIT SecurityElement * *OPTIONAL, Informational [Pa* *ge 19] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 - List of M-ES's with whom the C-ES wishes to communicate * *20 subjectNameOrAddress [1] NameOrAddress, -- Durations of time during which the request is valid durationOfInterest [2] SEQUENCE SIZE (0..u* *b-durations) OF Duration, -- The last time at which an attempted communication by the -- C-ES to the M-ES failed failedAttemptTime [3] DateTime, * *30 -- The type of application (smtp, talk, ...) associated with -- failedAttemptTime applicationType [4] SEQUENCE SIZE (0..ub-* *apps) OF ApplicationTypes, -- Notification of availability of M-ES for communication goes to ... notificationGoesTo [5] NameOrAddress OPT* *IONAL, -- Type of request submitted to SNS by C-ES: invoke or cancel requestType [6] RequestStatus * *40 "; DesireToCommunicateRequestResult ::= NULL; ApplicationTypes ::= SEQUENCE - portNumber INTEGER, transportId INTEGER "; * *50 etcServices SEQUENCE OF ApplicationTypes ::= - - portNumber 1, transportId 1 ", -- tcpmux - portNumber 7, transportId 1 ", -- echo - portNumber 7, transportId 2 ", -- echo - portNumber 9, transportId 1 ", -- discard - portNumber 9, transportId 2 ", -- discard - portNumber 11, transportId 1 ", -- systat - portNumber 13, transportId 1 ", -- daytime - portNumber 13, transportId 2 ", -- daytime * *60 - portNumber 15, transportId 1 ", -- netstat - portNumber 19, transportId 1 ", -- chargen - portNumber 19, transportId 2 ", -- chargen - portNumber 20, transportId 1 ", -- ftpdata - portNumber 21, transportId 1 ", -- ftp - portNumber 23, transportId 1 ", -- telnet - portNumber 25, transportId 1 ", -- SMTP - portNumber 37, transportId 1 ", -- time - portNumber 37, transportId 2 ", -- time - portNumber 42, transportId 2 ", -- name * *70 - portNumber 43, transportId 2 ", -- whois - portNumber 53, transportId 1 ", -- domain - portNumber 53, transportId 2 ", -- domain - portNumber 101,transportId 1 ", -- hostname Informational [Pa* *ge 20] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 - portNumber 111,transportId 1 ", -- sunrpc - portNumber 111,transportId 2 " -- sunrpc "; _______________________________________________________________________________* *__ 4.2.5 Desire to Communicate Notification _______________________________________________________________________________* *__ - Invoked by SNS to M-ES of C-ES's desire to communicate desireToCommunicateNotification OPERATION ARGUMENT DesireToCommunicateNotificationArgument RESULT DesireToCommunicateNotificationResult ERRORS - accessControlViolated, securityError, insufficientResources, * *10 unwillingToPerform, genericError " ::= 5; DesireToCommunicateNotificationArgument ::= SEQUENCE - -- Security features security [0] IMPLICIT SecurityElement OPTIONAL, -- Name or address of C-ES * *20 correspondingNameOrAddress [1] NameOrAddress, -- The last time at which an attempted communication by the -- C-ES to the M-ES failed failedAttemptTime [3] DateTime, -- The type of application (email, talk, ...) the C-ES was attempting -- to establish with the M-ES at the failed attempt time applicationType [4] SEQUENCE SIZE (0..ub-apps) OF ApplicationTypes * *30 "; DesireToCommunicateNotificationResult ::= NULL; _______________________________________________________________________________* *__ 4.3 LSNS Common Information Objects _______________________________________________________________________________* *__ SecurityElement ::= SEQUENCE - credentials Credentials, contentIntegrityCheck ContentIntegrityCheck OPTIONAL "; Credentials ::= CHOICE - Informational [Pa* *ge 21] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 simple [0] IMPLICIT SimpleCredentials * *10 - Strong Credentials are for future study -strong [1] IMPLICIT StrongCredentials "; SimpleCredentials ::= SEQUENCE - myNameOrAddress [0] NameOrAddress OPTIONAL, password [1] OCTET STRING (SIZE(0..ub-password-length)) OPTIONAL "; * *20 ContentIntegrityCheck ::= INTEGER (0..65535); - ContentIntegrityCheck is a 16-bit checksum of the contents _______________________________________________________________________________* *__ 4.3.1 Errors securityError ERROR PARAMETER security-problem SecurityProblem ::= 4; accessControlViolated ERROR PARAMETER NULL ::= 5; insufficientResources ERROR PARAMETER NULL ::= 6; unwillingToPerform ERROR PARAMETER NULL ::= 7; genericError ERROR PARAMETER NULL ::= 8; SecurityProblem ::= INTEGER (0..127); 4.3.2 DateTime -- DateTime is a Julian date, expressed as the number of -- seconds since 00:00:00 UTC, January 1, 1970. DateTime ::= INTEGER; 4.3.3 AsciiPrintableString Iso8859String ::= OCTET STRING; Informational [Pa* *ge 22] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 4.3.4 UpperBounds ub-subjects INTEGER ::= 256; ub-durations INTEGER ::= 127; ub-apps INTEGER ::= 16; ub-password-length INTEGER ::= 16 5 Implementation Considerations 5.1 General System Model An overview of LSNS is given in Figure 7, which we will refer to below. Figure * *8 presents the details of this Wireless Data & Voice network and is essentially a more detailed and less * *abstract version of Figure 8 (Chapter ??). The shaded areas are the focus of this document. The following functional breakdowns and their respective requirements from Figu* *re 7 are: fflNetwork Agent for Location and Status The functions of the Network Agent for Location and Status are carried out* * via a Location Directory. The Location Directory maintains an information base of the current forwar* *ding address for each M-ES in its home area. A necessary enhancement to the Network Agent for Location and Status is a * *Notification Request Directory that keeps track of which M-ESs the C-ES seeks information. They* * can be implemented as an extension to the location directory. Overall, the Network Agent for Location and Status must be capable of: - Providing the LSNS with the current location of an M-ES. - Registering those C-ESs which seek information on an M-ES, and conveyi* *ng this information to the LSNS when necessary. fflLSNS The LSNS needs to interact with the Network Agent for Location and Status * *, C-ESs, M-ESs, and the System Management. With the Network Agent for Location and Status , the LS* *NS should be able of determining the current location of an M-ES, as well as the list of C-ESs * *wishing to communicate with an M-ES. With System Management, interaction is as specified above. With t* *he C-ES, the LSNS needs to be capable of providing it with a Status Notification Report on one or * *more M-ESs. With the M-ES the LSNS needs to be able to relay the desire to communicate of a C-ES to * *it. fflSystem Management At any given point in time, system management must be aware of, capable of* * performing, and/or regulating a number of system parameters. These could be the capability of: Informational [Pa* *ge 23] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Figure 7: System Model Block Diagram - Determining the number of users that are active, - The general activity level of the network (LSNS + C-ES + M-ES), - Authentication of the C-ES, etc. System management must interact continuously with the LSNS to furthermore * *determine - Determine the load on the system, - Gauge its performance over time through monitoring its response to req* *uests for status notification and communication - Enable or disable security and access control mechanisms between the L* *SNS and the M-ES or C-ES - Ensure that the LSNS is running within accepted limits of operation. Informational [Pa* *ge 24] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 A Applying LSNS to the CDPD Network A.1 CDPD LSNS Overview In the specification described in this document, only the Cellular Digital Pack* *et Data (CDPD) network is con- sidered. The Status Notification Service can be easily applied to most other ne* *tworks that support mobility. The CDPD network supports communication with mobile devices which are only occa* *sionally connected to the network. Referring to Figure 6 the chosen network comprises: 1.An OC-ES, which in the context of CDPD is called a Mobile End System (M-ES* *). 2.The Serving MD-IS, through which the M-ES is attached to the network. 3.The Network Agent for Location and Status , which is the M-ES's anchor in * *the network and is always aware of the M-ES's status. The Status Notification Agent is realized as a* * function within the Network Agent for Location and Status real system. 4.The Corresponding End System, which is a real system capable of supporting* * Status Notification Ser- vice. Figure 8 presents the details of this CDPD network and is essentially a more de* *tailed and less abstract version of Figure 6. The interface between the M-ES and Serving MD-IS (A-Interface) is * *fully specified in the CDPD Specification and requires no modifications to support the Status Notification * *Service.The interface between the Serving MD-IS and the Network Agent for Location and Status (B-Interface) i* *s also fully defined in the CDPD specification and requires no modifications. The shaded areas and the C- i* *nterface are the focus of this document. Modifications needed by the involved entities are indicated by the shaded areas* * in Figure 9. A number of new functions need to be added to the Network Agent for Location and Status . They * *include the "Status Reporting Registration Function", the "Status Notification Function" and the "Status Repo* *rt Query Function". Several of the existing functions of the Network Agent for Location and Status need to * *be modified to support the Status Notification Service. In particular, the "Record Location Function" and * *the "Flush Location Function" need to be enhanced to interact with the new status notification related functi* *ons of the Network Agent for Location and Status . In addition to the functions mentioned above, a new information base which stor* *es requests for status notifi- cation need to be added to the Network Agent for Location and Status . This inf* *ormation base is illustrated as the "Notification Request Directory" in Figure 8. Further, the Network Agent* * for Location and Status's "Location Directory" is used by the Status Notification Service. It is possible* * to implement the "Notification Request Directory" as an extension of the "Location Directory". The shaded areas in Figure 9 indicate where software modifications are required* * for an LSNS implementation. As illustrated in Figure 9 there are no modifications required to the M-ES for * *a basic implementation of LSNS. Some M-ESs may implement a system which would require the M-ES to poll a Messag* *ing Server for mes- sages (e.g. IMAP, POP). For these implementations the desireToCommunicate servi* *ces are included. The shaded areas in Figure 10 illustrate where modifications will be required for a* *n LSNS implementation which includes the desireToCommunicate services. Informational [Pa* *ge 25] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Informational [Pa* *ge 26] Figure 8: Detailed interface diagram for the CDPD LSNS Network RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Figure 9: Modifications Required for LSNS Figure 10: Modifications Required for LSNS with desireToCommunicate Informational [Pa* *ge 27] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 A.2 LSNS Procedures For The CDPD Network We provide examples here of the use of statusNotificationRequest and statusNoti* *ficationReport operations. A.2.1 Invoking statusNotificationRequest by the C-ES In this example the C-ES is responsible for delivery of messages (e.g., email) * *to the M-ES as soon as possible and as efficiently as possible. Referring to Figure 11, after accepting respons* *ibility for the delivery of the message (01), the recipient's email address is translated into the M-ES NEI of * *the recipient (02). If the C-ES has seen recent indications of the M-ES being active (03), then C-ES attempts t* *o deliver the email (04). If the M-ES is not active (the message delivery was not successful), then the C* *-ES invokes the "Status Notification Request" remote operation on the Network Agent for Location and St* *atus . This results into the "Status Notification Request Procedure" of the Network Agent for Location a* *nd Status performing the procedures described in Figure 12. A.2.2 Performing statusNotificationRequest by the LSNS Referring to Figure 3.3, the status report registration process inside of the N* *etwork Agent for Location and Status appears generally as depicted by reference number 00. To begin the Netwo* *rk Agent for Location and Status accepts the request from the C-ES. (01). Next, the "Notification Registr* *ation Directory" is searched for the M-ES's NEI which is the subject of the request (02). If the search is not s* *uccessful, then an entry is created (03). Then the Corresponding-ES's address is added to the "Requesting System Li* *st" of the Notification Registration Directory(04). If the M-ES NEI is in the Network Agent for Locatio* *n and Status 's Location Directory which means the M-ES is active, then the C-ES is notified of the M-ES* *'s active status. This results into the "Status Notification Report Procedure" of the C-ES performing the proc* *edures described in Figure 15. When an M-ES becomes active or inactive, the Network Agent for Location and Sta* *tus may notify the C-ES of those events. The trigger for the "active status" notification process is the "* *Record Location Function" of the Network Agent for Location and Status which is a result of the Serving MD-IS's * *"Report Location Function" which follows the M-ES becoming active. The trigger for the "inactive status" n* *otification process is the "Flush Location Function" of the Home MD-IS which is a result of the Serving MD* *-IS's "Flush Location Function" which follows the M-ES becoming inactive. A.2.3 Invoking statusNotificationReport by the LSNS (going active) Referring to Figure 13, the active status notification process inside of the Ne* *twork Agent for Location and Status appears generally as depicted by reference number 00. This process is tr* *iggered by receiving an RDR- PDU from the Serving MD-IS. First, the ordinary "Record Location Function" of t* *he Network Agent for Location and Status is performed (01). Next, the "Notification Request Director* *y" is searched for the M-ES's NEI (02). If the search is successful, then the list of C-ESs to notify is obta* *ined (03). Each of the C-ESs are notified (04), (05). This results into the "Status Notification Function" of th* *e C-ES performing the procedures described in Figure 3.6. Informational [Pa* *ge 28] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Informational [Pa* *ge 29] Figure 11: C-ES invoking statusNotificationRequest RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Informational [Pa* *ge 30] Figure 12: LSNS performing statusNotificationRequest RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Informational [Pa* *ge 31] Figure 13: LSNS invoking statusNotificationReport, going active RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 A.2.4 Invoking statusNotificationReport by the LSNS (going inactive) Referring to Figure 14, the active status notification process inside of the HO* *ME-MDIS appears generally as depicted by reference number 00. This process is triggered by receiving the * *RDE-PDU from the Serving MDIS. First, the ordinary "Flush Location Function" of the HOME-MDIS is perform* *ed(01). Next, the "No- tification Registration Directory" is searched for the M-ES's NEI (02). If the * *search is successful, then the list of C-ESs to notify is obtained (03). Each of the C-ESs are notified (04), * *(05). A.2.5 Performing statusNotificationReport Procedures Referring to Figure 15, the C-ES translates the M-ES NEI into a list of message* *s that are pending for that M-ES (02). Then it attempts to deliver the messages to the M-ES. Since the M-ES* * is active, the delivery is likely to be successful. In case of failure, this M-ES's messages get subject t* *o C-ES's retransmission policy (05). B Applying LSNS to the Cellular Voice Network This Section To Be Supplied By Xypoint. C Abbreviations BER Basic Encoding Rules C-ES Corresponding End System CDPD Cellular Digital Packet Data ESRO Efficient Short Remote Operation ESROS Efficient Short Remote Operation Services LAN Local Area Network LSNS Location & Status Notification Services M-ES Mobile End System NALS Network Agent for Location & Status OC-ES Occasionally Connected End System PER Packed Encoding Rules SNS Status Notification Services TLV Type-Length-Value WAN Wide Area Network References [1]Specification of Abstract Syntax Notation One. The International Telegraph a* *nd Telephone Consultative Committee, 1988. Recommendation X.208. [2]Specification of Basic Encoding Rules for Abstract Syntax Notation One. The * *International Telegraph and Telephone Consultative Committee, 1988. Recommendation X.209. Informational [Pa* *ge 32] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Informational [Pa* *ge 33] Figure 14: LSNS invoking statusNotificationReport, going inacti* *ve RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 Figure 15: C-ES performing statusNotificationReport Informational [Pa* *ge 34] RFC DRAFT - Release 0.3 LSNS Specification Nove* *mber, 1999 [3]Information Processing _ Open Systems Interconnection _ Specification of Pac* *ked Encoding Rules for Abstract Syntax Notation One (ASN.1). International Organization for Standar* *dization and International Electrotechnical Committee. International Standard 8825-2. [4]M. Taylor, J. Cheng, and M. Banan. AT&T/Neda's Efficient Short Remote Operat* *ions (ESRO) Protocol Specification Version 1.2. Request for Comments (Informational) 2188, Neda C* *ommunications, Inc., September 1997. Online document is available at ftp://ftp.isi.edu/in-notes/r* *fc2188.txt. Informational [Pa* *ge 35]