Network Working Group Request for Comments: DRAFT -- Release 0.3 Category: Informational November, 1999 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 . . . 5 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 . . . . . . . . . . . . 13 2.2 Use of ASN.1 . . . . . . . . . . . 13 2.3 LSNS Basic Subprofile . . . . . . . . 13 2.3.1 Encoding Rules . . . . . . . . 14 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 . . . . . . . . . 15 4 Generalized LSNS Protocol 15 4.1 LSNS Protocols . . . . . . . . . . 15 4.2 Operations . . . . . . . . . . . 16 4.2.1 Status Query . . . . . . . . . 16 4.2.2 Status Notification Request . . . . . 18 4.2.3 Status Notification Report . . . . . . 20 4.2.4 Desire to Communicate Request . . . . . 20 4.2.5 Desire to Communicate Notification . . . . 22 4.3 LSNS Common Information Objects . . . . . . 23 4.3.1 Errors . . . . . . . . . . . 23 4.3.2 DateTime . . . . . . . . . . 23 4.3.3 AsciiPrintableString . . . . . . . 24 4.3.4 UpperBounds . . . . . . . . . 24 5 Implementation Considerations 24 RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 5.1 General System Model . . . . . . . . . 24 A Applying LSNS to the CDPD Network 26 A.1 CDPD LSNS Overview . . . . . . . . . 26 A.2 LSNS Procedures For The CDPD Network . . . . . 30 A.2.1 Invoking statusNotificationRequest by the C-ES . 30 A.2.2 Performing statusNotificationRequest by the LSNS 30 A.2.3 Invoking statusNotificationReport by the LSNS (going active) . . . . . . . . . . 32 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 37 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 . . . . . . . 26 8 Detailed interface diagram for the CDPD LSNS Network . 28 9 Modifications Required for LSNS . . . . . . 29 10 Modifications Required for LSNS with desireToCommunicate 29 11 C-ES invoking statusNotificationRequest . . . . 31 12 LSNS performing statusNotificationRequest . . . 33 13 LSNS invoking statusNotificationReport, going active . 34 14 LSNS invoking statusNotificationReport, going inactive 35 15 C-ES performing statusNotificationReport . . . . 36 List of Tables 1 Invoked and Performed Operations by the LSNS, C-ES, and M-ES 16 Informational [Page 2] RFC DRAFT -- Release 0.3 LSNS Specification November, 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 Corporation 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: o The location reporting features are preliminary. o The Cellular Voice Network specific features are incomplete. o The 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 be 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 costly in network traffic and delivery delays. The occasionally connected nature of M-ESs introduces the challenge of delivering information to the devices in a timely and efficient manner. Existing solutions to this problem are generally inefficient. We attempt to address this problem in an efficient and timely manner by introducing the Loaction & Status Notification Service (LSNS), where the current status (active/inactive) and the general location of Informational [Page 3] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 the M-ES is determined and communicated to those parties which should be provided access to such information. 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 recipient 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 access to this information is an integral part of this document. Basic concept and capabilities of LSNS are relevant to networks which support mobility. 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 assumes that the recipient is ready and willing to accept the information. The introduction of occasionally-connected devices which are often disconnected from the network invalidates this assumption because the occasionally-connected devices are often not available for information exchange. Attempting to communicate with an occasionally-connected device suffers from the inherent problems of efficient and timely notification of the availability and desire of the communicating parties. The originator needs to know whether or not the intended (occasionally-connected) recipient will 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 system 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 transmission is much more costly in terms of resource consumption and thus the problem of status notification 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 occasionally-connected recipient knows that the originator desires Informational [Page 4] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 Figure 1: Location & Status Notification Service Architecture communication with it. This service provides a mechanism by which each of the communicating parties is efficiently notified about the status of its communications peer. 1.1.1 General Model for Status Notification In the most general case, a corresponding end system (C-ES) communicates with an occasionally-connected end system (OC-ES) using information provided by the Location & Status Notification Service (LSNS). A corresponding end system may be any system other than the originating end system (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 communication with occasionally connected end systems more efficient, this system introduces a tri-lateral communication model. We introduce a Status Notification Service that facilitates communication 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 notification server can contain information regarding the C-ES's desire to communicate while the OC-ES was unreachable and can inform the OC-ES as soon as it becomes reachable. The crux of the status notification problem, and of this service, lies Informational [Page 5] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 in the communication between the C-ES and the OC-ES. If the C-ES is unaware of the availability, location and receptiveness 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. 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 these mechanisms involve the establishment of an association at the application layer between the C-ES and the LSNS. This association provides the means by which the LSNS informs the C-ES about the status of the OC-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 this event. A state change could involve the availability of the OC-ES, the ability of the OC-ES to communicate (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 illustrated in Figure 1, Figure 2, and Figure 4. Mechanism 2: Whenever the C-ES receives data destined for the OC-ES, it notifies the LSNS of its desire to communicate with the OC-ES. When the OC-ES becomes available, the LSNS notifies it of the C-ES's desire to communicate. The OC-ES then establishes an application layer association 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 between 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 occasionally-connected end systems. 1.2 Common Scenarios for using LSNS Scenario 1: C-ES initiates association with OC-ES when the OC-ES becomes reachable. 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 line connecting the LSNS and the OC-ES -- going through the network which supports the OC-ES -- represents communication between these entities. The line connecting the C-ES and the OC-ES represents the application layer association between these entities. It exists Informational [Page 6] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 Figure 2: Scenario 1 for the duration of the data transmission between these 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 network 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. Scenario 2: The OC-ES initiates the association. Refer to Figure 3 which, as in 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 Informational [Page 7] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 Figure 3: Scenario 2 because the OC-ES is unreachable. 2. C-ES communicates to LSNS its desire to communicate with the OC-ES. 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 network 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 OC-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. 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 Informational [Page 8] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 Figure 4: Example of Messaging to an OC-ES communication or inactive and unavailable. 4. Provide status change notifications to the C-ES entities which have requested notification. 5. Timely and reliable delivery of status change notifications, as this directly 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 originator 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. 1. The message originator sends a message which arrives at the recipient's message-delivery-system (i.e., mail-box). The Informational [Page 9] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 Figure 5: Another Example of Messaging to an OC-ES message-delivery-system attempts to deliver the message to the recipient but the association between the C-ES (message-delivery-system) and OC-ES (Message Recipient) fails. 2. The message-delivery-system (C-ES) requests from the LSNS to be notified of 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 reachable 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 also 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 message-delivery-system. The message-delivery-system attempts to deliver the message to the recipient but 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 communicate with the Message recipient (OC-ES). Note that this step could either precede or follow Step 1. Informational [Page 10] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 3. The OC-ES becomes reachable. The LSNS notifies the Message Recipient (OC-ES) of the message-delivery-system's (C-ES) desire to communicate. 4. The Message Recipient (OC-ES) uses this information to retrieve its message. 1.5 General Usage Characteristics Use of the LSNS service generally revolves around the following key concepts: o The Status Notification Server always knows when a device is registered on the network. o The Status Notification Server can notify different applications of the status (active or non-active) of an Occasionally Connected End System. o Corresponding End-Systems (e.g. Message Centers) and many other applications can operate more efficiently if they know when an Occasionally Connected End-System (e.g. a mobile unit) is registered and ready. o Additionally, the Status Notification Server can notify an Occasionally Connected System of an application's desire to communicate. 1.6 Scope Of This Specification The specification outlined in this document defines the protocol between the Status Notification Service, the Corresponding End System, and the Occasionally Connected System. The protocol will be based on the Efficient Short Remote Operation Services (see [1]). This chapter has presented an introduction to the main ideas of status notification. Chapter 2 provides an overview of the LSNS protocol. Network specific aspects of the protocol are included as attachments to the document. 2 Status Notification Service Overview An overview of the Status Notification Service for a Wireless Data & Voice network, and the various interface protocols (which make use of ASN.1 and Basic Encoding Rules) are shown in Figure 6. The annotations for Figure 6 are: Informational [Page 11] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 Figure 6: LSNS Interfaces and Protocols - (b) and (d) are of our interest. a. Registration Reporting Protocol (RRP). This could be an Application Programming 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 Service 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). e. API for (4). f. Mobile Network Registration Protocol (MNRP). This document will focus on the global protocols between the LSNS and the Corresponding 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 [1]. 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. Informational [Page 12] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 2.1 Elements Primary elements of the LSNS system are those highlighted in Figure 6. These comprise: o An Occasionally-Connected End System -- also called a Mobile End Systems (M-ES). o The Network Agent for Location and Status (NALS) , which is the M-ES's anchor in the network and is always aware of M-ES's status. The Status Notification Agent may be realized as a function within the Network Agent for Location and Status real system. o The Corresponding End System (C-ES), which is a real system capable of supporting Status Notification Service. 2.2 Use of ASN.1 Basic Encoding Rules (BER) [3] provides an encoding mechanism to enable transfer 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] [4] is a recent International Standard. PER is a much more compact set of encoding rules than BER, but the amount of compaction varies based upon the subtype notation. It does simple things such as omitting transmitting tags or transmitting lengths when the length is known not to vary, but it also relies heavily on the subtype notation to achieve 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 without 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. Informational [Page 13] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 2.3.1 Encoding Rules Use of Basic Encoding Rules is mandatory for both Format Standards and Submission and Delivery Protocol. In order to enable the smallest amount of data transfer, the following restrictions 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 "Primitive" and shall never be "Constructed". 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 [1]. 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 system (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., Informational [Page 14] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 sender of e-mail). A Corresponding End System uses the LSNS through the protocols specified in [SNS-P]. It invokes the following operations: o statusQuery, o statusNotificationRequest, o desireToCommunicateRequest, and performs the following: o statusNotificationReport. 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 instance while being in an airplane (unavailability of service). A Mobile End System uses the LSNS through the protocols specified in [SNS-P], and performs the following operation: o desireToCommunicateNotification 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 Notification 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 [2] and expresses Remote Operations based on the model of ESROS as specified in [1]. Informational [Page 15] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 ____________________________________________________________ |_Operation_/_Systems_____________|C-ES___|_LSNS___|_M-ES__|_ |_statusQuery_____________________|invoke__|perform_|______|_ |_statusNotificationRequest_______|invoke__|perform_|______|_ |_statusNotificationReport________|perform_|invoke__|______|_ |_desireToCommunicateRequest______|invoke__|perform_|______|_ |_desireToCommunicateNotification_|_______|invoke__|perform|_ Table 1: Invoked and Performed Operations by the LSNS, C-ES, and M-ES 4.2 Operations Definition and details of the operations that are invoked by the C-ES are presented below. 4.2.1 Status Query The Status Query Operation enables a C-ES to invoke a request to LSNS to inquire about the status of one or more M-ESs. The successful completion of this operation results in the delivery of status information 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, 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) Informational [Page 16] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 OF NameOrAddress }; StatusQueryResult ::= SEQUENCE { -- 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 { -- 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, Informational [Page 17] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 -- 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, 20 -- List of M-ES's whose status is being sought by the C-ES subjectNameOrAddress [1] SEQUENCE SIZE (0..ub-subjects) OF NameOrAddress, Informational [Page 18] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 -- 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, or3cancel0 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 }; 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 { active (0), inactive (1) } (SIZE (0..1)); RequestStatus ::= ENUMERATED { invoke (0), cancel (1) 70 }; _______________________________________________________________________ Informational [Page 19] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 4.2.3 Status Notification Report _______________________________________________________________________-- Invoked by SNS to C-ES to send notification statusNotificationReport OPERATION ARGUMENT StatusNotificationReportArgument RESULT StatusNotificationReportResult ERRORS { accessControlViolated, securityError, insufficientResources, 10 unwillingToPerform, genericError } ::= 3; StatusNotificationReportArgument ::= SEQUENCE { -- 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 Informational [Page 20] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 security [0] IMPLICIT SecurityElement OPTIONAL, -- 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..ub-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 OPTIONAL, -- Type of request submitted to SNS by C-ES: invoke or cancel requestType [6] RequestStatus40 }; 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 Informational [Page 21] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 { 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 { 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; _______________________________________________________________________ Informational [Page 22] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 4.3 LSNS Common Information Objects _______________________________________________________________________SecurityElement ::= SEQUENCE { credentials Credentials, contentIntegrityCheck ContentIntegrityCheck OPTIONAL }; Credentials ::= CHOICE { 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 Informational [Page 23] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 -- seconds since 00:00:00 UTC, January 1, 1970. DateTime ::= INTEGER; 4.3.3 AsciiPrintableString Iso8859String ::= OCTET STRING; 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 Figure 7 are: o Network 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 forwarding 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. Informational [Page 24] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 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 conveying this information to the LSNS when necessary. o LSNS 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 LSNS 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 the 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. o System 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: -- 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 requests for status notification and communication -- Enable or disable security and access control mechanisms between the LSNS and the M-ES or C-ES -- Ensure that the LSNS is running within accepted limits of operation. Informational [Page 25] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 Figure 7: System Model Block Diagram A Applying LSNS to the CDPD Network A.1 CDPD LSNS Overview In the specification described in this document, only the Cellular Digital Packet Data (CDPD) network is considered. The Status Notification Service can be easily applied to most other networks that support mobility. The CDPD network supports communication with mobile devices which are only occasionally 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. Informational [Page 26] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 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 Service. Figure 8 presents the details of this CDPD network and is essentially a more detailed 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) is also fully defined in the CDPD specification and requires no modifications. The shaded areas and the C- interface 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 Report 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 functions of the Network Agent for Location and Status . In addition to the functions mentioned above, a new information base which stores requests for status notification need to be added to the Network Agent for Location and Status . This information 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 Messaging Server for messages (e.g. IMAP, POP). For these implementations the desireToCommunicate services are included. The shaded areas in Figure 10 illustrate where modifications will be required for an LSNS implementation which includes the desireToCommunicate services. Informational [Page 27] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 Figure 8: Detailed interface diagram for the CDPD LSNS Network Informational [Page 28] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 Figure 9: Modifications Required for LSNS Figure 10: Modifications Required for LSNS with desireToCommunicate Informational [Page 29] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 A.2 LSNS Procedures For The CDPD Network We provide examples here of the use of statusNotificationRequest and statusNotificationReport 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 responsibility 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 to 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 Status . This results into the "Status Notification Request Procedure" of the Network Agent for Location and 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 Network Agent for Location and Status appears generally as depicted by reference number 00. To begin the Network Agent for Location and Status accepts the request from the C-ES. (01). Next, the "Notification Registration Directory" is searched for the M-ES's NEI which is the subject of the request (02). If the search is not successful, then an entry is created (03). Then the Corresponding-ES's address is added to the "Requesting System List" of the Notification Registration Directory(04). If the M-ES NEI is in the Network Agent for Location 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 procedures described in Figure 15. When an M-ES becomes active or inactive, the Network Agent for Location and Status 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" notification process is the "Flush Location Function" of the Home Informational [Page 30] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 Figure 11: C-ES invoking statusNotificationRequest Informational [Page 31] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 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 Network Agent for Location and Status appears generally as depicted by reference number 00. This process is triggered by receiving an RDR-PDU from the Serving MD-IS. First, the ordinary "Record Location Function" of the Network Agent for Location and Status is performed (01). Next, the "Notification Request 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). This results into the "Status Notification Function" of the C-ES performing the procedures described in Figure 3.6. A.2.4 Invoking statusNotificationReport by the LSNS (going inactive) Referring to Figure 14, the active status notification process inside of the HOME-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 performed(01). Next, the "Notification 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 messages 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 to C-ES's retransmission policy (05). B Applying LSNS to the Cellular Voice Network This Section To Be Supplied By Xypoint. Informational [Page 32] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 Figure 12: LSNS performing statusNotificationRequest Informational [Page 33] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 Figure 13: LSNS invoking statusNotificationReport, going active Informational [Page 34] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 Figure 14: LSNS invoking statusNotificationReport, going inactive Informational [Page 35] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 Figure 15: C-ES performing statusNotificationReport Informational [Page 36] RFC DRAFT -- Release 0.3 LSNS Specification November, 1999 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] M. Banan, J. Cheng, and M. Taylor. AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2. Request for Comments (Informational) 2188, Neda Communications, Inc., September 1997. Online document is available at ftp://ftp.isi.edu/in-notes/rfc2188.txt. [2] Specification of Abstract Syntax Notation One, 1988. Recommendation X.208. [3] Specification of Basic Encoding Rules for Abstract Syntax Notation One, 1988. Recommendation X.209. [4] Information Processing --- Open Systems Interconnection --- Specification of Packed Encoding Rules for Abstract Syntax Notation One (ASN.1). International Organization for Standardization and International Electrotechnical Committee. International Standard 8825-2. Informational [Page 37]