INTERNET-DRAFT                                                D.Piscitello,
Expires: February 28, 1998                                         L.Phifer
                                                            Core Competence
                                                                    Y.Wang,
                                                                    R.Hovey
                                                                   Bellcore
                                                            August 28, 1997


                   Mobile Network Computing Protocol (MNCP)
                        <draft-piscitello-mncp-00.txt>

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference material
   or to cite them other than as "works in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.  Please send comments to the
   authors.

Abstract

   This memo documents an architecture and protocol for mobile network
   computing. The protocol described herein provides session control and
   reliable delivery services to accommodate mobile client access to
   internetworked applications within a 'client-agent-server'
   architecture.  Client middleware based on this architecture can operate
   over wireless data networking services such as RAM, ARDIS, CDPD, PCS
   data services and wireless local area networks.  This client middleware
   can be implemented using any standard application programming interface
   to a commercial UDP/IP stack on Hand-held PC's (HPC), personal digital
   assistants (PDA's), four-line browsers or 'smart' phones as well as
   laptop and desktop computers.










   <draft-piscitello-mncp-00.txt>                               Page 1


INTERNET DRAFT                   MNCP                   August 28, 1997


                             Table of Contents

1. Introduction...........................................................4
1.1 Motivation............................................................4
1.2 Design Goals..........................................................4
1.3 Mobile Network Computing Architecture.................................6
1.4 Relationship of MNCP to other Internet Protocols......................7
1.5 Requirements..........................................................8
1.6 Terms.................................................................8
2. Protocol Overview......................................................9
2.1 Single Packet Reliable Delivery Service...............................9
2.2 Multi-Packet Reliable Delivery Service...............................10
2.2.1 NOTIFICATION Packet Processing (Sender)............................10
2.2.2 NOTIFICATION Packet Processing (Receiver)..........................12
2.2.3 Data Transfer (Sender).............................................12
2.2.4 Data Transfer (Receiver)...........................................13
2.3 Session Control Service..............................................14
2.3.1 Subscriber Validation..............................................14
2.3.2 Registration.......................................................14
2.3.3 Application Data Transfer..........................................15
2.3.4 Deregistration.....................................................15
2.3.5 Correlation Identifiers............................................16
3. MNCP Reliable Delivery Packets........................................16
3.1 Packet Types.........................................................16
3.2 Packet Headers.......................................................17
3.3 Packet Body..........................................................18
3.4 Packet Length........................................................20
3.5 Information Elements.................................................20
3.5.1 Data (Final and More)..............................................21
3.5.2 Message Length.....................................................21
3.5.3 Acknowledge Code...................................................22
3.5.4 Data Compression...................................................22
3.5.5 Data Offset........................................................23
3.5.6 Packet Size........................................................23
3.6 PT_CMD...............................................................23
3.7 PT_ACK...............................................................24
3.8 PT_NTFN..............................................................24
3.9 PT_DATA..............................................................24
4. MNCP Session Control Packets..........................................25
4.1 Packet Types.........................................................25
4.2 Session Control Headers..............................................25
4.3 Session Control Body.................................................26
4.4 Packet Length........................................................26
4.5 Information Elements.................................................26
4.5.1 Subscriber ID......................................................26
4.5.2 Application ID.....................................................26
4.5.3 Subscriber Password................................................27
4.5.4 Registration Status................................................27
4.5.5 Message Cross-Correlation ID.......................................27
4.5.6 Acknowledge Code...................................................27
4.6 FUN_REG_REQ..........................................................28
4.7 FUN_DEREG_REQ........................................................28
4.8 FUN_<other>..........................................................29
5. MNCP Reliable Delivery Processing.....................................29


<draft-piscitello-mncp-00.txt>                                  Page 2


INTERNET DRAFT                   MNCP                   August 28, 1997


5.1 Phase Diagram........................................................29
5.2 State Diagram........................................................31
5.3 States...............................................................32
5.4 Events...............................................................33
5.5 Actions..............................................................34
5.6 Timers, Acknowledgment, and Retransmission...........................37
5.7 Packet Size Negotiation, Segmentation and Reassembly.................37
5.7.1 Computing the payload size for PT_DATA packets.....................38
5.7.2 Segmentation and PT_DATA Packet Composition........................38
5.7.3 Reassembly.........................................................39
5.8 Data Compression.....................................................39
6. MNCP Session Control Processing.......................................40
6.1 Phase Diagram........................................................40
6.2 State Diagram........................................................42
6.3 States...............................................................42
6.4 Events...............................................................43
6.5 Actions..............................................................44
7. Security Considerations...............................................48
8. References............................................................48
9. Authors' Addresses....................................................49
Appendix A. HDML Transactions using MNCP.................................50
Appendix B. Future Protocol Extensions...................................55


































<draft-piscitello-mncp-00.txt>                                  Page 3


INTERNET DRAFT                   MNCP                   August 28, 1997



1. Introduction

1.1 Motivation

   Mobile network computing, if constrained by consumer interest alone,
   would at this point in time increase more rapidly than the growth of
   the Internet itself.  Applications that drive consumer interest --
   access to the public web and intranets, remote access to corporate and
   public databases, unified messaging and two-way paging -- are already
   present and widely available, having already been enabled by public and
   enterprise IP-based internetworking.

   The need to access internetworked applications remotely has already
   been established, but the means of addressing that need are only
   partially satisfied through the use of wireline and portable (laptop)
   PC solutions.

   The rapid acceptance of cellular telephony provides a strong indication
   of how quickly similarly untethered computer communications will be
   embraced by consumers. Recent technology advances now make it possible
   to produce handheld devices that are as small as cellular phones yet
   smart as portable PC's.  These devices are very adapted for wireless
   communications environments, better able to maintain signal strength
   and intelligently manage power consumption.  It is thus likely that
   mobile network computers (MNCs), hand-held PC's (HPCs), personal
   digital assistants, and four-line browser or "smart" phones operating
   over wireless data networks will complement (or inherit) existing
   remote access alternatives, and create a potentially enormous consumer
   market for wireless data networking services such as RAM, ARDIS, CDPD,
   and PCS data services.

   This new class of mobile computing devices (MCD's) will often operate
   in low bandwidth, high latency environments, where it is important to
   minimize communications consumption.  Such environments are not,
   however, the exclusive operating domains for every mobile computing
   device, and a device does not have to be among those types previously
   enumerated to be mobile.  Any classification of MCD's must also include
   desktop and docking laptop computers in wireless LAN environments,
   where mobility within a building or campus is provided by wireless
   Ethernet or similar technology.  It is also true that many mobile
   computing devices may be used in both wireless and wireline
   environments: change a network interface card (NIC) on many of these
   devices, and the MCD can operate over analog dial, ISDN, or in a LAN.

1.2 Design Goals

   Because of the diverse nature of Mobile Computing Devices, the
   communications environments over which they may operate, and the
   applications MCD's may provide, several design goals emerge.

   1) It is important to minimize communications consumption when low
   bandwidth, high latency networks are used by MCDs;



<draft-piscitello-mncp-00.txt>                                  Page 4


INTERNET DRAFT                   MNCP                   August 28, 1997


   2) Applications should operate well irrespective of wireless or
   wireline network characteristics; and

   3) It should be possible for certain classes of MCD's to operate in a
   disconnected state.

   4) It should be relatively simple for end users to change
   communications environments; optimally, an end user would be able to
   install the appropriate network interface and begin communicating over
   a different type of network.

   5) It is desirable to have a mechanism to allow subscriber
   identification and authentication to be IP address independent.

   6) It is desirable to minimize communications consumption for low
   bandwidth devices with limited battery life.

   7) Both mobile computing devices and mobility servers should be able to
   initiate communications and transfers of data; i.e., client initiated
   or pull" applications as well as server initiated or "push"
   applications should be accommodated.

   +----------+  +----------+  +-------+  +---------+
   | desktop  |  | handheld |  |  PDA  |  |  smart  |
   |    PC    |  |    PC    |  |       |  |  phone  |
   +----------+  +----------+  +-------+  +---------+
         |             |           |           |
   +------------------------------------------------+
   |                  Applications                  |
   +------------------------------------------------+
   |         mobile network computing middleware    |
   +------------------------------------------------+
   |        commercial UDP/IP implementation        |
   +------------------------------------------------+

   Mobile client applications will operate on wireless networks in a
   bandwidth-latency range where many commercial TCP's have insufficient
   tuning parameters to permit efficient operation.  Custom TCP's might be
   developed to accommodate the specific bandwidth-delay characteristics
   of wireless networks, but these custom TCP's would need to be installed
   in all networked hosts with which the user wishes to communicate, which
   is not practical.

   To meet the design goals enumerated, and to avoid situations where the
   end user would be responsible for reconfiguring TCP for each
   environment, or where the user might have to install a different TCP
   entirely to operate over a LAN or wireless WAN, we believe it is
   appropriate to build a middleware element that can operate on top of
   any commercial, off-the-shelf UDP/IP implementation.

   [Note: It is conceivable that a standard TCP could be adapted to
   satisfy the network transparency design goals.  The difficulty with
   this approach is that it will be some time before this can propagate
   into existing TCP implementations.  More importantly, the existing TCP


<draft-piscitello-mncp-00.txt>                                  Page 5


INTERNET DRAFT                   MNCP                   August 28, 1997


   architecture does not allow optimizations for minimizing communications
   consumption for low bandwidth devices with limited battery life, as
   will be described with MNCP.]

   These requirements suggest that important efficiencies can be achieved
   by adopting an agent-enabled, transmission independent messaging
   paradigm. This client-agent-server architecture allows for the
   introduction of increased efficiencies such as session level data
   compression.

   [Note: This client-agent-server relationship is euphemistically
   referred to as a thin-client architecture. However, it is appropriate
   to consider so-called thin clients as one of many, rather than the
   only, type of client accommodated by the MNC architecture.]

   +-----------+            +-------------+             +-------------+
   |  Mobile   |            |   Mobile    |             | Enterprise  |
   |  client   |            |   Agent/    |             |     or      |
   | (HPC,PDA, |            | application |             |  Internet   |
   |  laptop.) |            |   proxy     |             | application |
   |           |            |             |             |  server(s)  |
   +-----------+            +-------------+             +-------------+
         |                     |    |                         |
         |                     |    |        Internet or      |
         |___wireless network__|    |___Enterprise network____|

   In addition, client-server behavior and the "chatty" protocol behavior
   associated with client-server (web) interaction and transactions can be
   optimized by introducing a degree of parallelism, i.e., by adopting
   common service or "session layer" framing as well as application
   specific framing, on top of traditional transfer control framing.  In
   addition to the operational efficiencies introduced with this approach,
   mechanisms for providing reliable delivery over wireless technologies
   can be developed and applied in application, rather than TCP "kernel"
   and operating system, space.


1.3 Mobile Network Computing Architecture

   The Mobile Network Computing architecture consists of a middleware
   service component to support user registration and authentication, data
   transfer (with compression) and reliable delivery.  A diverse set of
   application service components may ride on top of this middleware, each
   providing application-specific services such as mobile (unified)
   messaging, paging, browsing, and remote database access.











<draft-piscitello-mncp-00.txt>                                  Page 6


INTERNET DRAFT                   MNCP                   August 28, 1997


         MCD             Mobility Server        External Server

     +--------------+                             +--------------+
   +-------------+  |    +--------------+       +-------------+  |
   |Client App(s)|--+    |  Appl Agent  |       |Server App(s)|--+
   +-------------+       +------+-------+       +-------------+
   |    MNCP     |       | MNCP | Other |       | Other Stack |
   +-------------+       +------+ Stack |       |(HTTP, SMTP, |
   |    UDP      |       | UDP  |(HTTP, |       |TCP/IP, etc) |
   +-------------+       +------+ SMTP, |       |             |
   |    IP       |       | IP   | TCPIP)|       |             |
   +-------------+--------------+-------+-------+-------------+
   |      Wireless Network      |      Wireline Network       |
   +----------------------------+-----------------------------+

   This internet-draft describes the Mobile Network Computing Protocol,
   which provides the services ascribed to the middleware component of the
   architecture.

1.4 Relationship of MNCP to other Internet Protocols

   MNCP is designed to be implemented on top of the Datagram protocol
   (UDP).  MNCP packets have an IP header, a UDP header, and an MNCP
   header.

         MCD                Mobility Server
     +--------------+         +--------------+  Server Apps can
   +-------------+  |       +-------------+  |  be Local or
   |Client App(s)|--+       |Server App(s)|--+  Distributed to
   +-------------+          +-------------+     External Server
   |    MNCP     |          |    MNCP     |
   +-------------+          +-------------+   +-----+-----+--------+
   |    UDP      |          |    UDP      |   | IP  | UDP | MNCP   |
   +-------------+          +-------------+   | Hdr | Hdr | Packet |
   |    IP       |          |    IP       |   +-----+-----+--------+
   +-------------+------------------------+      ^     ^
   |           Wireless Network           |      |     +- Src/DestPort
   +--------------------------------------+      |        Checksum
                                                 +- Src/Dest IP Address

   The source and destination address fields of the IP header are used by
   MNCP to identify the requesting and responding hosts.  For example, a
   request initiated by an MCD to a Mobility Server will carry the MCD's
   IP address in the source field and the Mobility Server's IP address in
   the destination field.

   The source and destination port fields of the UDP header are used by
   identify the requesting and responding MNCP's.  An MNCP implementation
   listens to an assigned "well known" UDP port number (to be assigned and
   recorded by IANA[2]) for incoming requests, and demultiplexes them to
   the appropriate application based upon Service ID (see Section 4.5.2).
   For example, a request initiated by a mobile messaging client
   application will carry the application's UDP port number in the source
   port field (selected from the range of values for UDP "ephemeral" or


<draft-piscitello-mncp-00.txt>                                  Page 7


INTERNET DRAFT                   MNCP                   August 28, 1997


   client ports) and the "well known" port number for MNCP in the
   destination port field.

   The UDP header length field reflects the total size of the MNCP packet.
   MNCP relies upon the UDP header's checksum field and error checking to
   protect the MNCP packet.  MNCP provides end-to-end acknowledgment,
   retransmission, flow control, and segmentation as needed to insulate
   supported applications from the diverse characteristics of the
   underlying mobile network.

   Client and server applications supported by MNCP are identified by a
   Service ID field carried in the first MNCP packet of each packet
   sequence.  In order to send or receive MNCP packets with a given
   Service ID, the MCD must register for that service with the Mobility
   Server.  The MNCP is responsible for authenticating the client and
   performing access control, based upon Subscriber ID and Password fields
   supplied by the MCD.  The MNCP relays messages between server
   applications and client applications currently registered for that
   Service ID.

1.5 Requirements
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119[5].

1.6 Terms
   This memo uses a number of terms to describe components of the MNCP.
   Other common terms are used as specified in RFC 1983[4].

   Mobile Computing Device (MCD)
     PDA, laptop, hand-held device, desktop PC, or other network computer
     connected via wireless technology to a Mobility Server.

   Mobility Server (MS)
     The system which acts as an application layer gateway or agent between
     MCDs and networked application services such as mobile messaging or
     web-enabled database access.

   Client Application
     An application located on an MCD which uses MNCP to communicate with
     Server Applications.

   Server Application
     An application conceptually located on a Mobility Server, but which
     may be physically distributed (i.e., a service-specific application
     gateway on the Mobility Server relays messages to and from a server
     application running on an external server).

   Packet
     The basic unit of MCNP communication, consisting of a structured
     sequence of octets matching the syntax defined in Sections 3-4 and
     transmitted over wireless networks connecting an MCD and its Mobility
     Server.



<draft-piscitello-mncp-00.txt>                                  Page 8


INTERNET DRAFT                   MNCP                   August 28, 1997


2. Protocol Overview
   This section provides a brief overview of each type of service,
   enumerating the features provided by each service.

   MNCP operates over the User Datagram Protocol, and relies on UDP
   protocol for protocol demultiplexing and data integrity . MNCP provides
   the following basic services:

   - A single packet (acknowledged datagram) reliable delivery service
     supports applications where a single datagram request and reply
     sequence is sufficient for application data transfer.

   - A multi-packet reliable delivery service supports applications
     requiring the reliable delivery of arbitrarily long data.

   - A set of registration and request/response correlation (message flow
     support) services collectively referred to as SESSION CONTROL.

   The MNC protocol consists of a message set of four basic packet types:
   COMMAND, NOTIFICATION, DATA, and ACKNOWLEDGE.  Reliable delivery and
   session control services are provided through the use of Information
   Elements (IE's) encoded in these four packet types.  The encodings of
   Information Elements for each packet type are described in sections 3
   and 4.

   The remainder of section 2 provides an overview of how MNCP provides
   data transfer and session control services to mobile applications.

2.1 Single Packet Reliable Delivery Service
   The single packet reliable delivery service is an acknowledged datagram
   service.  The service makes use of the COMMAND (PT_CMD) and ACKNOWLEDGE
   (PT_ACK) packets. The basic features of the service are:

   - Data transfer
   - Packet correlation
   - error detection and recovery using positive acknowledgment with
     retransmission based on timeout

   The single packet reliable delivery service is used when an application
   invokes the service with a request to send data, and a single MNCP
   datagram request and reply sequence is sufficient for application data
   transfer.  This is true when the total amount of data to be sent is
   less than or equal to the default packet size (470 octets).

   The MNCP constructs a COMMAND packet as follows.  Common header fields
   are populated as discussed in section 3.2. A correlation identifier
   value is chosen for the packet exchange by the MNCP and encoded in the
   COMMAND packet (see section 2.3.5).  Session Control information
   supplied by the application in the MNCP service request (service,
   function, and subscriber identifiers, and the subscriber password, see
   Section 2.3) are encoded in the packet header, along with any
   application-specific information elements supplied in the request.
   Application data are then appended to the header as "payload".



<draft-piscitello-mncp-00.txt>                                  Page 9


INTERNET DRAFT                   MNCP                   August 28, 1997


   The COMMAND packet is sent in a UDP packet to the well-known MNCP port
   (source UDP port value is assigned from UDP client space), and a retry
   timer is initiated by the sender.  If an acknowledgment is not received
   before the retry timer expires, the COMMAND packet is resent.  If a
   specified maximum number of retry attempts is exceeded and an
   ACKNOWLEDGMENT is not received, the failure is reported to the
   application.  If an ACKNOWLEDGMENT is received, a confirmation
   (delivery success or failure) is returned to the application.

   When a COMMAND packet is received, the MNCP parses the packet and
   composes and returns a ACKNOWLEDGMENT packet containing a negative ACK
   code if errors were detected.  Otherwise, the MNCP forwards the packet
   to the MNCP session control for processing (see section 2.3). If
   subscriber authentication and application service access control are
   successful, session control passes the contents of the data payload to
   the application service indicted in the header, and returns a positive
   acknowledgment to MNCP.  If authentication fails, or the subscriber is
   not authorized to use this application, session control will return a
   negative acknowledgment code to MNCP.  Upon reception of a response
   from session control, the MNCP composes and returns an ACKNOWLEDGMENT
   packet with a positive or negative ACK code (the ACK code may be
   negative, indicating a session control failure, such as an invalid
   subscriber identifier or password).

2.2 Multi-Packet Reliable Delivery Service
   The multi-packet reliable delivery service is used when an application
   attempts to send a message that is longer than the default packet size
   offered (see section 3.4), i.e., when the entire user data,
   uncompressed, cannot be transferred in a single packet.  The service
   makes use of the NOTIFICATION (PT_NTFN) DATA (PT_DATA) and ACKNOWLEDGE
   (PT_ACK) packets. The basic features of the service are:

   - Data Transfer
   - Packet correlation
   - Packet size selection
   - Data compression method selection
   - Error detection and recovery using positive acknowledgment with
     retransmission based on timeout
   - Flow control
   - Segmentation and reassembly
   - Data compression (when selected)

2.2.1 NOTIFICATION Packet Processing (Sender)
   When the multi-packet reliable delivery service is used, the MNCP
   constructs a NOTIFICATION packet to initiate a sequence of data
   packets.  The purpose of the NOTIFICATION packet is to convey to the
   receiver certain information regarding overall and compressed size of
   the data to be transferred, and to propose a data compression method
   and maximum packet size to use when transferring subsequent data in the
   context of this multi-packet transfer.

   The NOTIFICATION packet is always default packet size (470 octets) or
   less, and is constructed as follows. Common header fields are populated
   as discussed in section 3.2.  A correlation identifier value is chosen


<draft-piscitello-mncp-00.txt>                                 Page 10


INTERNET DRAFT                   MNCP                   August 28, 1997


   for the packet exchange by the MNCP (see section 2.3.5) and encoded in
   the NOTIFICATION packet.  The sequence number in the NOTIFICATION is
   set to an initial value of zero (all subsequent DATA packets within the
   same packet sequence are incremented sequentially by one).  The total
   (uncompressed) length of the application message to be sent is encoded
   in the packet as the Original Message Length.

   To increase network efficiency, the sender can propose to use a packet
   size larger than the default packet size.  For this version of the
   protocol, the maximum packet size that can be proposed is 2048 octets
   (see section 3.4).  The sender can also propose to use data
   compression, by specifying a compression method in the Data Compression
   Option.  Proposing a larger packet size and a data compression method
   are options in the MNCP.

   Session Control information supplied by the application in the MNCP
   service request (service, function, and subscriber identifiers, and the
   subscriber password, see Section 2.3) are encoded in the packet header,
   along with any application-specific information elements supplied in
   the request.

   The NOTIFICATION packet is sent in a UDP packet to the well-known MNCP
   port (source UDP port value is assigned from client space), and a retry
   timer is initiated by the sender.  If an ACKNOWLEDGMENT packet is not
   received before the retry timer expires, the NOTIFICATION packet is
   resent.  If a specified maximum number of retry attempts is exceeded
   and an ACKNOWLEDGMENT packet is not received, a failure is reported to
   the application (see section 5.6).

   If an ACKNOWLEDGMENT packet containing a positive ACK code is received,
   the sender begins transferring application data (see section 2.2.3).
   If the receiver has accepted an increased packet size, then the sender
   extracts the packet size specified in the ACKNOWLEDGMENT packet and
   uses this for subsequent message transfer.  The packet size indicated
   in the ACKNOWLEDGMENT packet may be equal to or less than the size
   proposed by the sender. If the sender has proposed a data compression
   method, a positive ACK code indicates that the receiver has agreed to
   the data compression option proposed by the sender in the NOTIFICATION
   packet being ACKed.

   The receiver may return a negative code to reject the compression
   method proposed in a NOTIFICATION packet, and may propose an
   alternative compression methods in the ACKNOWLEDGEMENT packet, to
   expedite the compression selection process. If the sender supports the
   data compression method proposed, the sender resends the NOTIFICATION,
   identifying the data compression proposed by the receiver in the
   ACKNOWLEDGMENT packet; alternatively, the sender may bid a new method.
   The receiver may again return a negative acknowledgment code to reject
   the proposed compression method, and (optionally) propose an
   alternative method.  This form of "bidding" continues until a mutually
   acceptable compression method is identified (no compression is a
   legitimate option).  The sender recognizes that compression selection
   has concluded when it receives an ACKNOWLEDGMENT packet containing a
   positive acknowledgment code.


<draft-piscitello-mncp-00.txt>                                 Page 11


INTERNET DRAFT                   MNCP                   August 28, 1997



   [NOTE: Under this compression selection scheme, the sending MNCP must
   compress the data using a particular algorithm before it sends the
   PT_NTFN in order to convey the compressed length.  This reflects
   current implementation practice.  This memo does not preclude the use
   and future specification of stream compression algorithms that could be
   more closely coupled with an underlying transmission service, to
   optimize performance.]

2.2.2 NOTIFICATION Packet Processing (Receiver)
   The MNCP parses an incoming NOTIFICATION packet and composes and
   returns a ACKNOWLEDGMENT packet containing a negative ACK code if
   errors were detected in the common header.  Otherwise, the receiver
   examines the NOTIFICATION packet to determine if the sender has
   proposed any options.  If the sender has proposed a packet size greater
   than the default packet size, the receiver may agree to use the larger
   packet size or it may propose an alternative size that is less than the
   size specified in the NOTIFICATION packet.  The receiver can propose a
   smaller packet size and still return a positive acknowledgment.

   If the NOTIFICATION proposes a data compression method that is not
   supported by the receiver, the receiver may reject the proposed data
   compression method and propose an alternative method in the
   ACKNOWLEDGMENT packet returned to the sender.  As described in section
   2.2.1, a form of "bidding" continues until both receiver and sender
   identify a mutually acceptable compression method.

   When processing associated with multi-packet reliable delivery is
   completed by the receiver, the MNCP forwards the NOTIFICATION packet to
   the MNCP session control for processing (see section 2.3).  Upon
   reception of a response from session control, the MNCP composes and
   returns an ACKNOWLEDGMENT packet with an ACK code indicating success or
   failure of session control processing.

2.2.3 Data Transfer (Sender)
   When the NOTIFICATION processing is completed, the MNCP attempts to
   transfer data.  The original application data submitted in the request
   is first compressed (if compression is selected), then segmented into a
   sequence of DATA packets containing data payloads of size {negotiated
   packet size - DATA packet header information}, i.e., when constructing
   a DATA packet, the MNCP attempts to create "n" packets of this fixed
   size.  The last segment of application data transferred in this
   sequence of DATA packets may contain fewer octets than the negotiated
   packet size minus the header.

   The processing and transmission of a sequence of DATA packets is as
   follows.  All packets in a sequence of DATA packets carry the same
   Correlation Identifier as the NOTIFICATION packet.  A Data Offset is
   encoded in each DATA packet to assist in the reassembly of the
   application message.  The first in a sequence of DATA packets has a
   Data Offset value of zero .  When compression is used, the sending MNCP
   will fill the first DATA packet to the maximum payload available with
   compressed data, otherwise, each packet is filled to the maximum
   payload available with a segment of the original uncompressed message.


<draft-piscitello-mncp-00.txt>                                 Page 12


INTERNET DRAFT                   MNCP                   August 28, 1997


   A sequence number is encoded in each DATA packet to assist in
   determining packet order.  The sequence number of the initial DATA
   packet in a sequence is set to one (1).

   For each additional DATA packet in the sequence, the Data Offset value
   represents the offset from the beginning of the transmitted data
   (hence, if the message was compressed before it was sent, the offset is
   relative to the beginning of the compressed message, not the original
   uncompressed message).  The sequence number value is incremented by one
   for each subsequent segment created.  The sequence number is not
   altered if a packet is retransmitted.

   Each packet in a sequence of DATA packets except the final DATA packet
   carries an indication that more DATA packets follow this packet.  The
   final DATA packet may contain less that the maximum data payload number
   of octets, and must not be padded.

   Each DATA packet is sent as a UDP packet to the source port which sent
   the last ACKNOWLEDGMENT packet, and a retry timer is initiated by the
   sender.  If an acknowledgment is not received before the retry timer
   expires, the DATA packet is resent.  If a specified maximum number of
   retry attempts is exceeded and an ACKNOWLEDGMENT is not received, the
   failure is reported to the application (see section 5.6).  If an
   ACKNOWLEDGMENT containing the sequence number of the DATA packet sent
   is received, the next DATA packet in the sequence is transmitted (out
   of sequence ACKNOWLEDGMENT packets are discarded). Upon reception of a
   positive ACKNOWLEDGMENT to the final DATA packet, a confirmation is
   provided to the sending application, indicating successful delivery.

2.2.4 Data Transfer (Receiver)
   When the receiver sends a positive ACKNOWLDEGMENT in response to a
   NOTIFICATION request, the receiving MNCP awaits the arrival of DATA
   packets.

   Reliable delivery of data is achieved through the use of a stop-and-go
   with timeout retransmission mechanism. Each DATA packet must be
   individually acknowledged by the receiving MNCP. The ACKNOWLEDGMENT
   packet must contain the same sequence number as the packet it is
   acknowledging.

   Out of sequence DATA packets (any packet with a previously acknowledged
   sequence number or a packet whose sequence number is greater than the
   next expected sequence number) are discarded by the receiving MNCP.  As
   part of the processing of out of sequence DATA packets, the receiving
   MNCP returns an ACKNOWLEDGEMENT packet containing the sequence number
   of the most recently acknowledged DATA packet.

   The receiver processes the incoming DATA packets as follows.  As part
   of the process of determining whether a properly composed DATA packet
   has arrived, the receiver checks to see if the correlation identifier
   in the packet corresponds to a transfer in progress; if the packet is
   incorrectly composed or the correlation identifier is unknown (not
   associated with a transfer in progress), the packet is discarded.  If
   the DATA packet is valid, the receiver uses the packet contents


<draft-piscitello-mncp-00.txt>                                 Page 13


INTERNET DRAFT                   MNCP                   August 28, 1997


   (correlation identifier, data offset, sequence number, more/final
   information, application data) and information relayed in the
   NOTIFICATION request (message length, compressed and uncompressed,
   compression method) to reassemble the application data.  The receiver
   composes and returns an ACKNOWLDEGEMENT packet containing the
   correlation identifier and sequence number from the DATA packet being
   acknowledged. The ACKNOWLEDGEMENT packet is sent as a UDP packet to the
   source port which sent the DATA packet being acknowledged.

   Reassembly of application data continues in this manner until a DATA
   packet containing a "final data" indicator is processed.  The
   reassembled data are uncompressed (if compression was used).
   Application-specific information elements are forwarded to the
   application, and a final ACKNOWLEDGEMENT packet is sent as a UDP packet
   to the source port which sent the DATA packet being acknowledged.

2.3 Session Control Service
   MNCP session control packets are exchanged between an MCD and a
   Mobility Server using MNCP reliable delivery packets.  The purpose of
   session control is to provide user validation (authentication),
   application access control, user registration (deregistration) for
   application services, and application request/response correlation.

2.3.1 Subscriber Validation
   User validation (authentication) is based on a subscriber identifier
   and subscriber password.  A subscriber identifier is assigned to the
   user of a mobile computing device, and is intended to be independent
   from any lower layer (e.g., IP) addressing or identification.  In
   particular, access controls to applications and services may be based
   on subscriber identification, allowing the subscriber to access these
   applications irrespective of the IP or equivalent network address the
   user of an MCD is (temporarily) using for communication with a Mobility
   Server.

   Applications and specific functions of applications that may be
   accessed by a user of a MCD (remotely invoked operations) are
   identified by a service identifier, which is globally unique and IANA-
   assigned, and a function identifier, which is service-specific.
   Application registration and deregistration are functions performed for
   all application services, and fall within session control, whereas
   other functions, such as a "check mailbox status" function, are
   specific to an application (mobile messaging), and are thus transparent
   to the MNCP.

2.3.2 Registration
   Registration is a process whereby a client (MCD) notifies a Mobility
   Server of its intent to make use of an application service.  An
   explicit form of registration is accomplished as follows.  Session
   control information (subscriber identification and authentication
   information, application service and function identification) is
   supplied by the client application to the MCD's MNCP and encoded as
   information elements in a REGISTRATION request (see also section 2.1).
   A registration request is sent by a client (MCD) MNCP using the single
   packet reliable delivery mechanism.


<draft-piscitello-mncp-00.txt>                                 Page 14


INTERNET DRAFT                   MNCP                   August 28, 1997



   The receiving MNCP (here, the Mobility Server) uses the subscriber
   identification and authentication information to validate the user and
   to determine whether the user has access privileges to the application
   service and function identified.  The receiving (MS) MNCP returns a
   positive or negative ACKNOWLEDGMENT based on the success or failure of
   authentication and access control processing.  If the authentication
   succeeds, the (MS) MNCP updates the status of the subscriber to
   "registered", records the IP address of the MCD from which the
   subscriber's registration request was initiated, and returns a positive
   ACKNOWLEDGEMENT.  The (MS) MNCP starts a timer that bounds the amount
   of time the registered subscriber may be inactive before the subscriber
   is declared unavailable (see sections 4.7 and section 6.4).

   [NOTE: Explicit registration may be used to enable "push" applications.
   Once a client application at an MCD is registered, an application at a
   Mobility Server may send unsolicited messages to the MCD.]

   A second, implicit form of registration occurs when an application at a
   Mobility Server receives requests for a service from a MCD that has not
   explicitly registered for that service.  If the subscriber
   identification and authentication are valid, and access to this service
   is permitted for this subscriber, the MS will register the client (MCD)
   as previously described, and process the service request (see section
   2.3.3 and section 3).

   Once a subscriber has registered, a Mobility Server will forward all
   subsequent subscriber-bound messages to the MCD at the IP address
   recorded, until the subscriber explicitly deregisters the service, or
   registers the service from another MCD, or from a different IP address.

2.3.3 Application Data Transfer
   Once registration is completed, applications at either the MCD or MS
   may begin sending requests. Session Control information (application
   service and function identification, subscriber identification and
   password, request/response message correlation information) accompany
   application-specific control information and data in each request.
   Each request (carried as a COMMAND packet or a NOTIFICATION packet
   initiating a multi-packet sequence) is authenticated.  If
   authentication succeeds and all the contents are reliably delivered, a
   positive ACKNOWLEDGEMENT is returned to the MCD MNCP. Application-
   specific IE's as well as data are forwarded to the application when the
   entire request has been delivered.

2.3.4 Deregistration
   Deregistration may be initiated by the MCD application.  A request to
   deregister from an application service results in the transmission of a
   DEREGISTER function by session control to the Mobility Server's (MS)
   MNCP.  Deregistration can also occur when an inactivity timer operating
   at the Mobility Server expires.  When either of these events occurs,
   the (MS) MNCP deregisters the subscriber (i.e., changes the
   registration status to deregistered for the application service
   indicated in the request).  The MNCP requesting deregistration (either



<draft-piscitello-mncp-00.txt>                                 Page 15


INTERNET DRAFT                   MNCP                   August 28, 1997


   the MCD or MS) composes and sends a Deregistration request and awaits
   an indication from reliable transfer that

   (a) the MCD MNCP has responded with an ACKNOWLDGEMENT indicating it
   wishes to continue communicating with the server.  In this case, the
   (MS) MNCP updates the registration status of the client (to
   registered).

   (b) the (MCD or MS) MNCP has responded with an ACKNOWLEDGEMENT
   indicating it agrees to discontinue communication.  In this case, the
   requesting MNCP remains in an unregistered (i.e., inactive) status.

   (c) retry timer expiration causes the reliable delivery MNCP to
   indicate to session control that communication attempts have been
   abandoned. In this case, the  requesting MNCP remains in an
   unregistered (i.e., inactive) status.

2.3.5 Correlation Identifiers
   The correlation identifier is used by Session Control to associate
   packets (or packet sequences) of a given exchange, and is relevant for
   both directions of information flow (i.e., the acknowledgment for a
   NOTIFICATION, COMMAND, and DATA packet must have the same correlation
   identifier) for the duration of that exchange.  The correlation
   identifier has local significance to the mobile computing device or
   Mobility Server.

   Applications may use a Correlation Identifier value to link together or
   "cross-correlate" packet sequences related to the same application-
   specific message flow.  Consider an e-mail client application request
   from a MCD to retrieve mailbox messages.  The request could be
   satisfied using a single COMMAND-ACK sequence.  The corresponding
   responses could be conveyed as a packet sequence involving the use of
   the NOTIFICATION service initiated by a messaging application operating
   on a Mobility Server.  The Cross-correlation Identifier value used by
   the Mobility Server when delivering the contents of the mailbox to the
   email client must be the same as the Correlation Identifier of the
   original request to retrieve mailbox messages (see section 4.5.5).

3. MNCP Reliable Delivery Packets
   This section defines the packets which support MNCP reliable delivery
   services.

3.1 Packet Types
   MNCP reliable delivery packets are exchanged between an MCD and a
   Mobility Server.  There are four types of MNCP reliable delivery
   packets, differentiated by the Packet Type field in the Packet Header.

   Command Packet (PT_CMD)
     This packet is used when the entire length of the application data can
     be carried in a single packet.






<draft-piscitello-mncp-00.txt>                                 Page 16


INTERNET DRAFT                   MNCP                   August 28, 1997


   Notification Packet (PT_NTFN)
     This packet is used when the entire length of the user data can not
     fit into a single packet.  It is followed by one or more PT_DATA
     packets.

   Data Packet (PT_DATA)
     This packet is used in conjunction with the Notification Packet to
     carry the actual application data.

   Acknowledge Packet (PT_ACK)
     This packet is used to confirm receipt of a PT_CMD, PT_NTFN, or
     PT_DATA packet by the peer MNCP.

   MNCP reliable delivery packets PT_CMD, PT_NTFN, and PT_DATA can
   originate from either the MCD or the Mobility Server.  Acknowledgments
   (PT_ACKs) are returned by the recipient of the other packets.

   Exactly one MNCP reliable delivery packet is encapsulated in each UDP
   Information field as an octet sequence, encoded in network-byte order.

3.2 Packet Headers
   The following common header fields appear in every MNCP reliable
   delivery packet.  A summary of the packet header format is shown below.
   The bits are transmitted in network-byte order, from left to right.

   0                   1                   2
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Major Version | Minor Version |  Packet Type  | ..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2           3                   4                   5
   4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Correlation Id           |       Sequence Number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Major and Minor Protocol Version
     Two one octet Protocol Version fields identify the Major and Minor
     Version level of the MNCP packet.  The values (1,1) MUST be used to
     indicate the MNCP protocol version specified by this memo.  When a
     packet is received with an unknown Protocol Version value, the packet
     SHOULD be silently discarded.

   Packet Type
     The Packet Type field is one octet, and identifies the type of MNCP
     reliable delivery packet as enumerated below.

            1       PT_CMD      Command
            2       PT_NTFN     Notification
            3       PT_DATA     Data
            4       PT_ACK      Acknowledge

     When a packet is received with an unknown Packet Type value, the
     packet SHOULD be silently discarded.


<draft-piscitello-mncp-00.txt>                                 Page 17


INTERNET DRAFT                   MNCP                   August 28, 1997



   Correlation Id
     The Correlation Id field is two octets, and is used to link together
     all the packets in a particular packet sequence.  When initiating a
     new packet sequence, applications at a Mobility Server MUST select
     values in the range h0001 - h7FFF (i.e., the most significant bit must
     be zero, 0).  When initiating a new packet sequence, applications at a
     MCD MUST select values in the range h8000-hFFFF (i.e., the most
     significant bit must be one, 1).  The value zero is reserved and MUST
     NOT be used.

     When a PT_DATA or PT_ACK packet is received with an unknown
     Correlation Identifier field, or any other type of packet is received
     with a missing Correlation Identifier field, the packet SHOULD be
     silently discarded.

     The MNCP that initiates a packet sequence (i.e., sends a PT_CMD or
     PT_NTFN packet) MUST ensure that the Correlation Identifier value
     uniquely identifies the packet sequence locally (i.e., no other packet
     sequence is in progress involving this MCD and the same Correlation
     Identifier value).  All other packets in this packet sequence
     (including PT_ACKs) MUST carry this same Correlation Identifier value.

     Applications may use the same Correlation Identifier value to link
     together packet sequences related to the same application-specific
     message flow.  For example, an e-mail client request might be conveyed
     by a PT-CMD packet sequence, with mail server responses conveyed as
     PT-NTFN packets sequences, all of which carry Cross Correlation
     Identifiers equal to the Correlation Identifier of the original
     request.

   Sequence Number
     The Sequence Number field is two octets, and is used to maintain
     sequencing of packets. When a packet is received with a missing or
     unknown Sequence Number field, the packet SHOULD be silently
     discarded.

     The sequence number MUST have the value zero (0) for the first packet
     of a packet sequence.  The sequence number contained in each
     subsequent PT_DATA packet within the same packet sequence MUST be
     incremented sequentially by one (1) until the maximum field value
     (65,536) has been reached, and then recycled back to zero(0).

3.3 Packet Body
   The body an MNCP packet is used to carry MNCP reliable delivery control
   information, session control information, and application-specific
   data.  The MNCP packet body is transmitted immediately after the MNCP
   packet header, beginning at bit 56 of the entire MNCP reliable delivery
   packet.







<draft-piscitello-mncp-00.txt>                                 Page 18


INTERNET DRAFT                   MNCP                   August 28, 1997


   5       6                   7                   8
   6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           MNCP Packet Body (1..N Information Elements)         ..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The MNCP reliable delivery packet body consists of one or more
   Information Elements (IEs).  Each Information Element consists of an IE
   Type field, IE Length field, and a variable-length data field (content
   determined by the IE Type, length identified by the IE Length).  There
   are two Information Element formats: an extended length format used
   only for IE_DATA_MORE and IE_DATA_FINAL elements, and an abbreviated
   format used for all other currently-defined IE Types.

   A summary of the Information Element field format is shown below.  The
   fields are transmitted in network-byte order, from left to right,
   beginning with the first available bit after the MNCP packet header or
   preceding Information Element.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IE Type=Other |  IE Length    | IE Data (1..N octets)          ..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 OR
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IE Type=DATA  |          IE Length            |IE Data(1..N oct)..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IE Type
     The IE Type field is one octet, and identifies the type of Information
     Element as enumerated below.

            5       IE_DATA_FINAL          Data (Final)
            6       IE_DATA_MORE           Data (More)
            8       IE_MSG_LENGTH          Message Length
            10      IE_ACK_CODE            Acknowledge Code
            16      IE_DATA_COMPRESSION    Data Compression
            18      IE_DATA_OFFSET         Data Offset
            20      IE_PKT_SIZE            Packet Size

     Additional IE Type values are defined by MNCP Session Control (see
     Section 4.5) and may also be defined for use by specific applications
     (to be assigned and recorded by IANA[2]).  When a packet is received
     with an unknown IE Type value, the Information Element SHOULD be
     forwarded to the application without further interpretation by the
     MNCP.

   IE Length
     If the IE Type equals IE_DATA_MORE or IE_DATA_FINAL, the IE Length
     field is two octets; otherwise, the IE Length field is one octet.  The
     IE Length field indicates the length of the information element data
     field, in octets.



<draft-piscitello-mncp-00.txt>                                 Page 19


INTERNET DRAFT                   MNCP                   August 28, 1997


     Octets beyond the range of the IE Length field are treated as a
     separate Information Element.  When a packet is received with an
     invalid Length field, the packet SHOULD be silently discarded.

   IE Data
     The format of the IE Data field varies according to IE Type.  The
     format associated with each IE Type is defined in Sections 3.5 and
     4.5.

   When encoding MNCP packets, the following general rules apply, in order
   of priority.

     - Required IEs MUST appear before optional IEs, and
     - Fixed-length IEs MUST appear before variable-length IEs.

3.4 Packet Length
   The length of each MNCP reliable delivery packet is the sum of the
   following:

     MNCP Header Length       7 octets
     MNCP Body Length         sum of Information Element lengths

   When IE Type is IE_DATA_MORE or IE_DATA_FINAL, the length of the
   Information Element is three(3) octets plus the value specified by the
   IE Length field.  Otherwise, the length of the Information Element is
   two (2) octets plus the value specified by the IE Length field.  Since
   every MNCP reliable delivery packet contains at least one Information
   Element, the minimum length of a packet is 10 octets.

   The maximum length of an MNCP packet, MAX_PACKET_SIZE, is limited to
   2048 octets.  The default packet size, DEFAULT_PACKET_SIZE, is 470
   octets, chosen because it is the most efficient size that can be
   transported by UDP over wireless Mobitex networks.  In order to
   increase network efficiency, the sending MNCP may propose a packet
   length greater than DEFAULT_PACKET_SIZE, but less than or equal to
   MAX_PACKET_SIZE.  The receiving MNCP may accept the proposed value or
   request a smaller packet length.  The selection of an appropriate
   packet size is affected by factors such as the Maximum Transmission
   Unit (MTU) and Maximum Segment Size (MSS) of the underlying network.

   When an application message is longer than the negotiated packet size
   (less header and protocol control information overhead), it MUST be
   segmented into more than one MNCP reliable delivery packet.  In this
   case, the length of the complete application message is indicated by
   the IE_MSG_LENGTH Information Element included in the PT_NTFN packet
   (see Section 3.5.2).

3.5 Information Elements
   Each Information Element includes IE Type and IE Length fields,
   formatted as described in Section 3.3.  Information Elements related to
   reliable transfer are defined below; additional elements related to
   session control are defined in Section 4.5.




<draft-piscitello-mncp-00.txt>                                 Page 20


INTERNET DRAFT                   MNCP                   August 28, 1997


   When a packet is received with a syntactically invalid Information
   Element, the packet MUST be acknowledged with the Ack Code
   ACK_ERR_INFO. When a packet is received without a required Information
   Element, the packet MUST be acknowledged with the Ack Code
   ACK_ERR_PROT.

3.5.1 Data (Final and More)
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T=IE_DATA_FINAL| Length=1..N                 | Data (1..N) ..
   |or IE_DATA_MORE| where N = (MAX_PACKET_SIZE - header length)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Data
     The Data field is variable length, ranging from one to
     (MAX_PACKET_SIZE - header) octets, and carries application-dependent
     content.

     The IE Type MUST equal IE_DATA_FINAL if the data field contains the
     only or final segment of an application message.  Otherwise, the IE
     Type MUST equal IE_DATA_MORE, indicating that the remainder of the
     application message will be sent in subsequent PT_DATA packets.

     In a PT_DATA packet, the content of the data field may be compressed
     (see Section 3.5.4).

3.5.2 Message Length
   0                   1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T=IE_MSG_LENGTH| Length=8      |..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1       2                   3                   4
   6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Original Message Length                     |..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4   5                   6                   7
   8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Compressed Message Length                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Original Message Length
     The Original Message Length field is four octets, and identifies the
     length, in octets, of the original application message to be
     transferred during an MNCP reliable delivery packet sequence.
     Providing this value allows the receiving MNCP to allocate adequate
     buffer space in which to build the decompressed message.

   Compressed Message Length
     The Compressed Message Length field is four octets, and identifies the
     length, in octets, of the same application message after compression.


<draft-piscitello-mncp-00.txt>                                 Page 21


INTERNET DRAFT                   MNCP                   August 28, 1997


     This indicates the number of data octets to be carried by the sequence
     of PT_DATA packets which follow this PT_NTFN packet, and may equal
     Original Message Length if no compression algorithm has been
     negotiated.  Providing this value allows the receiving MNCP to
     allocate adequate buffer space in which to reassemble the compressed
     message.

3.5.3 Acknowledge Code
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Typ=IE_ACK_CODE| Length=2      |           Ack Code            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Ack Code
     The Ack Code field is two octets, and indicates success or failure of
     MNCP packet processing.  Values associated with reliable transfer
     processing are enumerated below; additional session control-related
     values are enumerated in Section 4.5.6.

            ACK_OK            0  Success, no error
            ACK_ERR_MCD       1  Unrecognized MCD
            ACK_ERR_FILE_IO   9  Storage or File I/O error
            ACK_ERR_INFO     11  Invalid parameters/command syntax
            ACK_OOS_COMPRESS 12  Compression method not supported
            ACK_ERR_PROT     13  Protocol Error
            ACK_ERR_SYS   65535  Unrecoverable System Error


3.5.4 Data Compression
   0                   1                   2
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T=IE_DATA_COMP | Length=1      |  Compression  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Compression
     The Compression field is one octet, and identifies the compression
     method to be used on the data contained within PT_DATA packet
     IE_DATA_MORE and IE_DATA_FINAL information elements, as enumerated
     below.

            COMPRESS_OFF      0  Data MUST NOT be compressed
            COMPRESS_DEFAULT  1  Data MUST be compressed using default
                                 method, LZS, as defined by RFC 1974[3]

     Additional values for this field may be assigned and recorded by
     IANA[2].  Section 5.8 describes how this field is used for negotiation
     in PT_NTFN and PT_ACK packets.







<draft-piscitello-mncp-00.txt>                                 Page 22


INTERNET DRAFT                   MNCP                   August 28, 1997


3.5.5 Data Offset
   0                   1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T=IE_DATA_OFF  | Length=8      |..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1       2                   3                   4
   6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Data Offset                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Data Offset
     The Data Offset field is four octets.  When uncompressed data are
     sent, Data Offset identifies the offset, in octets, of the first bit
     of the IE_DATA_MORE or IE_DATA_FINAL Data field from the beginning of
     the original uncompressed message.  When compression is used, Data
     Offset identifies the offset, in octets, of the first bit of the
     IE_DATA_MORE or IE_DATA_FINAL Data field from the beginning of the
     compressed message.

3.5.6 Packet Size
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Typ=IE_PKT_SIZE| Length=2      |          Packet Size          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet Size
     The Packet Size field is two octets, and identifies the maximum size
     (in octets) for PT_DATA packets in this MNCP packet sequence.  Section
     5.7 describes how this field is used for negotiation in PT_NTFN and
     PT_ACK packets and how it affects segmentation of application data in
     PT_DATA packets.

     The default value for this field is DEFAULT_PACKET_SIZE (470 octets).
     The maximum value for this field is MAX_PACKET_SIZE (2048 octets).  If
     this field is absent from a PT_NTFN packet, the default value MUST be
     assumed.

3.6 PT_CMD
   When an application wishes to send a message that is shorter than
   (DEFAULT_PACKET_SIZE - header) octets, uncompressed, the MNCP MUST
   embed it in the IE_DATA_FINAL field of a PT_CMD packet.

   Upon reception of a correctly-formed PT_CMD packet, a PT_ACK MUST be
   transmitted, containing a positive or negative Ack Code as described in
   Section 3.7.

   The following IEs are optional in a PT_CMD packet.

     IE_DATA_FINAL              As defined in Section 3.5.1
                                MUST be present if application data
                                has been supplied by the user.


<draft-piscitello-mncp-00.txt>                                 Page 23


INTERNET DRAFT                   MNCP                   August 28, 1997



   Additional session control or application-specific IEs may also be
   included in the PT-CMD packet.

3.7 PT_ACK
   Upon reception of a correctly-formed PT_CMD, PT_NTFN, or PT_DATA
   packet, a PT_ACK MUST be transmitted to confirm delivery.  The PT_ACK
   includes the same Correlation ID and Sequence Number as the packet to
   be confirmed, and an Ack Code to indicate the success or failure of
   packet processing within the MNCP.

   The following IE is required in a PT_ACK packet.

           IE_ACK_CODE          As defined in Section 3.5.3

   Additional session control IEs and application-specific IEs may also be
   included in the PT_ACK packet.

3.8 PT_NTFN
   When an application wishes to send a message that is longer than
   (DEFAULT_PACKET_SIZE - header) octets, uncompressed, the MNCP MUST
   generate a PT_NTFN packet to initiate a sequence of PT_DATA packets.

   Upon reception of a correctly-formed PT_NTFN packet, a PT_ACK MUST be
   transmitted, containing a positive or negative Ack Code as described in
   Section 3.7.

   The following IEs are required in a PT_NTFN packet.

           IE_MSG_LENGTH        As defined in Section 3.5.2

   The following IEs are optional in a PT_NTFN packet.

           IE_DATA_COMPRESSION  As defined in Section 3.5.4
                                MUST be present if compression desired
                                otherwise default value assumed

           IE_PKT_SIZE          As defined in Section 3.5.6
                                MUST be present if long packets desired
                                otherwise default value assumed

   Additional application-specific IEs may also be included in the PT-NTFN
   packet.

3.9 PT_DATA
   When an application wishes to send a message that is longer than
   (DEFAULT_PACKET_SIZE - header) octets, uncompressed, the MNCP generates
   a sequence of PT_DATA packets to carry message segments.  The final
   PT_DATA packet carries the information element IE_DATA_FINAL; all
   others carry the information element IE_DATA_MORE.  These packets carry
   the same Correlation ID and sequentially-assigned Sequence Numbers.





<draft-piscitello-mncp-00.txt>                                 Page 24


INTERNET DRAFT                   MNCP                   August 28, 1997


   Upon reception of each correctly-formed PT_DATA packet, a PT_ACK MUST
   be transmitted, containing a positive or negative Ack Code as described
   in Section 3.7.

   The following IEs are required in a PT_DATA packet.

           IE_DATA_OFFSET       As defined in Section 3.5.5
           IE_DATA_MORE or
           IE_DATA_FINAL        As defined in Section 3.5.1

4. MNCP Session Control Packets
   This section defines the packets which support MNCP session control
   services.

4.1 Packet Types
   MNCP session control packets are exchanged between an MCD and a
   Mobility Server using MNCP reliable delivery packets. There are three
   types of MNCP session control packets, differentiated by the Function
   ID field of the IE_APP_ID information element in the MNCP session
   control header.

   Registration Packet (PT_CMD, Function ID = FUN_REG_REQ)
     This packet is used to register a Subscriber to use the specified
     Service.

   Deregistration Packet (PT_CMD, Function ID = FUN_DEREG_REQ)
     This packet is used to deregister a Subscriber so that it can no
     longer use the specified Service.

   Application Request Packet (PT_CMD or PT_NTFN, Function ID = other)
     This packet is used to request an application-specific service,
     specified by Service ID and Function ID.

   Registration packets originate from the MCD, to be processed and
   acknowledged by the Mobility Server.  Deregistration and Application
   Request packets can be initiated by either the MCD or Mobility Server.

   Exactly one MNCP session control packet is conveyed by each PT_CMD or
   PT_NTFN packet, utilizing those fields previously defined for MNCP
   reliable delivery, and the additional Session Control fields defined in
   this section.

4.2 Session Control Headers
   Information Element types defined specifically for use as MNCP Session
   Control header fields are enumerated below and defined in Section 4.5.

            1       IE_SUB_ID              Subscriber ID
            3       IE_APP_ID              Application ID
            9       IE_SUB_PWD             Subscriber Password

   These Information Elements are mandatory in every MNCP session control
   packet, regardless of Service ID or Function ID, and may appear
   anywhere within the list of Information Elements in an MNCP packet.



<draft-piscitello-mncp-00.txt>                                 Page 25


INTERNET DRAFT                   MNCP                   August 28, 1997


4.3 Session Control Body
   Information Element types defined specifically for use as MNCP Session
   Control body fields are enumerated below and defined in Section 4.5.

           11      IE_REG_STATUS          Registration Status
           24      IE_CROSS_ID            Message Cross-correlation ID

   These Information Elements may be included in certain MNCP session
   control packets, as determined by Function ID, and may appear anywhere
   within the list of Information Elements in an MNCP packet.

4.4 Packet Length
   The length of the MNCP session control packet can be computed as  the
   sum of the lengths of each session control Information Element.

4.5 Information Elements
   Each Information Element includes IE Type and IE Length fields,
   formatted as described in Section 3.3.  Information Elements related to
   reliable transfer are defined in Section 3.5; additional elements
   related to session control are defined below.

4.5.1 Subscriber ID
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=IE_SUB_ID | Length=1...N  |  Subscriber ID (1..N octets)  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subscriber ID
     The Subscriber ID field is variable length, and identifies the user of
     the MCD.  This value is used by MNCP Session Control to provide
     subscriber validation/authentication (see Section 7).


4.5.2 Application ID
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=IE_APP_ID | Length=2      |  Service ID   |  Function ID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Service ID
     The Service ID field is one octet, and identifies the Information
     Service (specific application) involved in this MNCP packet sequence.
     This field identifies both the application which originated the
     message and the destination application that is to receive the
     message.

     Service ID values are assigned and recorded by IANA[2] for use by
     specific applications.  Service ID is used by MNCP Session Control to
     provide service registration, deregistration, and filtering features.





<draft-piscitello-mncp-00.txt>                                 Page 26


INTERNET DRAFT                   MNCP                   August 28, 1997


   Function ID
     The Function ID field is one octet, and identifies the function within
     the specified Service requested by this MNCP packet, as enumerated
     below.

            0         FUN_DEREG_REQ       Deregistration Request
            1         FUN_REG_REQ         Registration Request
            2..255    TBD                 Application-Dependent

     Function ID values zero (0) and one (1) are reserved for use by  MNCP
     Session Control.  Function ID values 2 through 255 are application-
     dependent, and are transparent to the MNCP.

4.5.3 Subscriber Password
   0                   1                   2
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=IE_SUB_PWD| Length=4..N   |Subscriber Password(4..N octets)..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subscriber Password
     The Subscriber Password field is variable length, ranging from four to
     N octets, and carries a value used by MNCP Session Control for user
     validation/authentication (see Section 7).

4.5.4 Registration Status
   0                   1                   2           9
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 . . 0 1 2 3 4 5 6
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T=IE_REG_STATUS| Length=1..N  |Registration Status(1..N octets)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Registration Status
     The Registration Status field is a variable length field, where each
     octet contains the ID of a Service for which this Subscriber is
     currently registered.

4.5.5 Message Cross-Correlation ID
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Typ=IE_CROSS_ID| Length=2      |     Cross Correlation ID      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Cross-correlation ID
     The Message Cross-correlation ID is two octets, and carries a 16-bit
     unsigned integer number identifying the correlation ID of a previous
     message flow to which the current message flow is associated. Using a
     cross-correlation identifier, a receiving application correlates a
     response message with a previous request message.

4.5.6 Acknowledge Code
   MNCP Session Control defines additional values for the Ack Code field
   specified in Section 3.5.3.


<draft-piscitello-mncp-00.txt>                                 Page 27


INTERNET DRAFT                   MNCP                   August 28, 1997



            ACK_ERR_SID       2  Unrecognized Subscriber ID
            ACK_ERR_PWD       3  Incorrect Password
            ACK_OOS_SID       5  Subscriber ID is suspended
            ACK_OOS_SVC      10  Application service unavailable

4.6 FUN_REG_REQ
   When an application wishes to explicitly register for a specific
   Service ID (see section 2.3.2), it MUST first generate a Registration
   Request by issuing a PT_CMD packet with the desired Service ID and
   Function ID set to FUN_REG_REQ.

   Upon reception of a Registration Request, MNCP session control performs
   authentication based upon Service ID, Subscriber ID, and Password,
   marking the subscriber as "registered" and recording the IP address of
   the MCD from which the request was received if the subscriber is
   determined to be authentic and authorized to use the service.  A PT_ACK
   MUST be transmitted in response, containing a positive or negative Ack
   Code as described in Section 4.5.6.  In addition, as an implementation
   option, the PT_ACK MAY contain the IE_REG_STATUS Information Element
   described in Section 4.5.4.

4.7 FUN_DEREG_REQ
   When an application wishes to stop using a specific Service ID, it may
   generate a Deregistration Request by issuing a PT_CMD packet with the
   desired Service ID and Function ID set to FUN_DEREG_REQ.

   The MCD MNCP MAY deregister from a service by generating a
   Deregistration Request, either implicitly on behalf of the application,
   explicitly upon application request, or both. Upon receiving an MCD-
   initiated Deregistration Request, the MS MNCP session control performs
   authentication based upon Service ID, Subscriber ID, and Password,
   marking the subscriber as "deregistered" if authorized to use the
   service.  A PT_ACK MUST be transmitted in response, containing an Ack
   Code as described in Section 4.5.6.

   An MS MNCP that has not detected activity on the part of a registered
   subscriber for a given period of time (INACTIVITY_TIMER) MAY attempt to
   deregister the subscriber implicitly by generating a Deregistration
   Request.  Upon receiving an MS-initiated Deregistration Request, the
   MCD MNCP determines whether the application identified by the service
   ID is still running. If so, the MCD MNCP MUST return a PT_ACK (ACK_OK)
   and the MS MNCP MUST re-register the subscriber.  Otherwise, the MCD
   MNCP returns a PT_ACK  (ACK_OOS_SVC) and the MS interprets this as a
   confirmation that the application service is no longer running on the
   subscriber's MCD.

   In addition, as an implementation option, these PT_ACKs MAY contain the
   IE_REG_STATUS Information Element described in Section 4.5.4.  As a
   security precaution, this field SHOULD NOT be included when
   acknowledging a Deregistration Request that has not passed
   authentication.




<draft-piscitello-mncp-00.txt>                                 Page 28


INTERNET DRAFT                   MNCP                   August 28, 1997


4.8 FUN_<other>
   When an application wishes to send a request with a specific Service
   ID, it MUST generate an Application Request by issuing a PT_CMD or
   PT_NTFN packet with the desired Service ID and Function ID.

   Upon reception of an Application Request, and if the subscriber is
   currently registered to use the service, MNCP session control performs
   authentication based upon Service ID, Subscriber ID, and Password, and
   forwards the request to the destination application.

   If the subscriber is not currently registered to use the service, MNCP
   session control performs authentication based upon Service ID,
   Subscriber ID, and Password.  If the subscriber is determined to be
   authentic and permitted to access the service, MNCP session control
   marks the subscriber as "registered" and forwards the request to the
   destination application (implicit registration).

   For either case, a PT_ACK MUST be transmitted in response, containing a
   positive or negative Ack Code as described in Section 4.5.6.  A
   positive Ack Code indicates that the request can be delivered to the
   destination application; a negative Ack Code indicates why the request
   cannot be delivered.

5. MNCP Reliable Delivery Processing

5.1 Phase Diagram
   MNCP reliable delivery goes through three distinct phases which are
   specified in the following simplified diagram.

      +------+                                   +---------------+
      |      | PT_CMD                            |               |
      |      |---------------------------------->|               |
      | Idle |           +-------------+         | Data Transfer |
      |      | PT_NTFN   |             | PT_DATA |               |
      |      |---------->| Negotiation |-------->|               |
      |      |        ^  |             |      ^  |               |
      +------+        |  +-------------+      |  +---------------+
         ^  PT_ACK(C) |    |        |         |    |          |
         |    or TMO  <----+        |    TMO  <----+          |
         <--------------------------+-------------------------+
           PT_ACK(OK), PT_ACK(ERR), or TMO & retries exhausted

         TMO        = timeout expires
         PT_ACK(C)  = PT_ACK (ACK_OOS_COMPRESS) received
         PT_ACK(OK) = PT_ACK (ACK_OK) sent/received for final packet
         PT_ACK(ERR)= PT_ACK (any other IE_ACK_CODE) sent/received

   Idle Phase
     The MNCP necessarily begins and ends with this phase.  When an
     application or session control request causes a PT_NTFN packet to be
     sent or received, the MNCP proceeds to the Negotiation phase.  When an
     application or session control request causes a PT_CMD packet to be
     sent or received, the MNCP proceeds to the Data Transfer phase.



<draft-piscitello-mncp-00.txt>                                 Page 29


INTERNET DRAFT                   MNCP                   August 28, 1997


     The MNCP returns to the Idle phase automatically if:

     - the ack timeout expires while waiting for any packet (i.e., packet
      lost or silent discard of badly-formed packet) and all retries have
      been exhausted;

     - a PT_ACK packet with IE_ACK_CODE equal to ACK_OK is sent or received
      confirming the final packet in a packet sequence (i.e., confirming a
      PT_DATA packet that contained an IE_DATA_FINAL element); or

     - a PT_ACK packet with IE_ACK_CODE not equal to ACK_OK is sent, or a
      PT_ACK packet with IE_ACK_CODE not equal to ACK_OK or
      ACK_OSS_COMPRESS is received.

   Negotiation Phase
     The MNCP enters this phase when sending or receiving a PT_NTFN packet.

     The receiving MNCP processes the incoming packet and returns a
     positive or negative PT_ACK as follows.

     - If the PT_ACK is negative, the receiver returns to the Idle phase.

     - If the PT_ACK is positive, the receiver enters the Data Transfer
      phase.

     The sending MNCP awaits and processes the PT_ACK.

     - If the PT_ACK is positive, the sender enters the Data Transfer
      phase.

     - If the PT_ACK indicates ACK_OSS_COMPRESS, the sender SHOULD retry
      sending the PT_NTFN with a different compression method and remain
      in the Negotiation phase.

     - Otherwise, the sender returns to the Idle phase.

     Any locally-initiated application request received during this phase
     MUST NOT be processed by this MNCP instance until the Idle Phase is
     re-entered.  Such requests MAY be rejected or buffered locally by the
     implementation.

   Data Transfer Phase
     The MNCP enters this phase when sending or receiving a PT_CMD or
     PT_DATA packet.

     The receiving MNCP processes the incoming packet and returns a
     positive or negative PT_ACK as follows.

     - If the PT_ACK is negative or confirms receipt of a packet containing
      an IE_DATA_FINAL element, the receiver returns to the Idle phase.

     - Otherwise (confirming PT_DATA packet with IE_DATA_MORE), the
      receiver remains in the Data Transfer phase.



<draft-piscitello-mncp-00.txt>                                 Page 30


INTERNET DRAFT                   MNCP                   August 28, 1997


     The sending MNCP awaits and processes the PT_ACK.

     - If PT_ACK is negative or the outgoing packet contained an
      IE_DATA_FINAL element, the sender returns to the Idle phase.

     - Otherwise (PT_ACK confirmed packet containing IE_DATA_MORE), the
      sender remains in the Data Transfer phase and sends the next PT_DATA
      packet.

     Any locally-initiated application request received during this phase
     MUST NOT be processed by this MNCP instance until the Idle Phase is
     re-entered.  Such requests MAY be rejected or buffered locally by the
     implementation.

5.2 State Diagram
   The MNCP reliable delivery finite-state automaton is defined by events,
   actions and state transitions.  Events include reception of application
   requests, expiration of the Ack timer, and reception of packets from a
   peer.  Actions include the starting of the timers and transmission of
   packets to the peer.

   Events                                 Actions

   REQ = Receive Application Request      scm = send PT_CMD
   RCM = Receive PT_CMD                   snt = send PT_NTFN
   RNT = Receive PT_NTFN                  fsc = fwd to Session Control
   RSP = Receive Session Response         sak = send PT_ACK
   RAK = Receive PT_ACK                   sdt = send PT_DATA
   RDT = Receive PT_DATA                  sto = start timers
   TMO = Ack Timeout                      ind = send Appl Indication
                                          cnf = send Appl Confirm

   The complete state transition table follows.  States are indicated
   horizontally, and events are read vertically.  State transitions and
   actions are represented in the form action/new-state.  Multiple actions
   are separated by commas, and may continue on succeeding lines as space
   requires; multiple actions may be implemented in any convenient order.
   The state may be followed by a letter, which indicates an explanatory
   footnote.  The dash ('-') indicates an illegal transition.

















<draft-piscitello-mncp-00.txt>                                 Page 31


INTERNET DRAFT                   MNCP                   August 28, 1997


         | State
         |    0         1         2         3         4         5
   Events| Listen   Cmd-Sent  Ntfn-Sent  Data-Sent Await-Rsp Await-Data
   ------+-------------------------------------------------------------
    REQ  | scm/1 or     -         -         -         -         -
         | snt/2
    RCM  | sak/0 or     -         -         -         -         -
         | fsc/4
    RNT  | sak/0 or     -         -         -         -         -
         | fsc/4
    RSP  |   -          -         -         -      sak/0 or     -
         |                                         sak/5 or
         |                                         ind,sak/0
    RAK  |   -      cnf/0     cnf/0 or   cnf/0 or     -         -
         |                    snt/2      sdt/3
         |                    sdt/3
    RDT  |   -          -         -         -         -      sak/5 or
         |                                                   ind,sak/0
    TMO  |   -      cnf/0 or  cnf/0 or   cnf/0 or     -          0
         |          scm/1     snt/2      sdt/3

   Timers are started (sto action) when sending any packet and stopped
   when receiving any packet.  The sending MNCP runs an ACK_WAIT_TIMER;
   the receiving MNCP runs a DATA_WAIT_TIMER.  See section 5.6 for
   additional detail.

5.3 States
   Following is a more detailed description of each automaton state.

   Listen
     The MNCP automaton begins and ends in this state, awaiting either a
     locally-initiated application or session control request, or receipt
     of a PT_CMD or PT_NTFN packet.

   Command-Sent
     The MNCP automaton transitions to this state when sending a PT_CMD
     packet.  Events expected to occur while in this state are expiration
     of the ACK_WAIT_TIMER or receipt of a PT_ACK packet.

   Notification-Sent
     The MNCP automaton transitions to this state when sending a PT_NTFN
     packet.  Events expected to occur while in this state are expiration
     of the ACK_WAIT_TIMER or receipt of a PT_ACK packet.

   Await-Data
     The MNCP automaton transitions to this state when sending a positive
     PT_ACK packet in response to an incoming PT_NTFN packet.  Events
     expected to occur while in this state are expiration of the
     DATA_WAIT_TIMER or receipt of a PT_ACK packet.







<draft-piscitello-mncp-00.txt>                                 Page 32


INTERNET DRAFT                   MNCP                   August 28, 1997


   Await-Session-Response
     The MNCP automaton transitions to this state when forwarding an
     incoming PT_CMD or PT_NTFN packet to MNCP session control.  The only
     event expected to occur while in this state is a response from session
     control.

   Data-Sent
     The MNCP automaton transitions to this state when sending a PT_DATA
     packet.  Events expected to occur while in this state are expiration
     of the ACK_WAIT_TIMER or receipt of a PT_ACK packet.

5.4 Events
   Transitions and actions in the automaton are caused by events.

   Receive Application Request (REQ)
     This event occurs when a locally-initiated application or session
     control request is submitted to the MNCP for processing.  If the data
     contained in the request is shorter than (DEFAULT_PACKET_SIZE -
     header) octets, uncompressed, the MNCP automaton sends a PT_CMD (scm
     action). Otherwise, it sends a PT_NTFN (snt action).

   Receive PT_CMD (RCM)
     This event occurs when a remotely-initiated PT_CMD packet is received
     by the MNCP as an incoming UDP datagram.  If the packet is badly
     formed, contains an invalid version, a system error occurs, or
     resources are unavailable to further process the request, the MNCP
     automaton sends a PT_ACK (sak action) with a negative Ack Code.
     Otherwise, it forwards the PT_CMD packet to the MNCP session control
     automaton (fsc action).

   Receive PT_NTFN (RNT)
     This event occurs when a remotely-initiated PT_NTFN packet is received
     by the MNCP as an incoming UDP datagram.  If the packet is badly
     formed, contains an invalid version, a system error occurs, resources
     are unavailable to further process the request, or the proposed
     compression method is not supported, the MNCP automaton sends a PT_ACK
     (sak action) with a negative Ack Code, and an alternative compression
     method (if applicable).  Otherwise, it forwards the PT_NTFN packet to
     the MNCP session control automaton (fsc action).

   Receive Session Response (RSP)
     This event occurs when a response is returned from the local MNCP
     session control automaton, indicating the success or failure of
     authentication, registration, or deregistration.  If the response is
     negative, the MNCP automaton sends a PT_ACK (sak action) with the
     negative Ack Code supplied by session control.  If the response is
     positive, the MNCP automaton sends a PT_ACK (sak action) ACK_OK.  If
     the incoming request was a PT_CMD packet, the MNCP automaton supplies
     any application-specific information elements (including data) to the
     destination application (ind action).

   Receive PT_ACK (RAK)
     This event occurs when a remotely-initiated PT_ACK packet is received
     by the MNCP as an incoming UDP datagram.  If the Ack Code is


<draft-piscitello-mncp-00.txt>                                 Page 33


INTERNET DRAFT                   MNCP                   August 28, 1997


     ACK_OOS_COMPRESS, the MNCP automaton SHOULD resend the PT_NTFN with
     another compression method (snt action).  If the Ack Code is any other
     negative value, the MNCP automaton notifies the requesting application
     of the failure (cnf action).  If the Ack Code is ACK_OK and confirms a
     PT_NTFN or PT_DATA(more) packet, the MNCP automaton sends a PT_DATA
     packet (sdt action).  Otherwise (the Ack Code is ACK_OK and confirms
     the final packet in a sequence), the MNCP automaton notifies the
     requesting application that its request was delivered successfully
     (cnf action).

   Receive PT_DATA (RDT)
     This event occurs when a remotely-initiated PT_DATA packet is received
     by the MNCP as an incoming UDP datagram.  The MNCP automaton uses the
     packet contents to reassemble and decompress application data (see
     Sections 5.6 through 5.8) and send a PT_ACK (sak action).  If incoming
     packet contained an IE_DATA_FINAL element, the MNCP automaton supplies
     all application-specific information elements received during the
     packet sequence, including the reassembled/decompressed application
     data, to the destination application (ind action).

   Ack Timeout (TMO)
     This event occurs when the ACK_WAIT_TIMER or DATA_WAIT_TIMER started
     by this MNCP automaton expires.  The automaton applies its
     retransmission algorithm (see Section 5.6) to determine the
     appropriate action: resending a PT_CMD packet (scm action), PT_NTFN
     packet (snt action), PT_DATA packet (sdt action), or PT_ACK packet
     (sak action), or abandoning the packet sequence.  When abandoning the
     packet sequence, if this MNCP was the sequence initiator, it also
     notifies the requesting application of the failure (cnf action).

5.5 Actions
   Actions in the automaton are caused by events and typically indicate
   the transmission of packets and/or the starting or stopping of the
   timers.

   send PT_CMD (scm)
     The MNCP automaton sends a PT_CMD packet as a result of a locally-
     initiated application or session control request, or as a retry
     (ACK_WAIT_TIMER expired with retry remaining).

     The MNCP builds a PT_CMD packet as follows.
     - Protocol Version is set to the value for this implementation.
     - Packet Type is set to PT_CMD.
     - Correlation Identifier is assigned by the MNCP (new request) or set
      to the previously-assigned value (retry).
     - Sequence Number is set to zero(0).
     - Session Control fields supplied in the request (Service ID, Function
      ID, Subscriber ID, Subscriber Password) are appended.
     - Any application-specific IEs supplied in the request are appended.
     - Any application-specific data supplied in the request is
      encapsulated in a Data(Final) information element.

     The PT_CMD packet is sent as a UDP packet to the "well-known" MNCP
     port, the PKT_RETRY count is incremented, and the ACK_WAIT_TIMER is


<draft-piscitello-mncp-00.txt>                                 Page 34


INTERNET DRAFT                   MNCP                   August 28, 1997


     started (see Section 5.6).  The MNCP automaton then transitions to the
     Command-Sent state.

   send PT_NTFN (snt)
     The MNCP automaton sends a PT_NTFN packet as a result of a locally-
     initiated application or session control request, or as a retry
     (ACK_WAIT_TIMER expired with retry remaining or PT_ACK
     ACK_OOS_COMPRESS received and alternative method available).

     The MNCP builds a PT_NTFN packet as follows.
     - Protocol Version is set to the value for this implementation.
     - Packet Type is set to PT_NTFN.
     - Correlation Identifier is assigned by the MNCP (new request) or set
      to the previously-assigned value (retry).
     - Sequence Number is set to zero(0).
     - Data Compression Method is chosen by the MNCP, influenced by values
      returned in earlier PT_ACKs (if any); see Section 5.8. If the
      default value (COMPRESS_OFF) is selected, this field SHOULD be
      omitted.
     - Uncompressed Message Length is set to the number of octets of
      application-specific data supplied in the request.
     - Compressed Message Length is set to the number of octets yielded
      when compressing this data using the proposed Compression Method.
     - As an implementation option, Packet Size may be set to a value
      larger than DEFAULT_PACKET_SIZE; see Section 5.7.  If the default
      value is desired, this field SHOULD be omitted.
     - Session Control fields supplied in the request (Service ID, Function
      ID, Subscriber ID, Subscriber Password) are appended.
     - Any application-specific IEs supplied in the request are appended.

     The PT_NTFN packet is sent as a UDP packet to the "well-known" MNCP
     port, the PKT_RETRY count is incremented, and the ACK_WAIT_TIMER is
     started (see Section 5.6).  The MNCP automaton then transitions to the
     Notification-Sent state.

   fwd to Session Control (fsc)
     The MNCP automaton forwards incoming PT_CMD and PT_NTFN packets to
     MNCP session control for registration, deregistration, and
     authentication.  The MNCP automaton then transitions to the Await-
     Session-Response state.

   send PT_ACK (sak)
     The MNCP automaton sends a PT_ACK packet in response to an incoming
     packet.

     The MNCP builds a PT_ACK packet as follows.
     - Protocol Version is set to the value for this implementation.
     - Packet Type is set to PT_ACK.
     - Correlation Identifier and Sequence Number are both set to the
      corresponding values in the packet being acknowledged.
     - Ack Code is chosen by the MNCP to reflect the result of processing.





<draft-piscitello-mncp-00.txt>                                 Page 35


INTERNET DRAFT                   MNCP                   August 28, 1997


     When acknowledging a PT_NTFN only, the following fields MAY also be
     included in the PT_ACK packet.
     - If the Ack Code is ACK_OOS_COMPRESS, an alternative Data Compression
      Method MUST be chosen by the MNCP; see Section 5.8.  Otherwise, this
      field MUST be omitted.
     - As an implementation option, PACKET_SIZE MAY be set to a value
      larger than DEFAULT_PACKET_SIZE and less than the proposed size, see
      Section 5.7.  If the default value is desired, this field SHOULD be
      omitted.

     The PT_ACK packet is sent as a UDP packet to the source port which
     sent the packet being acknowledged.  When positively acknowledging a
     PT_NTFN or PT_DATA(more) packet, the MNCP automaton then transitions
     to the Await-Data state and the DATA_WAIT_TIMER is started (see
     section 5.6).  Otherwise, the MNCP automaton transitions to the Listen
     state, forwards incoming data to the receiving application (ind
     action), and the packet sequence is concluded.

   send PT_DATA (sdt)
     The MNCP automaton sends a PT_DATA packet when it receives a positive
     PT_ACK to a PT_NTFN or PT_DATA(more) packet, or as a retry
     (ACK_WAIT_TIMER expired with retry remaining).

     The MNCP builds a PT_DATA packet as follows.
     - Protocol Version is set to the value for this implementation.
     - Packet Type is set to PT_DATA.
     - Correlation Identifier is set to the value used in the PT_NTFN
      packet that started this packet sequence.
     - Sequence Number is set to the value used in the preceding packet
      (retry) or that value incremented by one (otherwise).
     - Data Offset is set to the starting octet position of the
      application-specific data to be included in this packet.
     - Compressed and segmented application data (see Sections 5.7 and 5.8)
      is encapsulated in IE_DATA_MORE or IE_DATA_FINAL information
      elements.  When building an IE_DATA_MORE element, the MNCP MUST fill
      the remainder of the PT_DATA packet with compressed data.  When
      building an IE_DATA_FINAL element, the MNCP MUST NOT pad the data.

     The PT_DATA packet is sent as a UDP packet to the source port which
     sent the last PT_ACK packet, the PKT_RETRY count is incremented, and
     the ACK_WAIT_TIMER is started (see Section 5.6).  The MNCP automaton
     then transitions to the Data-Sent state.

   start ACK_WAIT_TIMER or DATA_WAIT_TIMER (sto)
     The MNCP automaton starts the ACK_WAIT_TIMER or DATA_WAIT_TIMER
     whenever it sends a non ACK packet, as described in Section 5.6.

   send Appl Indication (ind)
     The MNCP automaton supplies incoming session control information
     elements, application-specific information elements, and
     reassembled/decompressed data (if any) to the destination application
     just before sending a PT_ACK to an incoming PT_CMD or PT_DATA(final)
     packet as described under the sak action above.



<draft-piscitello-mncp-00.txt>                                 Page 36


INTERNET DRAFT                   MNCP                   August 28, 1997


   send Appl Confirm (cnf)
     The MNCP automaton supplies a delivery confirmation to the requesting
     application when it receives the final PT_ACK in a packet sequence or
     abandons the request.  Negative confirmations include the reason why
     the request could not be delivered (e.g., the Ack Code value or
     timeout).  The MNCP automaton then transitions to the Listen state and
     the packet sequence is concluded.

5.6 Timers, Acknowledgment, and Retransmission
   To help ensure a reliable delivery of data between a MCD and the
   Mobility Server, MNCP uses a stop-and-go with timeout retransmission
   mechanism.

   Each MNCP reliable delivery packet carries a 16-bit unsigned sequence
   number and MUST be individually acknowledged by the receiving MNCP.
   The sequence number MUST start at 0 for the first packet of each packet
   sequence and be incremented by one for each additional packet in the
   flow till 65,535 and then recycled through 0 if necessary.  An
   acknowledgment packet MUST use the same sequence number as the packet
   it is acknowledging.

   Out of sequence data packet MUST be discarded by the receiving MNCP.
   As part of the action associated with the processing a PT_DATA packet
   that arrives out of sequence, the MNCP MUST return a PT_ACK packet
   containing the Sequence Number of the most recently acknowledged
   PT_DATA packet.

   When sending a packet, the sending MNCP MUST start a retransmission
   timer (ACK_WAIT_TIMEOUT, default 15 seconds), during which the sending
   MNCP will wait for an acknowledgment from the receiving MNCP.  When
   sending a PT_ACK to any packet other than PT_DATA (final), the
   receiving MNCP MUST start a DATA_WAIT_TIMER (typically, three times the
   ACK_WAIT_TIMER value).  Expiration of this timer causes the transfer of
   the packet sequence to be abandoned.

   If the sending MNCP does not receive an acknowledgment from the
   receiving MNCP within the timeout period, which has the same sequence
   number as the packet been sent, it should retransmit the packet up to
   PKT_RETRY times (default 2 retries per packet).  If there is still no
   acknowledgment after all the retries (i.e., for an attempt of PKT_RETRY
   + 1 times), the sending MNCP should abort the packet sequence.

   Implementation Note: In the current implementations, timers are
   assigned predetermined values appropriate for the wireless environment
   over which the MNCP operates, from a configuration file.
   ACK_WAIT_TIMEOUT is the same for all Service ID/Function ID
   combinations.

5.7 Packet Size Negotiation, Segmentation and Reassembly
   A sending MNCP may propose a packet size larger than the
   DEFAULT_PACKET_SIZE in a NOTIFICATION REQUEST.  Any value greater than
   DEFAULT_PACKET_SIZE but less than or equal to the maximum packet size
   of 2048 octets may be proposed by encoding the desired size in the
   IE_PKT_SIZE information element in the PT_NTFN.  A receiving MNCP may


<draft-piscitello-mncp-00.txt>                                 Page 37


INTERNET DRAFT                   MNCP                   August 28, 1997


   accept the proposed packet size, or it may proposed a reduced packet
   size.  The receiving MNCP specifies the acceptable packet size
   (proposed or reduced) in the IE_PKT_SIZE information element when
   composing a PT_ACK packet in response to a PT_NTFN packet.  In the
   absence of an explicit IE_PKT_SIZE field, the DEFAULT_PACKET_SIZE MUST
   be assumed.

5.7.1 Computing the payload size for PT_DATA packets
   The sending MNCP subtracts the MNCP common header length (7), the
   length of IE_DATA_OFFSET information element (6) and the length of the
   IE Length and IE Type components of the IE_DATA_MORE information
   element (3) from the value of IE_PKT_SIZE and uses this as the
   PAYLOAD_SIZE.

5.7.2 Segmentation and PT_DATA Packet Composition
   The sending MNCP segments application data into "n" PT_DATA packets.
   All but the final PT_DATA packet contain one IE_DATA_MORE information
   element that conveys PAYLOAD_SIZE octets, and a monotonically
   incremented sequence number, and a data offset.

   Data compression, if selected, is performed on the application data
   prior to segmentation.  This is required to determine the value of
   Compressed Message Length used in the PT_NTFN (see section 3.5.2).

   Initially, a local parameter, next-data-offset, is set to zero (0), and
   the next-sequence-number is set equal to the value of Sequence Number
   sent in the PT_NTFN (zero, 0).

   If no compression is used, then PAYLOAD_SIZE number of octets of
   uncompressed data are encoded in the Data field of the IE_DATA_MORE
   information element.  The value of next-data-offset is encoded in the
   IE_DATA_OFFSET field, and next-data-offset is incremented by
   PAYLOAD_SIZE.  If compression is used, then PAYLOAD_SIZE number of
   octets of compressed data are encoded in the Data field of the
   IE_DATA_MORE information element, the value of next-data-offset is
   encoded in the IE_DATA_OFFSET field, and next-data-offset is set to the
   octet location of the final octet of data that were encoded in the Data
   field. The Sequence number encoded in the common packet header is set
   to next-sequence number, and next-sequence-number is increased by one
   (1).

   The PT_DATA packet is then sent as an individual transmission in a UDP
   packet, and a timer is initiated.  If a PT_ACK is not received before
   the retransmission timer expires, the PT_DATA packet is retransmitted.
   Retransmission upon timer expiration is repeated until a maximum number
   of retries (PKT_RETRY +1) is exhausted, at which time the sending MNCP
   notifies session control of a communications failure.

   Upon reception of an PT_ACK, another PT_DATA packet may be sent.  If no
   compression is used and the value of IE_DATA_OFFSET subtracted from
   Original Message length is greater than PAYLOAD_SIZE, the process of
   composing and sending a PT_DATA packet containing an IE_DATA_MORE
   information element is repeated.  Similarly, a PT_DATA packet
   containing an IE_DATA_MORE information element is composed if


<draft-piscitello-mncp-00.txt>                                 Page 38


INTERNET DRAFT                   MNCP                   August 28, 1997


   compression is used and more than PAYLOAD_SIZE number of compressed
   octets remain to be sent.  Otherwise, a final PT_DATA packet is
   generated.

   The final PT_DATA packet contains an IE_DATA_FINAL information element,
   and conveys up to PAYLOAD_SIZE octets, compressed or uncompressed.  The
   value of the IE_DATA_FINAL information element must not be padded.

5.7.3 Reassembly
   The receiving MNCP processes incoming PT_DATA packets as follows.
   Following transmission of a positive (PT_ACK) acknowledgment to a
   PT_NTFN packet, the receiving MNCP sets a local parameter for next-
   expected-sequence-number to one (1), and awaits the arrival of a
   PT_DATA packet containing the same Correlation ID as encoded in the
   PT_NTFN packet that initiated this packet sequence and a Sequence
   Number equal to the parameter next-expected-sequence-number, and an
   IE_DATA_MORE or IE_DATA_FINAL information element.

   The receiving MNCP composes and returns a PT_ACK with Sequence Number
   set to the value of Sequence Number from the PT_DATA packet being
   acknowledged, then increments next-expected-sequence-number by one (1),
   and awaits the arrival of the next packet in the sequence.  If the
   sequence number in the next PT_DATA packet that arrives does not equal
   next-expected-sequence-number, the receiving MNCP composes and returns
   a PT_ACK packet with the sequence number of the last acknowledged
   PT_DATA packet (next-expected-sequence-number minus 1) and immediately
   discards the PT_DATA packet.  Otherwise, the receiving MNCP processes
   each arriving PT_DATA packet containing an IE_DATA_MORE information
   element in exactly the same manner as the initial PT_DATA packet.  The
   process repeats until a PT_DATA packet containing an IE_DATA_FINAL
   information element is received.  The receiving MNCP composes and
   returns a PT_ACK as previously described.

   If compression is used, the user data extracted from the IE_DATA_MORE
   and IE_DATA_FINAL information elements received by the MNCP are
   reassembled and then uncompressed.  Reassembly uses the values of
   IE_DATA_OFFSET and PAYLOAD_SIZE to compose the original message from
   the message segments delivered, then the message in its entirety is
   passed to the application.

   Receive buffer strategies are implementation-dependent; for example, if
   compression is used during a transfer, the value of Compressed Message
   Length from the IE_MSG_LENGTH information element in the PT_NTFN may be
   used to allocate a buffer sufficient for the reassembly of the
   compressed data packet sequence, otherwise the value of Original
   Message Length may be used.  [Note: This memo imposes no restrictions
   on how receive buffers are allocated in implementations.]

5.8 Data Compression
   When issuing a PT_NTFN packet, the sending MNCP uses the
   IE_DATA_COMPRESSION field to indicate the compression method that it
   wishes to apply to the application data that will follow in PT_DATA
   packets.  The IE_MSG_LENGTH Compressed Message Length field is computed



<draft-piscitello-mncp-00.txt>                                 Page 39


INTERNET DRAFT                   MNCP                   August 28, 1997


   by assuming this compression method.  The receiving MNCP responds to
   this bid in the PT_ACK packet that confirms the PT_NTFN, as follows.

   To accept the proposed compression method, the responding MNCP MUST
   return a PT_ACK packet with IE_DATA_COMPRESSION absent and IE_ACK_CODE
   equal to ACK_OK.

   To reject the proposed compression method, the responding MNCP MUST
   return a PT_ACK packet with IE_DATA_COMPRESSION set to indicate an
   alternative compression method (which may be NONE) and an IE_ACK_CODE
   equal to ACK_OOS_COMPRESS.

   If the sender's proposed compression method was rejected, the sending
   MNCP SHOULD issue another PT_NTFN packet with an alternative
   compression method, repeating the above negotiation until a mutually
   acceptable method is agreed upon (signaled by a PT_ACK with IE_ACK_CODE
   equal to ACK_OK and IE_DATA_COMPRESSION absent). Note that the
   IE_MSG_LENGTH Compressed Message Length field is recomputed by assuming
   the compression method, which can either be the alternative method
   proposed by the receiver, or a new method proposed by the sender.  If
   no compression method is specified, the Compressed Message Length field
   value MUST be the same as the value of Original Message Length.

   Once a compression method has been agreed, the sending MNCP applies the
   negotiated method to compress the data content of PT_DATA packet
   IE_DATA_MORE and IE_DATA_FINAL elements sent in this MNCP packet
   sequence.  The receiving MNCP applies the same negotiated method to
   decompress the data content upon arrival, ultimately yielding the
   number of octets indicated by the IE_MSG_LENGTH Original Message Length
   field.

6. MNCP Session Control Processing
   The phase diagram and state machine described in this section operates
   on unique Subscriber ID/Service ID pairs.  When responding to any
   event, the session control automaton must first determine the current
   state associated with the Subscriber ID/Service ID pair, and then
   follow the course of action specified for that state.

6.1 Phase Diagram
     Session control goes through two distinct phases which are specified
     in the following simplified diagram.















<draft-piscitello-mncp-00.txt>                                 Page 40


INTERNET DRAFT                   MNCP                   August 28, 1997



      +------+           +------------+ DEREG(FAILED)
      |      |REG(ACK_OK)|            | and APPL REQs
      | Idle |---------->| Registered |---------+
      |      |           |            |<--------+
      +------+           +------------+
         ^                       |
         | DEREG(SUCCESS)OR LOS  |
         <-----------------------+

       REG(ACK_OK)   = Send or receive Ack Code ACK_OK to FUN_REG_REQ
                       or FUN_<other>
       DEREG(SUCCESS)= Send/receive positive Ack accepting FUN_DEREG_REQ
                       PT_ACK from MCD to MS containing ACK_OOS_SVC
                       PT_ACK from MS to MCD containing ACK_OK
       DEREG(FAILED) = Send/receive negative Ack rejecting FUN_DEREG_REQ
                       PT_ACK from MCD to MS containing ACK_OK
                       PT_ACK from MS to MCD containing any other value
       APPL REQs     = Send or receive FUN_<other> app-specific request
       LOS           = Loss of signal assumed when DEREG_REQ abandoned

   Idle Phase
     MNCP session control necessarily begins and ends with this phase.
     When a positive acknowledgment (Ack Code ACK_OK) is returned to a
     Registration Request (FUN_REG_REQ or FUN_<other> in the case of an
     implicit registration performed by the MS), session control
     transitions to the Registered phase.

     MNCP session control returns to the Idle phase automatically after
     receiving or sending a successful Deregistration Request, and after
     timeout of a Deregistration Request, as signaled by the MNCP reliable
     delivery automaton.

   Registered Phase
     MCD MNCP session control enters this phase when receiving a positive
     Registration Request acknowledgment.  MS MNCP session control enters
     this phase when it has received and processed a valid Registration
     request from an MCD and has responded to the request with a positive
     acknowledgment.  MS MNCP session control also enters this phase when
     it has received and processed a valid service request from an MCD that
     has not previously (explicitly) registered with the service and has
     responded to the request with a positive acknowledgment.

     In this phase, MNCP session control processes incoming Deregistration
     Requests and any other Application Request.  All requests are
     authenticated, and service access control is verified.  Application
     Requests are forwarded to the destination application service only if
     the subscriber is currently registered for that service.

     The Mobility Server runs an INACTIVITY_TIMER to reaffirm the
     registration status on a periodic basis.

     MCD MNCP session control remains in the Registered phase until it
     completes a successful Deregistration Request.  MS MNCP session


<draft-piscitello-mncp-00.txt>                                 Page 41


INTERNET DRAFT                   MNCP                   August 28, 1997


     control remains in the Registered phase until it either completes a
     successful Deregistration, or a Deregistration Request is abandoned
     due to timeout.  When Deregistration is completed, the MNCP returns to
     the Idle phase.

6.2 State Diagram
   The session control finite-state automaton is defined by events,
   actions and state transitions.  Events include reception of application
   requests and expiration of the Inactivity timer.  Actions include the
   starting of the INACTIVITY_TIMER and transmission of requests and
   responses.

   Events                                 Actions

   ORR = Outgoing Registration Request    srr = send FUN_REG_REQ
   ODR = Outgoing Deregistration Request  sdr = send FUN_DEREG_REQ
   OAR = Outgoing Application Request     sar = send FUN_<other>
   IRR = Incoming FUN_REG_REQ             au  = authenticate subscriber
   IDR = Incoming FUN_DEREG_REQ           up  = update registr. status
   IAR = Incoming FUN_<other>             spk = send Positive Ack
   IAK = Incoming Ack                     snk = send Negative Ack
   TMO = Inactivity Timeout               it  = start INACTIVITY_TIMER

   The complete state transition table follows.  States are indicated
   horizontally, and events are read vertically.  State transitions and
   actions are represented in the form action/new-state.  Multiple actions
   are separated by commas, and may continue on succeeding lines as space
   requires; multiple actions may be implemented in any convenient order.
   The state may be followed by a letter, which indicates an explanatory
   footnote.  The dash ('-') indicates an illegal transition.

         | State
         |    0            1         2         3         4
   Events| Listen      Reg-Sent  Dereg-Sent App-Sent Registered
   ------+-----------------------------------------------------
    ORR  | srr/1           -         -         -     -
    ODR  |     -           -         -         -     up,sdr/2
    OAR  |     -           -         -         -     sar/3
    IRR  | au,snk/0 or     -         -         -     -
         | au,up,it,spk/4
    IDR  |     -       snk/1      snk/2      snk/3   au,snk/4 or
         |                                           au,up,spk/0
    IAR  |     -           -         -         -     au,it,up,spk/4 or
         |                                           au,it,spk/4 or
         |                                           au,it,snk/4
    IAK  |     -       up/4 or   up,it/4 or    4     -
         |                 0         0
    TMO  |     -           -         -         -     up,sdr/2

   The INACTIVITY_TIMER runs only at the Mobility Server.

6.3 States
   Following is a more detailed description of each automaton state.



<draft-piscitello-mncp-00.txt>                                 Page 42


INTERNET DRAFT                   MNCP                   August 28, 1997


   Listen
     The session control automaton begins and ends in this state, awaiting
     either a locally-initiated (outgoing) Registration Request, or receipt
     of an incoming FUN_REG_REQ indication from MNCP reliable delivery.

   Registration-Request-Sent
     The session control automaton transitions to this state when sending a
     FUN_REG_REQ.  The events expected to occur while in this state are
     receipt of an Ack Code from MNCP reliable transfer, indicating the
     result of the request or timeout, or receipt of a Deregister request
     form the MS.

   Deregistration-Request-Sent
     The session control automaton transitions to this state when sending a
     FUN_DEREG_REQ.  Events expected to occur while in this state are
     receipt of an Ack Code from MNCP reliable transfer or receipt of an
     incoming FUN_DEREG_REQ.

   Application-Request-Sent
     The session control automaton transitions to this state when sending a
     FUN_REG_REQ.  Events expected to occur while in this state are receipt
     of an Ack Code from MNCP reliable transfer or receipt of an incoming
     FUN_DEREG_REQ, or receipt of a Deregister request form the MS.

   Registered
     The session control automaton transitions to this state when returning
     a positive Ack for an incoming FUN_REG_REQ (explicit registration),
     returning a positive Ack for an incoming FUN_<other> (implicit
     request), receiving a positive Ack for an outgoing FUN_REG_REQ,
     receiving a positive Ack for an outgoing FUN_<other>, or receiving a
     negative Ack for an outgoing FUN_DEREG_REQ.  Events expected to occur
     while in this state are outgoing Deregistration or Application
     Requests, incoming FUN_DEREG_REQ or FUN_<other> packets, or expiration
     of the INACTIVITY_TIMER.

6.4 Events
   Transitions and actions in the automaton are caused by events.

   Outgoing Registration Request (ORR)
     This event occurs when a Registration Request is initiated by the MCD,
     causing the session control automaton to send a FUN_REG_REQ (srr
     action).  This event MAY also be initiated implicitly by the MCD
     session control implementation (e.g., when the first Application-
     specific Request for a give service is initiated).

   Outgoing Deregistration Request (ODR)
     This event occurs when a Deregistration Request is initiated by the
     MCD, causing the session control automaton to send a FUN_DEREG_REQ
     (sdr action).  This event MAY also be initiated by the MS session
     control implementation (as a consequence of the expiry of the
     INACTIVITY_TIMER).





<draft-piscitello-mncp-00.txt>                                 Page 43


INTERNET DRAFT                   MNCP                   August 28, 1997



   Outgoing Application Request (OAR)
     This event occurs when an Application Request is initiated by the MCD,
     causing the session control automaton to send a FUN_<other> (sar
     action).

   Incoming FUN_REG_REQ (IRR)
     This event occurs when a remotely-initiated FUN_REG_REQ is received by
     the Mobility Server.  The session control automaton attempts to
     authenticate the subscriber and verify the subscriber is permitted
     access to the service indicated in the request (au action) and returns
     the result to MNCP reliable delivery as an Ack Code (snk or spk
     action).  When authentication is successful, the automaton also
     updates the subscriber's registration status (up action) and starts
     the INACTIVITY_TIMER (it action).

   Incoming FUN_DEREG_REQ (IDR)
     This event occurs when a remotely-initiated FUN_DEREG_REQ is received
     by either the MCD or Mobility Server.  The session control automaton
     attempts to authenticate the subscriber (au action) and returns the
     result to MNCP reliable delivery as an Ack Code (snk or spk action).
     When authentication is successful, the automaton also updates the
     subscriber's registration status (up action).

   Incoming FUN_<other> (IAR)
     This event occurs when any other remotely-initiated request
     (FUN_<other>) is received by either the Mobility Server.  The session
     control automaton attempts to authenticate the subscriber and verify
     the subscriber is permitted access to the service indicated in the
     request (au action), and returns the result to MNCP reliable delivery
     as an Ack Code (snk or spk action).

   Incoming Acknowledgment (IAK)
     This event occurs when a response is received from MNCP reliable
     delivery, indicating success or failure of an earlier request as an
     Ack Code.  When receiving a Registration or Deregistration Request
     acknowledgment, the automaton updates the subscriber's registration
     status (up action).  When the Mobility Server receives an ACK_OK in a
     Deregistration Request acknowledgment, indicating the subscriber
     should be (re)registered for the service, the MS (re)starts the
     INACTIVITY_TIMER (it action).

   Inactivity Timeout (TMO)
     This event occurs when the INACTIVITY_TIMER started by the Mobility
     Server's session control automaton expires.  Subsequent processing
     assumes that the MCD has become unavailable since last contact (e.g.,
     out of range, turned off, disabled).  The automaton updates the
     subscriber's registration status (up action) and sends a FUN_DEREG_REQ
     (sdr action).

6.5 Actions
   Actions in the automaton are caused by events and typically indicate
   the transmission of packets and/or the (re)starting of the Inactivity
   timer.


<draft-piscitello-mncp-00.txt>                                 Page 44


INTERNET DRAFT                   MNCP                   August 28, 1997



   send FUN_REG_REQ (srr)
     The MCD sends a FUN_REG_REQ packet as a result of a locally-initiated
     Registration Request involving a Subscriber/Service combination that
     is not currently registered (i.e., the automaton is in the Listen
     state).  Session Control fields (Service ID, Function ID, Subscriber
     ID, Subscriber Password) are supplied to the MNCP reliable delivery
     automaton for inclusion in a PT_CMD packet.  Function ID is set to
     FUN_REG_REQ; all other values are obtained from the MCD
     subscriber/application.  The session control automaton then
     transitions to the Registration-Request-Sent state.

   send FUN_DEREG_REQ (sdr)
     The MCD sends a FUN_DEREG_REQ packet as a result of a locally-
     initiated Deregistration Request (implicit or explicit) involving a
     Subscriber/Service combination that is currently registered (i.e., the
     automaton is in the Registered state).  The Mobility Server also sends
     a FUN_DEREG_REQ packet when the INACTIVITY_TIMER expires.  Session
     Control fields (Service ID, Function ID, Subscriber ID, Subscriber
     Password) are supplied to the MNCP reliable delivery automaton for
     inclusion in a PT_CMD packet.  Function ID is set to FUN_DEREG_REQ;
     all other values are obtained from the subscriber/application or the
     registration status table.  The session control automaton marks the
     subscriber as deregistered for this service (up action) and then
     transitions to the Deregistration-Request-Sent state.































<draft-piscitello-mncp-00.txt>                                 Page 45


INTERNET DRAFT                   MNCP                   August 28, 1997


   send FUN_<other> (sar)
     Either the Mobility Server or the MCD sends a FUN_<other> packet as a
     result of a locally-initiated Application Request involving a
     Subscriber/Service combination that is currently registered (i.e., the
     automaton is in the Registered state), or the MCD sends a FUN_<other>
     packet as a result of a locally-initiated Application Request
     involving a Subscriber/Service combination that has not been
     explicitly registered (i.e., the MS is expected to implicitly register
     the application at the MCD).  Session Control fields provided by the
     application (Service ID, Function ID, Subscriber ID, Subscriber
     Password) are supplied to the MNCP reliable delivery automaton for
     inclusion in a PT_CMD or PT_NTFN packet.  The session control
     automaton then transitions to the Application-Request-Sent state.

     An Application Request initiated when the automaton is in the Listen
     state MAY cause the MCD to attempt implicit registration before the
     request is further processed.  Otherwise, such a request MUST be
     rejected using the Ack Code value ACK_OOS_SVC and the automaton
     remains in the Listen state.

   authenticate subscriber (au)
     The automaton attempts to authenticate the Subscriber ID and Password
     and verifies the subscriber's current registration status and
     permission to access the specified Service ID and Function ID.

     - If Subscriber ID is not found, return the Ack Code ACK_ERR_SID.
     - Else if the Subscriber Password is invalid, return the Ack Code
      ACK_ERR_PWD.
     - Else if the Subscriber does not have permission to access this
      Service and Function, return the Ack Code ACK_OOS_SID.
     - Else if the Service is not currently available (e.g., the
      application process bound to this Service ID is not running), return
      ACK_OOS_SVC.
     - Else return ACK_OK.

     The method by which the MNCP determines whether a local application
     service is running is not specified by this memo.  Refer to Section 7
     for additional discussion of Security.  Refer to the spk and snk
     actions for Ack Code processing.

   update Registration Status (up)
     The automaton updates the subscriber's current registration status for
     each specified service as follows.













<draft-piscitello-mncp-00.txt>                                 Page 46


INTERNET DRAFT                   MNCP                   August 28, 1997


     When the MNCP:                               Status is set to:
     ---------------------------------------      -----------------
     Sends positive FUN_REG_REQ Ack Code          Registered
     Receives positive FUN_REG_REQ Ack Code       Registered
     Receives positive FUN_<other> Ack Code       Registered (implicit)
     Sends FUN_DEREG_REQ                          Deregistered (implicit)
     Sends positive FUN_DEREG_REQ Ack Code        Deregistered
     (MCD sends ACK_OOS_SVC, MS sends ACK_OK)
     Receives positive FUN_DEREG_REQ Ack Code     Deregistered
     (MCD rcvs ACK_OK, MS rcvs ACK_OOS_SVC)
     Sends negative FUN_DEREG_REQ Ack Code        (Still)Registered
     (MCD sends ACK_OK, MS sends ACK_other)
     Receives negative FUN_DEREG_REQ Ack Code     (Re)Registered
     (MCD rcvs ACK_other, MS rcvs ACK_OK)

     Storage methods and internal representation of subscriber information
     and registration status are not specified by this memo.

   send Positive Ack Code (spk)
     Successful authentication of any incoming request forwarded to session
     control is indicated by returning a positive ACK code to the MNCP
     reliable delivery automaton for inclusion in a PT_ACK packet. A
     positive Ack Code is ACK_OK in all cases except when an MCD responds
     to a FUN_DEREG_REQ; in this case, it is ACK_OOS_SVC. The session
     control automaton changes state when acknowledging initial Application
     Requests (FUN_<other> packets) that cause implicit registration.  The
     automaton transitions to the logical next state: Registered after a
     FUN_REG_REQ, FUN_<other>, or Listen after a FUN_DEREG_REQ.

   send Negative Ack Code (snk)
     Failed authentication of any incoming request forwarded to session
     control is indicated by returning a negative ACK code to the MNCP
     reliable delivery automaton for inclusion in a PT_ACK packet.  A
     negative ACK code is one of {ACK_ERR_SID, ACK_ERR_PWD, ACK_OOS_SID, or
     ACK_OOS_SVC}, except in the case where an MCD rejects a FUN_DEREG_REQ,
     in which case the ACK code is ACK_OK. The session control automaton
     does not change state when acknowledging Application Requests
     (FUN_<other> packets) or failed Registration Requests, but transitions
     back to the Registered state after a failed Deregistration Request
     (i.e., MS requests deregistration after inactivity time expires, but
     MCD indicates the application is still active).

   start INACTIVITY_TIMER (it)
     The Mobility Server's session control automaton (re)starts an
     INACTIVITY_TIMER whenever it receives a FUN_REG_REQ, FUN_<other>, or
     failed FUN_DEREG_REQ Ack from the MCD.  This timer allows the Mobility
     Server to refresh the registration status associated with an MCD on a
     periodic basis in the absence of other traffic.  This timer does not
     apply to the MCD's session control automaton.







<draft-piscitello-mncp-00.txt>                                 Page 47


INTERNET DRAFT                   MNCP                   August 28, 1997


7. Security Considerations
   The only form of security provided in this protocol is a validation
   (weak authentication) scheme based on clear text subscriber
   identification and password, so it is vulnerable to several known forms
   of attacks on clear text, against which only limited defenses can be
   taken (password aging/expiration, use of one-time long, system-
   generated passwords, etc.).  Only subscriber validation is performed
   (the subscriber has no mechanism to determine the authenticity of a
   mobility server).

   [NOTE: A means of negotiating or selecting a strong authentication
   method and (additionally, optionally) a method for providing data
   integrity and confidentiality at the session control level of MNCP is
   under investigation.]

   Since MNCP operates over UDP/IP, it may be appropriate to make use of
   security services offered by other layers.  For example, an IP
   Authentication Header can be used to provide integrity and
   authentication without confidentiality to IP datagrams [6], whereas an
   IP Encapsulating Security Payload (ESP) can be used to provide
   integrity, authentication, and confidentiality to IP datagrams (see
   also [7]).

   For other applications, it may be appropriate to adopt/adapt
   application-specific security services.  For example,  Mobile Messaging
   application, having already adapted POP3 [8] and SMTP [9], could also
   adapt PGP [10] to provide non-repudiation of sender and data privacy
   through encryption.

8. References

  [1]Postel, J., "User Datagram  Protocol," RFC 768, USC/Information
     Sciences Institute, 28 August 2880.

  [2] Reynolds, S. and Postel, J., "ASSIGNED NUMBERS", RFC 1700, 20
     October 1994.

  [3] Friend, R. and Simpson, W., "PPP Stac LZS Compression Protocol", RFC
     1974, USC/Information Sciences Institute, 13 August 2896.

  [4] Malkin, G., "Internet Users' Glossary", RFC 1983, USC/Information
     Sciences Institute, 16 August 2896.

  [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", RFC 2119, USC/Information Sciences Institute, 26 March
     1997.

   [6] Atkinson, R., "IP Authentication Header", RFC 1826,
       USC/Information Sciences Institute, 9 August 2895.

   [7] Atkinson, R., "Security Architecture for the Internet Protocol",
       RFC 1825, USC/Information Sciences Institute, 9 August 2895.

   [8] Atkins, D.,  Stallings, W., Zimmermann, P., "PGP Message


<draft-piscitello-mncp-00.txt>                                 Page 48


INTERNET DRAFT                   MNCP                   August 28, 1997


       Exchange" Formats", RFC 1991, , USC/Information Sciences
       Institute, 16 August 2896

   [9] S Myers, J., M. Rose, "Post Office Protocol - Version 3", RFC
       1939, USC/Information Sciences Institute, 14 May 1996

   [10] Postel, J., "Simple Mail Transfer Protocol", RFC 821,
       USC/Information Sciences Institute, January 8 1982

9. Authors' Addresses

   Dave Piscitello                 Lisa Phifer
   Core Competence                 Core Competence
   1620 Tuckerstown Road           1620 Tuckerstown Road
   Dresher, PA 19025               Dresher, PA 19025
   (215) 830-0692                  (215) 830-0692
   dave@corecom.com                lisa@corecom.com


   Richard Hovey                   Yangwei Wang
   Bellcore                        Bellcore
   445 South Street, MRE-2N264     331 Newman Springs Rd, NVC-3C221
   Morristown, NJ 07960-6438       Red Bank, NJ 07701
   (201)829-4176                   (908)758-5107
   hovey@bellcore.com              ywang@cc.bellcore.com































<draft-piscitello-mncp-00.txt>                                 Page 49


INTERNET DRAFT                   MNCP                   August 28, 1997



Appendix A. HDML Transactions using MNCP

   The design of the Mobile Network Computing Protocol (MNCP) makes it
   possible to implement a wide range of services efficiently and reliably
   using low-bandwidth, high-latency wireless links.  In this Appendix, we
   describe the implementation of a Web browsing and information push
   service based on the Handheld Device Markup Language (HDML).

   HDML has been proposed as a means of bringing interactive browsing
   services to devices with limited processing, storage, display and input
   capabilities.  The language is based on the concept of decks (the basic
   unit transported) and cards (the basic unit displayed).  The language
   is a replacement for HTML for portable devices such as screen
   telephones and two-way pagers, and makes use of the infrastructure of
   HTTP connections and Web servers that has been created for HTML
   browsers. (See http://www.w3.org/pub/WWW/TR/NOTE-Submission-HDML.html
   for a copy of the HDML proposal)

   An HDML browser on an MNCP-capable client device begins by registering
   with the Mobility server. The client registers by submitting a request
   with the Function ID set to 1, and the Service ID set to the pre-
   defined HDML service (assume 85 is assigned to HDML).  During the
   registration process, the Mobility server validates the user, based on
   the submitted Subscriber ID and password, ensuring both that the
   subscriber is registered with the server and authorized to use the
   requested service.  Once registered, the client device can perform
   interactive browsing of HDML sites and receive unsolicited (pushed)
   messages encoded in HDML.

   Browsing of HDML sites is initiated by the subscriber, pointing the
   browser to the desired URL.  The HDML browser formulates a HTTP request
   (e.g., GET or POST) of the specified URL, and submits this to the MNCP
   agent code on the client device. The MNCP code then formulates a single
   packet or multi-packet request to a pre-defined Service ID (i.e., 85)
   on the Mobility server.  The MNC protocol handles reliable delivery of
   the request to the Mobility server, invisible to the HDML browser.

   The Mobility server routes incoming messages to code modules based on
   the Service ID.   Any message with a Service ID of 85 are routed to the
   HDML service module.  The HDML service module then extracts the HTTP
   request from the MNCP message.  The HTTP request could be implemented
   by using a Function ID to correspond to each HTTP function (i.e.,
   Function ID 2 maps to GET, Function ID 3 maps to PUT) or the HTTP
   request as formulated by the client could be included as the body of
   the message.  The HDML service module then forwards the HTTP request to
   the HDML information server.  When the Mobility server receives the
   response from the HDML information server, it encodes the response with
   the previously negotiated compression algorithm and delivers it to the
   client device.  The subscriber could then continue browsing in a
   similar fashion, based on the contents of the HDML deck that was
   returned.




<draft-piscitello-mncp-00.txt>                                 Page 50


INTERNET DRAFT                   MNCP                   August 28, 1997


   The process of `pushing' a message to the HDML browser is implemented
   from the server side.  An external server begins the process by
   formulating an HDML deck to be delivered to a particular HDML service
   subscriber.  Alternatively, a person may wish to send an email- or
   page-type notice to the subscriber.  The information server or the
   individual must deliver the message to the Mobility server, using the
   interface specified by the Mobility server.  (HTTP connections or e-
   mail messages are two possibilities.)  When the Mobility server
   receives such a message, it first determines if the subscriber to whom
   the message is addressed is registered.  If the subscriber is not
   registered for HDML service, the message might be returned or placed in
   a message store.  If the subscriber is currently registered, the
   Mobility server routes the message to the HDML service module.  The
   HDML service module takes the incoming message and formats it for
   delivery.  This formatting might include converting a plain-text
   message to HDML, as well as compression and segmentation for MNCP
   delivery.  The HDML service assigns the proper Service ID (85) and a
   pre-defined Function ID that corresponds to pushed messages.  In fact,
   multiple Function IDs could be assigned to pushed messages, with
   different values indicating different levels of priority, for example.
   Using single- or multiple-packet reliable delivery, the Mobility server
   then forwards the message to the HDML client.  The browser code
   receives the HDML deck, interprets the format for proper display and
   informs the user in an appropriate fashion.  The user can then interact
   with the delivered message in standard browsing mode.

   When the subscriber has completed browsing and/or no longer wishes to
   receive pushed messages, terminating the browser will perform a de-
   registration operation, separating the subscriber from the Mobility
   server.  The de-registration message again uses the HDML-assigned
   Service ID (85) and the Function ID of 0.

   A variety of services can be implemented using HDML.  Currently, public
   services such as phone-number searches, news reports and weather
   forecasts are available.  Users of such services would not generally
   benefit from the overhead of sophisticated security measures.  However,
   HDML could be used in intranet-like applications, such as salespeople
   querying market data, which would require encryption and
   authentication.  To properly protect the data transmitted in such
   applications, the security measures must protect the entire path from
   client to server, not just the wireless portion of the link.  End-to-
   end encryption and authentication protocols could be built into HDML
   browsers and HDML information servers to protect sensitive data.













<draft-piscitello-mncp-00.txt>                                 Page 51


INTERNET DRAFT                   MNCP                   August 28, 1997


   Figure A-1 depicts the MNC architecture as used to support HDML
   transactions.  Figure A-2 illustrates the message flows.

        MCD               MS            HDML Server
   +-----------+      +----------+      +--------+
   |           | HDML |          | HDML |  Info  |
   |HDML Client| <--> |HDML Proxy| <--> | Server |
   +-----------+      +-----+----+      +--------+
   |    MNCP   |      |MNCP |HTTP|      |  HTTP  |
   +-----------+      +-----+----+      +--------+
   |    UDP    |      |UDP  |TCP |      |   TCP  |
   +-----------+------+-----+----+------+--------+
   |   Wireless Network     |   Wireline Network |
   +------------------------+--------------------+

                               Figure A-1.








































<draft-piscitello-mncp-00.txt>                                 Page 52


INTERNET DRAFT                   MNCP                   August 28, 1997



          MCD              MS         HDML Server
           |               |               |
   REG_REQ |PT_CMD(S85,F1) |               |
   ------->|-------------->|               |
   REG_CNF |PT_ACK(ACK_OK) | Register MCD  |
   <-------|<--------------|               |
           |               |               |
           |               |               |
   FUN_REQ |PT_CMD(S85,Fx) | Browser Pull  |
   ------->|-------------->| HDML GET:URL  |
   FUN_CNF |PT_ACK(ACK_OK) |-------------->|
   <-------|<--------------|               |Perform GET
           |               |               |Return PUT
           |               |   HDML PUT    |
           |PT_NTFN(S85,Fy)|<--------------|
           |<--------------|               |
           |PT_ACK(ACK_OK) |               |
           |-------------->|               |
           |PT_DATA(M,DECK)|               |
           |<--------------|               |
           |PT_ACK(ACK_OK) |               |
           |-------------->|               |
           |PT_DATA(F,DECK)|               |
   <-------|<--------------|               |
   FUN_IND |PT_ACK(ACK_OK) |               |
           |               |               |
           |               |               |
           |               |               |Server Push
           |               | HDML POST:URL |
           |PT_NTFN(S85,Fz)|<--------------|
           |<--------------|               |
           |PT_ACK(ACK_OK) |               |
           |-------------->|               |
           |PT_DATA(M,DECK)|               |
           |<--------------|               |
           |PT_ACK(ACK_OK) |               |
           |-------------->|               |
           |PT_DATA(F,DECK)|               |
   <-------|<--------------|               |
   FUN-IND |PT_ACK(ACK_OK) |               |
           |               |               |
           |               |               |
   DEREGREQ|PT_CMD(S85,F0) |               |
   ------->|-------------->|               |
   DEREGCNF|PT_ACK(ACK_OK) |Deregister MCD |
   <-------|<--------------|               |
           |               |               |
           |               |               |Server Push
           |               | HDML POST:URL |
           |               X<--------------|
           |               |               |




<draft-piscitello-mncp-00.txt>                                 Page 53


INTERNET DRAFT                   MNCP                   August 28, 1997


   Key:   S85 = Service ID of HDML-based service
          F1  = Function ID of FUN_REG_REQ
          F0  = Function ID of FUN_DEREG_REQ
          Fx,y,z = Function IDs of FUN_<other>_REQs
          M,DECK = IE_DATA_MORE containing segment of HDML deck
          F,DECK = IE_DATA_FINAL containing last segment of HDML deck

   Note:  This flow illustrates explicit registration. For implicit
          registration, omit first MNCP packet sequence; MS registers
          MCD upon receipt of FUN_<other>_REQ instead.

                                 Figure A-2.












































<draft-piscitello-mncp-00.txt>                                 Page 54


INTERNET DRAFT                   MNCP                   August 28, 1997



Appendix B. Future Protocol Extensions

   Several extensions are under consideration for the MNCP.

   A reliable delivery that uses a sliding window mechanism to improve
   performance.  The objective is to extend the current positive
   acknowledgment of packets with retransmission by allowing more than one
   packet to be transmitted before waiting for acknowledgment from the
   receiver.  Full or partial window credit indications would accompany
   cumulative acknowledgments returned by the receiver, and selective
   acknowledgments would be a desirable extension as well

   A means of providing data synchronization at the session control level
   that persists beyond the possibly abrupt termination or interruption of
   an underlying connection is desirable.  Such a mechanism would allow a
   mobile computing device to continue a transfer from a commonly agreed
   upon starting point in an octet stream rather than from the beginning
   of the stream.

   It would be desirable to be able to extend the existing "per reliable
   transfer" authentication model in MNCP to support strong authentication
   whether applications are explicitly or implicitly registered.  It would
   also be useful to allow the MCD to verify the authenticity of a
   Mobility Server.

   One method under consideration is to identify an authentication method
   and encode the authentication information appropriate for that method
   in the same registration request or data request packet. The initiator
   (MCD or MS) chooses a method, performs whatever computation is required
   to generate the strong authentication information for that method, and
   then sends the packet.  The initiator decides what security is
   appropriate. A new IE identifying authentication-method can be sent in
   the clear, with the remainder of the PT_NTFN (PT_CMD) (including
   authentication information) encrypted as per the indicated security
   method.




















<draft-piscitello-mncp-00.txt>                                 Page 55