idnits 2.17.1 draft-piscitello-mncp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 54 longer pages, the longest (page 2) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 530 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 775 has weird spacing: '...se, the reque...' == Line 1299 has weird spacing: '...uted as the...' == Line 1606 has weird spacing: '...nf/0 or cnf/...' == Line 1611 has weird spacing: '...nf/0 or cnf/0...' == Line 2127 has weird spacing: '...Request srr...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 28, 1997) is 9736 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1700 (ref. '2') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1974 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 1983 (ref. '4') ** Obsolete normative reference: RFC 1826 (ref. '6') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1825 (ref. '7') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1991 (ref. '8') (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 821 (ref. '10') (Obsoleted by RFC 2821) Summary: 16 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D.Piscitello, 3 Expires: February 28, 1998 L.Phifer 4 Core Competence 5 Y.Wang, 6 R.Hovey 7 Bellcore 8 August 28, 1997 10 Mobile Network Computing Protocol (MNCP) 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "works in progress." 25 To view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Distribution of this memo is unlimited. Please send comments to the 32 authors. 34 Abstract 36 This memo documents an architecture and protocol for mobile network 37 computing. The protocol described herein provides session control and 38 reliable delivery services to accommodate mobile client access to 39 internetworked applications within a 'client-agent-server' 40 architecture. Client middleware based on this architecture can operate 41 over wireless data networking services such as RAM, ARDIS, CDPD, PCS 42 data services and wireless local area networks. This client middleware 43 can be implemented using any standard application programming interface 44 to a commercial UDP/IP stack on Hand-held PC's (HPC), personal digital 45 assistants (PDA's), four-line browsers or 'smart' phones as well as 46 laptop and desktop computers. 48 Table of Contents 50 1. Introduction...........................................................4 51 1.1 Motivation............................................................4 52 1.2 Design Goals..........................................................4 53 1.3 Mobile Network Computing Architecture.................................6 54 1.4 Relationship of MNCP to other Internet Protocols......................7 55 1.5 Requirements..........................................................8 56 1.6 Terms.................................................................8 57 2. Protocol Overview......................................................9 58 2.1 Single Packet Reliable Delivery Service...............................9 59 2.2 Multi-Packet Reliable Delivery Service...............................10 60 2.2.1 NOTIFICATION Packet Processing (Sender)............................10 61 2.2.2 NOTIFICATION Packet Processing (Receiver)..........................12 62 2.2.3 Data Transfer (Sender).............................................12 63 2.2.4 Data Transfer (Receiver)...........................................13 64 2.3 Session Control Service..............................................14 65 2.3.1 Subscriber Validation..............................................14 66 2.3.2 Registration.......................................................14 67 2.3.3 Application Data Transfer..........................................15 68 2.3.4 Deregistration.....................................................15 69 2.3.5 Correlation Identifiers............................................16 70 3. MNCP Reliable Delivery Packets........................................16 71 3.1 Packet Types.........................................................16 72 3.2 Packet Headers.......................................................17 73 3.3 Packet Body..........................................................18 74 3.4 Packet Length........................................................20 75 3.5 Information Elements.................................................20 76 3.5.1 Data (Final and More)..............................................21 77 3.5.2 Message Length.....................................................21 78 3.5.3 Acknowledge Code...................................................22 79 3.5.4 Data Compression...................................................22 80 3.5.5 Data Offset........................................................23 81 3.5.6 Packet Size........................................................23 82 3.6 PT_CMD...............................................................23 83 3.7 PT_ACK...............................................................24 84 3.8 PT_NTFN..............................................................24 85 3.9 PT_DATA..............................................................24 86 4. MNCP Session Control Packets..........................................25 87 4.1 Packet Types.........................................................25 88 4.2 Session Control Headers..............................................25 89 4.3 Session Control Body.................................................26 90 4.4 Packet Length........................................................26 91 4.5 Information Elements.................................................26 92 4.5.1 Subscriber ID......................................................26 93 4.5.2 Application ID.....................................................26 94 4.5.3 Subscriber Password................................................27 95 4.5.4 Registration Status................................................27 96 4.5.5 Message Cross-Correlation ID.......................................27 97 4.5.6 Acknowledge Code...................................................27 98 4.6 FUN_REG_REQ..........................................................28 99 4.7 FUN_DEREG_REQ........................................................28 100 4.8 FUN_..........................................................29 101 5. MNCP Reliable Delivery Processing.....................................29 102 5.1 Phase Diagram........................................................29 103 5.2 State Diagram........................................................31 104 5.3 States...............................................................32 105 5.4 Events...............................................................33 106 5.5 Actions..............................................................34 107 5.6 Timers, Acknowledgment, and Retransmission...........................37 108 5.7 Packet Size Negotiation, Segmentation and Reassembly.................37 109 5.7.1 Computing the payload size for PT_DATA packets.....................38 110 5.7.2 Segmentation and PT_DATA Packet Composition........................38 111 5.7.3 Reassembly.........................................................39 112 5.8 Data Compression.....................................................39 113 6. MNCP Session Control Processing.......................................40 114 6.1 Phase Diagram........................................................40 115 6.2 State Diagram........................................................42 116 6.3 States...............................................................42 117 6.4 Events...............................................................43 118 6.5 Actions..............................................................44 119 7. Security Considerations...............................................48 120 8. References............................................................48 121 9. Authors' Addresses....................................................49 122 Appendix A. HDML Transactions using MNCP.................................50 123 Appendix B. Future Protocol Extensions...................................55 124 1. Introduction 126 1.1 Motivation 128 Mobile network computing, if constrained by consumer interest alone, 129 would at this point in time increase more rapidly than the growth of 130 the Internet itself. Applications that drive consumer interest -- 131 access to the public web and intranets, remote access to corporate and 132 public databases, unified messaging and two-way paging -- are already 133 present and widely available, having already been enabled by public and 134 enterprise IP-based internetworking. 136 The need to access internetworked applications remotely has already 137 been established, but the means of addressing that need are only 138 partially satisfied through the use of wireline and portable (laptop) 139 PC solutions. 141 The rapid acceptance of cellular telephony provides a strong indication 142 of how quickly similarly untethered computer communications will be 143 embraced by consumers. Recent technology advances now make it possible 144 to produce handheld devices that are as small as cellular phones yet 145 smart as portable PC's. These devices are very adapted for wireless 146 communications environments, better able to maintain signal strength 147 and intelligently manage power consumption. It is thus likely that 148 mobile network computers (MNCs), hand-held PC's (HPCs), personal 149 digital assistants, and four-line browser or "smart" phones operating 150 over wireless data networks will complement (or inherit) existing 151 remote access alternatives, and create a potentially enormous consumer 152 market for wireless data networking services such as RAM, ARDIS, CDPD, 153 and PCS data services. 155 This new class of mobile computing devices (MCD's) will often operate 156 in low bandwidth, high latency environments, where it is important to 157 minimize communications consumption. Such environments are not, 158 however, the exclusive operating domains for every mobile computing 159 device, and a device does not have to be among those types previously 160 enumerated to be mobile. Any classification of MCD's must also include 161 desktop and docking laptop computers in wireless LAN environments, 162 where mobility within a building or campus is provided by wireless 163 Ethernet or similar technology. It is also true that many mobile 164 computing devices may be used in both wireless and wireline 165 environments: change a network interface card (NIC) on many of these 166 devices, and the MCD can operate over analog dial, ISDN, or in a LAN. 168 1.2 Design Goals 170 Because of the diverse nature of Mobile Computing Devices, the 171 communications environments over which they may operate, and the 172 applications MCD's may provide, several design goals emerge. 174 1) It is important to minimize communications consumption when low 175 bandwidth, high latency networks are used by MCDs; 176 2) Applications should operate well irrespective of wireless or 177 wireline network characteristics; and 179 3) It should be possible for certain classes of MCD's to operate in a 180 disconnected state. 182 4) It should be relatively simple for end users to change 183 communications environments; optimally, an end user would be able to 184 install the appropriate network interface and begin communicating over 185 a different type of network. 187 5) It is desirable to have a mechanism to allow subscriber 188 identification and authentication to be IP address independent. 190 6) It is desirable to minimize communications consumption for low 191 bandwidth devices with limited battery life. 193 7) Both mobile computing devices and mobility servers should be able to 194 initiate communications and transfers of data; i.e., client initiated 195 or pull" applications as well as server initiated or "push" 196 applications should be accommodated. 198 +----------+ +----------+ +-------+ +---------+ 199 | desktop | | handheld | | PDA | | smart | 200 | PC | | PC | | | | phone | 201 +----------+ +----------+ +-------+ +---------+ 202 | | | | 203 +------------------------------------------------+ 204 | Applications | 205 +------------------------------------------------+ 206 | mobile network computing middleware | 207 +------------------------------------------------+ 208 | commercial UDP/IP implementation | 209 +------------------------------------------------+ 211 Mobile client applications will operate on wireless networks in a 212 bandwidth-latency range where many commercial TCP's have insufficient 213 tuning parameters to permit efficient operation. Custom TCP's might be 214 developed to accommodate the specific bandwidth-delay characteristics 215 of wireless networks, but these custom TCP's would need to be installed 216 in all networked hosts with which the user wishes to communicate, which 217 is not practical. 219 To meet the design goals enumerated, and to avoid situations where the 220 end user would be responsible for reconfiguring TCP for each 221 environment, or where the user might have to install a different TCP 222 entirely to operate over a LAN or wireless WAN, we believe it is 223 appropriate to build a middleware element that can operate on top of 224 any commercial, off-the-shelf UDP/IP implementation. 226 [Note: It is conceivable that a standard TCP could be adapted to 227 satisfy the network transparency design goals. The difficulty with 228 this approach is that it will be some time before this can propagate 229 into existing TCP implementations. More importantly, the existing TCP 230 architecture does not allow optimizations for minimizing communications 231 consumption for low bandwidth devices with limited battery life, as 232 will be described with MNCP.] 234 These requirements suggest that important efficiencies can be achieved 235 by adopting an agent-enabled, transmission independent messaging 236 paradigm. This client-agent-server architecture allows for the 237 introduction of increased efficiencies such as session level data 238 compression. 240 [Note: This client-agent-server relationship is euphemistically 241 referred to as a thin-client architecture. However, it is appropriate 242 to consider so-called thin clients as one of many, rather than the 243 only, type of client accommodated by the MNC architecture.] 245 +-----------+ +-------------+ +-------------+ 246 | Mobile | | Mobile | | Enterprise | 247 | client | | Agent/ | | or | 248 | (HPC,PDA, | | application | | Internet | 249 | laptop.) | | proxy | | application | 250 | | | | | server(s) | 251 +-----------+ +-------------+ +-------------+ 252 | | | | 253 | | | Internet or | 254 |___wireless network__| |___Enterprise network____| 256 In addition, client-server behavior and the "chatty" protocol behavior 257 associated with client-server (web) interaction and transactions can be 258 optimized by introducing a degree of parallelism, i.e., by adopting 259 common service or "session layer" framing as well as application 260 specific framing, on top of traditional transfer control framing. In 261 addition to the operational efficiencies introduced with this approach, 262 mechanisms for providing reliable delivery over wireless technologies 263 can be developed and applied in application, rather than TCP "kernel" 264 and operating system, space. 266 1.3 Mobile Network Computing Architecture 268 The Mobile Network Computing architecture consists of a middleware 269 service component to support user registration and authentication, data 270 transfer (with compression) and reliable delivery. A diverse set of 271 application service components may ride on top of this middleware, each 272 providing application-specific services such as mobile (unified) 273 messaging, paging, browsing, and remote database access. 275 MCD Mobility Server External Server 277 +--------------+ +--------------+ 278 +-------------+ | +--------------+ +-------------+ | 279 |Client App(s)|--+ | Appl Agent | |Server App(s)|--+ 280 +-------------+ +------+-------+ +-------------+ 281 | MNCP | | MNCP | Other | | Other Stack | 282 +-------------+ +------+ Stack | |(HTTP, SMTP, | 283 | UDP | | UDP |(HTTP, | |TCP/IP, etc) | 284 +-------------+ +------+ SMTP, | | | 285 | IP | | IP | TCPIP)| | | 286 +-------------+--------------+-------+-------+-------------+ 287 | Wireless Network | Wireline Network | 288 +----------------------------+-----------------------------+ 290 This internet-draft describes the Mobile Network Computing Protocol, 291 which provides the services ascribed to the middleware component of the 292 architecture. 294 1.4 Relationship of MNCP to other Internet Protocols 296 MNCP is designed to be implemented on top of the Datagram protocol 297 (UDP). MNCP packets have an IP header, a UDP header, and an MNCP 298 header. 300 MCD Mobility Server 301 +--------------+ +--------------+ Server Apps can 302 +-------------+ | +-------------+ | be Local or 303 |Client App(s)|--+ |Server App(s)|--+ Distributed to 304 +-------------+ +-------------+ External Server 305 | MNCP | | MNCP | 306 +-------------+ +-------------+ +-----+-----+--------+ 307 | UDP | | UDP | | IP | UDP | MNCP | 308 +-------------+ +-------------+ | Hdr | Hdr | Packet | 309 | IP | | IP | +-----+-----+--------+ 310 +-------------+------------------------+ ^ ^ 311 | Wireless Network | | +- Src/DestPort 312 +--------------------------------------+ | Checksum 313 +- Src/Dest IP Address 315 The source and destination address fields of the IP header are used by 316 MNCP to identify the requesting and responding hosts. For example, a 317 request initiated by an MCD to a Mobility Server will carry the MCD's 318 IP address in the source field and the Mobility Server's IP address in 319 the destination field. 321 The source and destination port fields of the UDP header are used by 322 identify the requesting and responding MNCP's. An MNCP implementation 323 listens to an assigned "well known" UDP port number (to be assigned and 324 recorded by IANA[2]) for incoming requests, and demultiplexes them to 325 the appropriate application based upon Service ID (see Section 4.5.2). 326 For example, a request initiated by a mobile messaging client 327 application will carry the application's UDP port number in the source 328 port field (selected from the range of values for UDP "ephemeral" or 329 client ports) and the "well known" port number for MNCP in the 330 destination port field. 332 The UDP header length field reflects the total size of the MNCP packet. 333 MNCP relies upon the UDP header's checksum field and error checking to 334 protect the MNCP packet. MNCP provides end-to-end acknowledgment, 335 retransmission, flow control, and segmentation as needed to insulate 336 supported applications from the diverse characteristics of the 337 underlying mobile network. 339 Client and server applications supported by MNCP are identified by a 340 Service ID field carried in the first MNCP packet of each packet 341 sequence. In order to send or receive MNCP packets with a given 342 Service ID, the MCD must register for that service with the Mobility 343 Server. The MNCP is responsible for authenticating the client and 344 performing access control, based upon Subscriber ID and Password fields 345 supplied by the MCD. The MNCP relays messages between server 346 applications and client applications currently registered for that 347 Service ID. 349 1.5 Requirements 350 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 351 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 352 document are to be interpreted as described in RFC 2119[5]. 354 1.6 Terms 355 This memo uses a number of terms to describe components of the MNCP. 356 Other common terms are used as specified in RFC 1983[4]. 358 Mobile Computing Device (MCD) 359 PDA, laptop, hand-held device, desktop PC, or other network computer 360 connected via wireless technology to a Mobility Server. 362 Mobility Server (MS) 363 The system which acts as an application layer gateway or agent between 364 MCDs and networked application services such as mobile messaging or 365 web-enabled database access. 367 Client Application 368 An application located on an MCD which uses MNCP to communicate with 369 Server Applications. 371 Server Application 372 An application conceptually located on a Mobility Server, but which 373 may be physically distributed (i.e., a service-specific application 374 gateway on the Mobility Server relays messages to and from a server 375 application running on an external server). 377 Packet 378 The basic unit of MCNP communication, consisting of a structured 379 sequence of octets matching the syntax defined in Sections 3-4 and 380 transmitted over wireless networks connecting an MCD and its Mobility 381 Server. 383 2. Protocol Overview 384 This section provides a brief overview of each type of service, 385 enumerating the features provided by each service. 387 MNCP operates over the User Datagram Protocol, and relies on UDP 388 protocol for protocol demultiplexing and data integrity . MNCP provides 389 the following basic services: 391 - A single packet (acknowledged datagram) reliable delivery service 392 supports applications where a single datagram request and reply 393 sequence is sufficient for application data transfer. 395 - A multi-packet reliable delivery service supports applications 396 requiring the reliable delivery of arbitrarily long data. 398 - A set of registration and request/response correlation (message flow 399 support) services collectively referred to as SESSION CONTROL. 401 The MNC protocol consists of a message set of four basic packet types: 402 COMMAND, NOTIFICATION, DATA, and ACKNOWLEDGE. Reliable delivery and 403 session control services are provided through the use of Information 404 Elements (IE's) encoded in these four packet types. The encodings of 405 Information Elements for each packet type are described in sections 3 406 and 4. 408 The remainder of section 2 provides an overview of how MNCP provides 409 data transfer and session control services to mobile applications. 411 2.1 Single Packet Reliable Delivery Service 412 The single packet reliable delivery service is an acknowledged datagram 413 service. The service makes use of the COMMAND (PT_CMD) and ACKNOWLEDGE 414 (PT_ACK) packets. The basic features of the service are: 416 - Data transfer 417 - Packet correlation 418 - error detection and recovery using positive acknowledgment with 419 retransmission based on timeout 421 The single packet reliable delivery service is used when an application 422 invokes the service with a request to send data, and a single MNCP 423 datagram request and reply sequence is sufficient for application data 424 transfer. This is true when the total amount of data to be sent is 425 less than or equal to the default packet size (470 octets). 427 The MNCP constructs a COMMAND packet as follows. Common header fields 428 are populated as discussed in section 3.2. A correlation identifier 429 value is chosen for the packet exchange by the MNCP and encoded in the 430 COMMAND packet (see section 2.3.5). Session Control information 431 supplied by the application in the MNCP service request (service, 432 function, and subscriber identifiers, and the subscriber password, see 433 Section 2.3) are encoded in the packet header, along with any 434 application-specific information elements supplied in the request. 435 Application data are then appended to the header as "payload". 437 The COMMAND packet is sent in a UDP packet to the well-known MNCP port 438 (source UDP port value is assigned from UDP client space), and a retry 439 timer is initiated by the sender. If an acknowledgment is not received 440 before the retry timer expires, the COMMAND packet is resent. If a 441 specified maximum number of retry attempts is exceeded and an 442 ACKNOWLEDGMENT is not received, the failure is reported to the 443 application. If an ACKNOWLEDGMENT is received, a confirmation 444 (delivery success or failure) is returned to the application. 446 When a COMMAND packet is received, the MNCP parses the packet and 447 composes and returns a ACKNOWLEDGMENT packet containing a negative ACK 448 code if errors were detected. Otherwise, the MNCP forwards the packet 449 to the MNCP session control for processing (see section 2.3). If 450 subscriber authentication and application service access control are 451 successful, session control passes the contents of the data payload to 452 the application service indicted in the header, and returns a positive 453 acknowledgment to MNCP. If authentication fails, or the subscriber is 454 not authorized to use this application, session control will return a 455 negative acknowledgment code to MNCP. Upon reception of a response 456 from session control, the MNCP composes and returns an ACKNOWLEDGMENT 457 packet with a positive or negative ACK code (the ACK code may be 458 negative, indicating a session control failure, such as an invalid 459 subscriber identifier or password). 461 2.2 Multi-Packet Reliable Delivery Service 462 The multi-packet reliable delivery service is used when an application 463 attempts to send a message that is longer than the default packet size 464 offered (see section 3.4), i.e., when the entire user data, 465 uncompressed, cannot be transferred in a single packet. The service 466 makes use of the NOTIFICATION (PT_NTFN) DATA (PT_DATA) and ACKNOWLEDGE 467 (PT_ACK) packets. The basic features of the service are: 469 - Data Transfer 470 - Packet correlation 471 - Packet size selection 472 - Data compression method selection 473 - Error detection and recovery using positive acknowledgment with 474 retransmission based on timeout 475 - Flow control 476 - Segmentation and reassembly 477 - Data compression (when selected) 479 2.2.1 NOTIFICATION Packet Processing (Sender) 480 When the multi-packet reliable delivery service is used, the MNCP 481 constructs a NOTIFICATION packet to initiate a sequence of data 482 packets. The purpose of the NOTIFICATION packet is to convey to the 483 receiver certain information regarding overall and compressed size of 484 the data to be transferred, and to propose a data compression method 485 and maximum packet size to use when transferring subsequent data in the 486 context of this multi-packet transfer. 488 The NOTIFICATION packet is always default packet size (470 octets) or 489 less, and is constructed as follows. Common header fields are populated 490 as discussed in section 3.2. A correlation identifier value is chosen 491 for the packet exchange by the MNCP (see section 2.3.5) and encoded in 492 the NOTIFICATION packet. The sequence number in the NOTIFICATION is 493 set to an initial value of zero (all subsequent DATA packets within the 494 same packet sequence are incremented sequentially by one). The total 495 (uncompressed) length of the application message to be sent is encoded 496 in the packet as the Original Message Length. 498 To increase network efficiency, the sender can propose to use a packet 499 size larger than the default packet size. For this version of the 500 protocol, the maximum packet size that can be proposed is 2048 octets 501 (see section 3.4). The sender can also propose to use data 502 compression, by specifying a compression method in the Data Compression 503 Option. Proposing a larger packet size and a data compression method 504 are options in the MNCP. 506 Session Control information supplied by the application in the MNCP 507 service request (service, function, and subscriber identifiers, and the 508 subscriber password, see Section 2.3) are encoded in the packet header, 509 along with any application-specific information elements supplied in 510 the request. 512 The NOTIFICATION packet is sent in a UDP packet to the well-known MNCP 513 port (source UDP port value is assigned from client space), and a retry 514 timer is initiated by the sender. If an ACKNOWLEDGMENT packet is not 515 received before the retry timer expires, the NOTIFICATION packet is 516 resent. If a specified maximum number of retry attempts is exceeded 517 and an ACKNOWLEDGMENT packet is not received, a failure is reported to 518 the application (see section 5.6). 520 If an ACKNOWLEDGMENT packet containing a positive ACK code is received, 521 the sender begins transferring application data (see section 2.2.3). 522 If the receiver has accepted an increased packet size, then the sender 523 extracts the packet size specified in the ACKNOWLEDGMENT packet and 524 uses this for subsequent message transfer. The packet size indicated 525 in the ACKNOWLEDGMENT packet may be equal to or less than the size 526 proposed by the sender. If the sender has proposed a data compression 527 method, a positive ACK code indicates that the receiver has agreed to 528 the data compression option proposed by the sender in the NOTIFICATION 529 packet being ACKed. 531 The receiver may return a negative code to reject the compression 532 method proposed in a NOTIFICATION packet, and may propose an 533 alternative compression methods in the ACKNOWLEDGEMENT packet, to 534 expedite the compression selection process. If the sender supports the 535 data compression method proposed, the sender resends the NOTIFICATION, 536 identifying the data compression proposed by the receiver in the 537 ACKNOWLEDGMENT packet; alternatively, the sender may bid a new method. 538 The receiver may again return a negative acknowledgment code to reject 539 the proposed compression method, and (optionally) propose an 540 alternative method. This form of "bidding" continues until a mutually 541 acceptable compression method is identified (no compression is a 542 legitimate option). The sender recognizes that compression selection 543 has concluded when it receives an ACKNOWLEDGMENT packet containing a 544 positive acknowledgment code. 546 [NOTE: Under this compression selection scheme, the sending MNCP must 547 compress the data using a particular algorithm before it sends the 548 PT_NTFN in order to convey the compressed length. This reflects 549 current implementation practice. This memo does not preclude the use 550 and future specification of stream compression algorithms that could be 551 more closely coupled with an underlying transmission service, to 552 optimize performance.] 554 2.2.2 NOTIFICATION Packet Processing (Receiver) 555 The MNCP parses an incoming NOTIFICATION packet and composes and 556 returns a ACKNOWLEDGMENT packet containing a negative ACK code if 557 errors were detected in the common header. Otherwise, the receiver 558 examines the NOTIFICATION packet to determine if the sender has 559 proposed any options. If the sender has proposed a packet size greater 560 than the default packet size, the receiver may agree to use the larger 561 packet size or it may propose an alternative size that is less than the 562 size specified in the NOTIFICATION packet. The receiver can propose a 563 smaller packet size and still return a positive acknowledgment. 565 If the NOTIFICATION proposes a data compression method that is not 566 supported by the receiver, the receiver may reject the proposed data 567 compression method and propose an alternative method in the 568 ACKNOWLEDGMENT packet returned to the sender. As described in section 569 2.2.1, a form of "bidding" continues until both receiver and sender 570 identify a mutually acceptable compression method. 572 When processing associated with multi-packet reliable delivery is 573 completed by the receiver, the MNCP forwards the NOTIFICATION packet to 574 the MNCP session control for processing (see section 2.3). Upon 575 reception of a response from session control, the MNCP composes and 576 returns an ACKNOWLEDGMENT packet with an ACK code indicating success or 577 failure of session control processing. 579 2.2.3 Data Transfer (Sender) 580 When the NOTIFICATION processing is completed, the MNCP attempts to 581 transfer data. The original application data submitted in the request 582 is first compressed (if compression is selected), then segmented into a 583 sequence of DATA packets containing data payloads of size {negotiated 584 packet size - DATA packet header information}, i.e., when constructing 585 a DATA packet, the MNCP attempts to create "n" packets of this fixed 586 size. The last segment of application data transferred in this 587 sequence of DATA packets may contain fewer octets than the negotiated 588 packet size minus the header. 590 The processing and transmission of a sequence of DATA packets is as 591 follows. All packets in a sequence of DATA packets carry the same 592 Correlation Identifier as the NOTIFICATION packet. A Data Offset is 593 encoded in each DATA packet to assist in the reassembly of the 594 application message. The first in a sequence of DATA packets has a 595 Data Offset value of zero . When compression is used, the sending MNCP 596 will fill the first DATA packet to the maximum payload available with 597 compressed data, otherwise, each packet is filled to the maximum 598 payload available with a segment of the original uncompressed message. 600 A sequence number is encoded in each DATA packet to assist in 601 determining packet order. The sequence number of the initial DATA 602 packet in a sequence is set to one (1). 604 For each additional DATA packet in the sequence, the Data Offset value 605 represents the offset from the beginning of the transmitted data 606 (hence, if the message was compressed before it was sent, the offset is 607 relative to the beginning of the compressed message, not the original 608 uncompressed message). The sequence number value is incremented by one 609 for each subsequent segment created. The sequence number is not 610 altered if a packet is retransmitted. 612 Each packet in a sequence of DATA packets except the final DATA packet 613 carries an indication that more DATA packets follow this packet. The 614 final DATA packet may contain less that the maximum data payload number 615 of octets, and must not be padded. 617 Each DATA packet is sent as a UDP packet to the source port which sent 618 the last ACKNOWLEDGMENT packet, and a retry timer is initiated by the 619 sender. If an acknowledgment is not received before the retry timer 620 expires, the DATA packet is resent. If a specified maximum number of 621 retry attempts is exceeded and an ACKNOWLEDGMENT is not received, the 622 failure is reported to the application (see section 5.6). If an 623 ACKNOWLEDGMENT containing the sequence number of the DATA packet sent 624 is received, the next DATA packet in the sequence is transmitted (out 625 of sequence ACKNOWLEDGMENT packets are discarded). Upon reception of a 626 positive ACKNOWLEDGMENT to the final DATA packet, a confirmation is 627 provided to the sending application, indicating successful delivery. 629 2.2.4 Data Transfer (Receiver) 630 When the receiver sends a positive ACKNOWLDEGMENT in response to a 631 NOTIFICATION request, the receiving MNCP awaits the arrival of DATA 632 packets. 634 Reliable delivery of data is achieved through the use of a stop-and-go 635 with timeout retransmission mechanism. Each DATA packet must be 636 individually acknowledged by the receiving MNCP. The ACKNOWLEDGMENT 637 packet must contain the same sequence number as the packet it is 638 acknowledging. 640 Out of sequence DATA packets (any packet with a previously acknowledged 641 sequence number or a packet whose sequence number is greater than the 642 next expected sequence number) are discarded by the receiving MNCP. As 643 part of the processing of out of sequence DATA packets, the receiving 644 MNCP returns an ACKNOWLEDGEMENT packet containing the sequence number 645 of the most recently acknowledged DATA packet. 647 The receiver processes the incoming DATA packets as follows. As part 648 of the process of determining whether a properly composed DATA packet 649 has arrived, the receiver checks to see if the correlation identifier 650 in the packet corresponds to a transfer in progress; if the packet is 651 incorrectly composed or the correlation identifier is unknown (not 652 associated with a transfer in progress), the packet is discarded. If 653 the DATA packet is valid, the receiver uses the packet contents 654 (correlation identifier, data offset, sequence number, more/final 655 information, application data) and information relayed in the 656 NOTIFICATION request (message length, compressed and uncompressed, 657 compression method) to reassemble the application data. The receiver 658 composes and returns an ACKNOWLDEGEMENT packet containing the 659 correlation identifier and sequence number from the DATA packet being 660 acknowledged. The ACKNOWLEDGEMENT packet is sent as a UDP packet to the 661 source port which sent the DATA packet being acknowledged. 663 Reassembly of application data continues in this manner until a DATA 664 packet containing a "final data" indicator is processed. The 665 reassembled data are uncompressed (if compression was used). 666 Application-specific information elements are forwarded to the 667 application, and a final ACKNOWLEDGEMENT packet is sent as a UDP packet 668 to the source port which sent the DATA packet being acknowledged. 670 2.3 Session Control Service 671 MNCP session control packets are exchanged between an MCD and a 672 Mobility Server using MNCP reliable delivery packets. The purpose of 673 session control is to provide user validation (authentication), 674 application access control, user registration (deregistration) for 675 application services, and application request/response correlation. 677 2.3.1 Subscriber Validation 678 User validation (authentication) is based on a subscriber identifier 679 and subscriber password. A subscriber identifier is assigned to the 680 user of a mobile computing device, and is intended to be independent 681 from any lower layer (e.g., IP) addressing or identification. In 682 particular, access controls to applications and services may be based 683 on subscriber identification, allowing the subscriber to access these 684 applications irrespective of the IP or equivalent network address the 685 user of an MCD is (temporarily) using for communication with a Mobility 686 Server. 688 Applications and specific functions of applications that may be 689 accessed by a user of a MCD (remotely invoked operations) are 690 identified by a service identifier, which is globally unique and IANA- 691 assigned, and a function identifier, which is service-specific. 692 Application registration and deregistration are functions performed for 693 all application services, and fall within session control, whereas 694 other functions, such as a "check mailbox status" function, are 695 specific to an application (mobile messaging), and are thus transparent 696 to the MNCP. 698 2.3.2 Registration 699 Registration is a process whereby a client (MCD) notifies a Mobility 700 Server of its intent to make use of an application service. An 701 explicit form of registration is accomplished as follows. Session 702 control information (subscriber identification and authentication 703 information, application service and function identification) is 704 supplied by the client application to the MCD's MNCP and encoded as 705 information elements in a REGISTRATION request (see also section 2.1). 706 A registration request is sent by a client (MCD) MNCP using the single 707 packet reliable delivery mechanism. 709 The receiving MNCP (here, the Mobility Server) uses the subscriber 710 identification and authentication information to validate the user and 711 to determine whether the user has access privileges to the application 712 service and function identified. The receiving (MS) MNCP returns a 713 positive or negative ACKNOWLEDGMENT based on the success or failure of 714 authentication and access control processing. If the authentication 715 succeeds, the (MS) MNCP updates the status of the subscriber to 716 "registered", records the IP address of the MCD from which the 717 subscriber's registration request was initiated, and returns a positive 718 ACKNOWLEDGEMENT. The (MS) MNCP starts a timer that bounds the amount 719 of time the registered subscriber may be inactive before the subscriber 720 is declared unavailable (see sections 4.7 and section 6.4). 722 [NOTE: Explicit registration may be used to enable "push" applications. 723 Once a client application at an MCD is registered, an application at a 724 Mobility Server may send unsolicited messages to the MCD.] 726 A second, implicit form of registration occurs when an application at a 727 Mobility Server receives requests for a service from a MCD that has not 728 explicitly registered for that service. If the subscriber 729 identification and authentication are valid, and access to this service 730 is permitted for this subscriber, the MS will register the client (MCD) 731 as previously described, and process the service request (see section 732 2.3.3 and section 3). 734 Once a subscriber has registered, a Mobility Server will forward all 735 subsequent subscriber-bound messages to the MCD at the IP address 736 recorded, until the subscriber explicitly deregisters the service, or 737 registers the service from another MCD, or from a different IP address. 739 2.3.3 Application Data Transfer 740 Once registration is completed, applications at either the MCD or MS 741 may begin sending requests. Session Control information (application 742 service and function identification, subscriber identification and 743 password, request/response message correlation information) accompany 744 application-specific control information and data in each request. 745 Each request (carried as a COMMAND packet or a NOTIFICATION packet 746 initiating a multi-packet sequence) is authenticated. If 747 authentication succeeds and all the contents are reliably delivered, a 748 positive ACKNOWLEDGEMENT is returned to the MCD MNCP. Application- 749 specific IE's as well as data are forwarded to the application when the 750 entire request has been delivered. 752 2.3.4 Deregistration 753 Deregistration may be initiated by the MCD application. A request to 754 deregister from an application service results in the transmission of a 755 DEREGISTER function by session control to the Mobility Server's (MS) 756 MNCP. Deregistration can also occur when an inactivity timer operating 757 at the Mobility Server expires. When either of these events occurs, 758 the (MS) MNCP deregisters the subscriber (i.e., changes the 759 registration status to deregistered for the application service 760 indicated in the request). The MNCP requesting deregistration (either 761 the MCD or MS) composes and sends a Deregistration request and awaits 762 an indication from reliable transfer that 764 (a) the MCD MNCP has responded with an ACKNOWLDGEMENT indicating it 765 wishes to continue communicating with the server. In this case, the 766 (MS) MNCP updates the registration status of the client (to 767 registered). 769 (b) the (MCD or MS) MNCP has responded with an ACKNOWLEDGEMENT 770 indicating it agrees to discontinue communication. In this case, the 771 requesting MNCP remains in an unregistered (i.e., inactive) status. 773 (c) retry timer expiration causes the reliable delivery MNCP to 774 indicate to session control that communication attempts have been 775 abandoned. In this case, the requesting MNCP remains in an 776 unregistered (i.e., inactive) status. 778 2.3.5 Correlation Identifiers 779 The correlation identifier is used by Session Control to associate 780 packets (or packet sequences) of a given exchange, and is relevant for 781 both directions of information flow (i.e., the acknowledgment for a 782 NOTIFICATION, COMMAND, and DATA packet must have the same correlation 783 identifier) for the duration of that exchange. The correlation 784 identifier has local significance to the mobile computing device or 785 Mobility Server. 787 Applications may use a Correlation Identifier value to link together or 788 "cross-correlate" packet sequences related to the same application- 789 specific message flow. Consider an e-mail client application request 790 from a MCD to retrieve mailbox messages. The request could be 791 satisfied using a single COMMAND-ACK sequence. The corresponding 792 responses could be conveyed as a packet sequence involving the use of 793 the NOTIFICATION service initiated by a messaging application operating 794 on a Mobility Server. The Cross-correlation Identifier value used by 795 the Mobility Server when delivering the contents of the mailbox to the 796 email client must be the same as the Correlation Identifier of the 797 original request to retrieve mailbox messages (see section 4.5.5). 799 3. MNCP Reliable Delivery Packets 800 This section defines the packets which support MNCP reliable delivery 801 services. 803 3.1 Packet Types 804 MNCP reliable delivery packets are exchanged between an MCD and a 805 Mobility Server. There are four types of MNCP reliable delivery 806 packets, differentiated by the Packet Type field in the Packet Header. 808 Command Packet (PT_CMD) 809 This packet is used when the entire length of the application data can 810 be carried in a single packet. 812 Notification Packet (PT_NTFN) 813 This packet is used when the entire length of the user data can not 814 fit into a single packet. It is followed by one or more PT_DATA 815 packets. 817 Data Packet (PT_DATA) 818 This packet is used in conjunction with the Notification Packet to 819 carry the actual application data. 821 Acknowledge Packet (PT_ACK) 822 This packet is used to confirm receipt of a PT_CMD, PT_NTFN, or 823 PT_DATA packet by the peer MNCP. 825 MNCP reliable delivery packets PT_CMD, PT_NTFN, and PT_DATA can 826 originate from either the MCD or the Mobility Server. Acknowledgments 827 (PT_ACKs) are returned by the recipient of the other packets. 829 Exactly one MNCP reliable delivery packet is encapsulated in each UDP 830 Information field as an octet sequence, encoded in network-byte order. 832 3.2 Packet Headers 833 The following common header fields appear in every MNCP reliable 834 delivery packet. A summary of the packet header format is shown below. 835 The bits are transmitted in network-byte order, from left to right. 837 0 1 2 838 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 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Major Version | Minor Version | Packet Type | .. 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 2 3 4 5 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Correlation Id | Sequence Number | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 Major and Minor Protocol Version 849 Two one octet Protocol Version fields identify the Major and Minor 850 Version level of the MNCP packet. The values (1,1) MUST be used to 851 indicate the MNCP protocol version specified by this memo. When a 852 packet is received with an unknown Protocol Version value, the packet 853 SHOULD be silently discarded. 855 Packet Type 856 The Packet Type field is one octet, and identifies the type of MNCP 857 reliable delivery packet as enumerated below. 859 1 PT_CMD Command 860 2 PT_NTFN Notification 861 3 PT_DATA Data 862 4 PT_ACK Acknowledge 864 When a packet is received with an unknown Packet Type value, the 865 packet SHOULD be silently discarded. 867 Correlation Id 868 The Correlation Id field is two octets, and is used to link together 869 all the packets in a particular packet sequence. When initiating a 870 new packet sequence, applications at a Mobility Server MUST select 871 values in the range h0001 - h7FFF (i.e., the most significant bit must 872 be zero, 0). When initiating a new packet sequence, applications at a 873 MCD MUST select values in the range h8000-hFFFF (i.e., the most 874 significant bit must be one, 1). The value zero is reserved and MUST 875 NOT be used. 877 When a PT_DATA or PT_ACK packet is received with an unknown 878 Correlation Identifier field, or any other type of packet is received 879 with a missing Correlation Identifier field, the packet SHOULD be 880 silently discarded. 882 The MNCP that initiates a packet sequence (i.e., sends a PT_CMD or 883 PT_NTFN packet) MUST ensure that the Correlation Identifier value 884 uniquely identifies the packet sequence locally (i.e., no other packet 885 sequence is in progress involving this MCD and the same Correlation 886 Identifier value). All other packets in this packet sequence 887 (including PT_ACKs) MUST carry this same Correlation Identifier value. 889 Applications may use the same Correlation Identifier value to link 890 together packet sequences related to the same application-specific 891 message flow. For example, an e-mail client request might be conveyed 892 by a PT-CMD packet sequence, with mail server responses conveyed as 893 PT-NTFN packets sequences, all of which carry Cross Correlation 894 Identifiers equal to the Correlation Identifier of the original 895 request. 897 Sequence Number 898 The Sequence Number field is two octets, and is used to maintain 899 sequencing of packets. When a packet is received with a missing or 900 unknown Sequence Number field, the packet SHOULD be silently 901 discarded. 903 The sequence number MUST have the value zero (0) for the first packet 904 of a packet sequence. The sequence number contained in each 905 subsequent PT_DATA packet within the same packet sequence MUST be 906 incremented sequentially by one (1) until the maximum field value 907 (65,536) has been reached, and then recycled back to zero(0). 909 3.3 Packet Body 910 The body an MNCP packet is used to carry MNCP reliable delivery control 911 information, session control information, and application-specific 912 data. The MNCP packet body is transmitted immediately after the MNCP 913 packet header, beginning at bit 56 of the entire MNCP reliable delivery 914 packet. 916 5 6 7 8 917 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 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | MNCP Packet Body (1..N Information Elements) .. 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 The MNCP reliable delivery packet body consists of one or more 923 Information Elements (IEs). Each Information Element consists of an IE 924 Type field, IE Length field, and a variable-length data field (content 925 determined by the IE Type, length identified by the IE Length). There 926 are two Information Element formats: an extended length format used 927 only for IE_DATA_MORE and IE_DATA_FINAL elements, and an abbreviated 928 format used for all other currently-defined IE Types. 930 A summary of the Information Element field format is shown below. The 931 fields are transmitted in network-byte order, from left to right, 932 beginning with the first available bit after the MNCP packet header or 933 preceding Information Element. 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | IE Type=Other | IE Length | IE Data (1..N octets) .. 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 OR 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | IE Type=DATA | IE Length |IE Data(1..N oct).. 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 IE Type 946 The IE Type field is one octet, and identifies the type of Information 947 Element as enumerated below. 949 5 IE_DATA_FINAL Data (Final) 950 6 IE_DATA_MORE Data (More) 951 8 IE_MSG_LENGTH Message Length 952 10 IE_ACK_CODE Acknowledge Code 953 16 IE_DATA_COMPRESSION Data Compression 954 18 IE_DATA_OFFSET Data Offset 955 20 IE_PKT_SIZE Packet Size 957 Additional IE Type values are defined by MNCP Session Control (see 958 Section 4.5) and may also be defined for use by specific applications 959 (to be assigned and recorded by IANA[2]). When a packet is received 960 with an unknown IE Type value, the Information Element SHOULD be 961 forwarded to the application without further interpretation by the 962 MNCP. 964 IE Length 965 If the IE Type equals IE_DATA_MORE or IE_DATA_FINAL, the IE Length 966 field is two octets; otherwise, the IE Length field is one octet. The 967 IE Length field indicates the length of the information element data 968 field, in octets. 970 Octets beyond the range of the IE Length field are treated as a 971 separate Information Element. When a packet is received with an 972 invalid Length field, the packet SHOULD be silently discarded. 974 IE Data 975 The format of the IE Data field varies according to IE Type. The 976 format associated with each IE Type is defined in Sections 3.5 and 977 4.5. 979 When encoding MNCP packets, the following general rules apply, in order 980 of priority. 982 - Required IEs MUST appear before optional IEs, and 983 - Fixed-length IEs MUST appear before variable-length IEs. 985 3.4 Packet Length 986 The length of each MNCP reliable delivery packet is the sum of the 987 following: 989 MNCP Header Length 7 octets 990 MNCP Body Length sum of Information Element lengths 992 When IE Type is IE_DATA_MORE or IE_DATA_FINAL, the length of the 993 Information Element is three(3) octets plus the value specified by the 994 IE Length field. Otherwise, the length of the Information Element is 995 two (2) octets plus the value specified by the IE Length field. Since 996 every MNCP reliable delivery packet contains at least one Information 997 Element, the minimum length of a packet is 10 octets. 999 The maximum length of an MNCP packet, MAX_PACKET_SIZE, is limited to 1000 2048 octets. The default packet size, DEFAULT_PACKET_SIZE, is 470 1001 octets, chosen because it is the most efficient size that can be 1002 transported by UDP over wireless Mobitex networks. In order to 1003 increase network efficiency, the sending MNCP may propose a packet 1004 length greater than DEFAULT_PACKET_SIZE, but less than or equal to 1005 MAX_PACKET_SIZE. The receiving MNCP may accept the proposed value or 1006 request a smaller packet length. The selection of an appropriate 1007 packet size is affected by factors such as the Maximum Transmission 1008 Unit (MTU) and Maximum Segment Size (MSS) of the underlying network. 1010 When an application message is longer than the negotiated packet size 1011 (less header and protocol control information overhead), it MUST be 1012 segmented into more than one MNCP reliable delivery packet. In this 1013 case, the length of the complete application message is indicated by 1014 the IE_MSG_LENGTH Information Element included in the PT_NTFN packet 1015 (see Section 3.5.2). 1017 3.5 Information Elements 1018 Each Information Element includes IE Type and IE Length fields, 1019 formatted as described in Section 3.3. Information Elements related to 1020 reliable transfer are defined below; additional elements related to 1021 session control are defined in Section 4.5. 1023 When a packet is received with a syntactically invalid Information 1024 Element, the packet MUST be acknowledged with the Ack Code 1025 ACK_ERR_INFO. When a packet is received without a required Information 1026 Element, the packet MUST be acknowledged with the Ack Code 1027 ACK_ERR_PROT. 1029 3.5.1 Data (Final and More) 1030 0 1 2 3 1031 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 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 |T=IE_DATA_FINAL| Length=1..N | Data (1..N) .. 1034 |or IE_DATA_MORE| where N = (MAX_PACKET_SIZE - header length) 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 Data 1038 The Data field is variable length, ranging from one to 1039 (MAX_PACKET_SIZE - header) octets, and carries application-dependent 1040 content. 1042 The IE Type MUST equal IE_DATA_FINAL if the data field contains the 1043 only or final segment of an application message. Otherwise, the IE 1044 Type MUST equal IE_DATA_MORE, indicating that the remainder of the 1045 application message will be sent in subsequent PT_DATA packets. 1047 In a PT_DATA packet, the content of the data field may be compressed 1048 (see Section 3.5.4). 1050 3.5.2 Message Length 1051 0 1 1052 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 |T=IE_MSG_LENGTH| Length=8 |.. 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 1 2 3 4 1057 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 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Original Message Length |.. 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 4 5 6 7 1062 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 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Compressed Message Length | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 Original Message Length 1068 The Original Message Length field is four octets, and identifies the 1069 length, in octets, of the original application message to be 1070 transferred during an MNCP reliable delivery packet sequence. 1071 Providing this value allows the receiving MNCP to allocate adequate 1072 buffer space in which to build the decompressed message. 1074 Compressed Message Length 1075 The Compressed Message Length field is four octets, and identifies the 1076 length, in octets, of the same application message after compression. 1078 This indicates the number of data octets to be carried by the sequence 1079 of PT_DATA packets which follow this PT_NTFN packet, and may equal 1080 Original Message Length if no compression algorithm has been 1081 negotiated. Providing this value allows the receiving MNCP to 1082 allocate adequate buffer space in which to reassemble the compressed 1083 message. 1085 3.5.3 Acknowledge Code 1086 0 1 2 3 1087 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 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 |Typ=IE_ACK_CODE| Length=2 | Ack Code | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 Ack Code 1093 The Ack Code field is two octets, and indicates success or failure of 1094 MNCP packet processing. Values associated with reliable transfer 1095 processing are enumerated below; additional session control-related 1096 values are enumerated in Section 4.5.6. 1098 ACK_OK 0 Success, no error 1099 ACK_ERR_MCD 1 Unrecognized MCD 1100 ACK_ERR_FILE_IO 9 Storage or File I/O error 1101 ACK_ERR_INFO 11 Invalid parameters/command syntax 1102 ACK_OOS_COMPRESS 12 Compression method not supported 1103 ACK_ERR_PROT 13 Protocol Error 1104 ACK_ERR_SYS 65535 Unrecoverable System Error 1106 3.5.4 Data Compression 1107 0 1 2 1108 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 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 |T=IE_DATA_COMP | Length=1 | Compression | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 Compression 1114 The Compression field is one octet, and identifies the compression 1115 method to be used on the data contained within PT_DATA packet 1116 IE_DATA_MORE and IE_DATA_FINAL information elements, as enumerated 1117 below. 1119 COMPRESS_OFF 0 Data MUST NOT be compressed 1120 COMPRESS_DEFAULT 1 Data MUST be compressed using default 1121 method, LZS, as defined by RFC 1974[3] 1123 Additional values for this field may be assigned and recorded by 1124 IANA[2]. Section 5.8 describes how this field is used for negotiation 1125 in PT_NTFN and PT_ACK packets. 1127 3.5.5 Data Offset 1128 0 1 1129 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 |T=IE_DATA_OFF | Length=8 |.. 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 1 2 3 4 1134 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 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Data Offset | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 Data Offset 1140 The Data Offset field is four octets. When uncompressed data are 1141 sent, Data Offset identifies the offset, in octets, of the first bit 1142 of the IE_DATA_MORE or IE_DATA_FINAL Data field from the beginning of 1143 the original uncompressed message. When compression is used, Data 1144 Offset identifies the offset, in octets, of the first bit of the 1145 IE_DATA_MORE or IE_DATA_FINAL Data field from the beginning of the 1146 compressed message. 1148 3.5.6 Packet Size 1149 0 1 2 3 1150 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 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 |Typ=IE_PKT_SIZE| Length=2 | Packet Size | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 Packet Size 1156 The Packet Size field is two octets, and identifies the maximum size 1157 (in octets) for PT_DATA packets in this MNCP packet sequence. Section 1158 5.7 describes how this field is used for negotiation in PT_NTFN and 1159 PT_ACK packets and how it affects segmentation of application data in 1160 PT_DATA packets. 1162 The default value for this field is DEFAULT_PACKET_SIZE (470 octets). 1163 The maximum value for this field is MAX_PACKET_SIZE (2048 octets). If 1164 this field is absent from a PT_NTFN packet, the default value MUST be 1165 assumed. 1167 3.6 PT_CMD 1168 When an application wishes to send a message that is shorter than 1169 (DEFAULT_PACKET_SIZE - header) octets, uncompressed, the MNCP MUST 1170 embed it in the IE_DATA_FINAL field of a PT_CMD packet. 1172 Upon reception of a correctly-formed PT_CMD packet, a PT_ACK MUST be 1173 transmitted, containing a positive or negative Ack Code as described in 1174 Section 3.7. 1176 The following IEs are optional in a PT_CMD packet. 1178 IE_DATA_FINAL As defined in Section 3.5.1 1179 MUST be present if application data 1180 has been supplied by the user. 1182 Additional session control or application-specific IEs may also be 1183 included in the PT-CMD packet. 1185 3.7 PT_ACK 1186 Upon reception of a correctly-formed PT_CMD, PT_NTFN, or PT_DATA 1187 packet, a PT_ACK MUST be transmitted to confirm delivery. The PT_ACK 1188 includes the same Correlation ID and Sequence Number as the packet to 1189 be confirmed, and an Ack Code to indicate the success or failure of 1190 packet processing within the MNCP. 1192 The following IE is required in a PT_ACK packet. 1194 IE_ACK_CODE As defined in Section 3.5.3 1196 Additional session control IEs and application-specific IEs may also be 1197 included in the PT_ACK packet. 1199 3.8 PT_NTFN 1200 When an application wishes to send a message that is longer than 1201 (DEFAULT_PACKET_SIZE - header) octets, uncompressed, the MNCP MUST 1202 generate a PT_NTFN packet to initiate a sequence of PT_DATA packets. 1204 Upon reception of a correctly-formed PT_NTFN packet, a PT_ACK MUST be 1205 transmitted, containing a positive or negative Ack Code as described in 1206 Section 3.7. 1208 The following IEs are required in a PT_NTFN packet. 1210 IE_MSG_LENGTH As defined in Section 3.5.2 1212 The following IEs are optional in a PT_NTFN packet. 1214 IE_DATA_COMPRESSION As defined in Section 3.5.4 1215 MUST be present if compression desired 1216 otherwise default value assumed 1218 IE_PKT_SIZE As defined in Section 3.5.6 1219 MUST be present if long packets desired 1220 otherwise default value assumed 1222 Additional application-specific IEs may also be included in the PT-NTFN 1223 packet. 1225 3.9 PT_DATA 1226 When an application wishes to send a message that is longer than 1227 (DEFAULT_PACKET_SIZE - header) octets, uncompressed, the MNCP generates 1228 a sequence of PT_DATA packets to carry message segments. The final 1229 PT_DATA packet carries the information element IE_DATA_FINAL; all 1230 others carry the information element IE_DATA_MORE. These packets carry 1231 the same Correlation ID and sequentially-assigned Sequence Numbers. 1233 Upon reception of each correctly-formed PT_DATA packet, a PT_ACK MUST 1234 be transmitted, containing a positive or negative Ack Code as described 1235 in Section 3.7. 1237 The following IEs are required in a PT_DATA packet. 1239 IE_DATA_OFFSET As defined in Section 3.5.5 1240 IE_DATA_MORE or 1241 IE_DATA_FINAL As defined in Section 3.5.1 1243 4. MNCP Session Control Packets 1244 This section defines the packets which support MNCP session control 1245 services. 1247 4.1 Packet Types 1248 MNCP session control packets are exchanged between an MCD and a 1249 Mobility Server using MNCP reliable delivery packets. There are three 1250 types of MNCP session control packets, differentiated by the Function 1251 ID field of the IE_APP_ID information element in the MNCP session 1252 control header. 1254 Registration Packet (PT_CMD, Function ID = FUN_REG_REQ) 1255 This packet is used to register a Subscriber to use the specified 1256 Service. 1258 Deregistration Packet (PT_CMD, Function ID = FUN_DEREG_REQ) 1259 This packet is used to deregister a Subscriber so that it can no 1260 longer use the specified Service. 1262 Application Request Packet (PT_CMD or PT_NTFN, Function ID = other) 1263 This packet is used to request an application-specific service, 1264 specified by Service ID and Function ID. 1266 Registration packets originate from the MCD, to be processed and 1267 acknowledged by the Mobility Server. Deregistration and Application 1268 Request packets can be initiated by either the MCD or Mobility Server. 1270 Exactly one MNCP session control packet is conveyed by each PT_CMD or 1271 PT_NTFN packet, utilizing those fields previously defined for MNCP 1272 reliable delivery, and the additional Session Control fields defined in 1273 this section. 1275 4.2 Session Control Headers 1276 Information Element types defined specifically for use as MNCP Session 1277 Control header fields are enumerated below and defined in Section 4.5. 1279 1 IE_SUB_ID Subscriber ID 1280 3 IE_APP_ID Application ID 1281 9 IE_SUB_PWD Subscriber Password 1283 These Information Elements are mandatory in every MNCP session control 1284 packet, regardless of Service ID or Function ID, and may appear 1285 anywhere within the list of Information Elements in an MNCP packet. 1287 4.3 Session Control Body 1288 Information Element types defined specifically for use as MNCP Session 1289 Control body fields are enumerated below and defined in Section 4.5. 1291 11 IE_REG_STATUS Registration Status 1292 24 IE_CROSS_ID Message Cross-correlation ID 1294 These Information Elements may be included in certain MNCP session 1295 control packets, as determined by Function ID, and may appear anywhere 1296 within the list of Information Elements in an MNCP packet. 1298 4.4 Packet Length 1299 The length of the MNCP session control packet can be computed as the 1300 sum of the lengths of each session control Information Element. 1302 4.5 Information Elements 1303 Each Information Element includes IE Type and IE Length fields, 1304 formatted as described in Section 3.3. Information Elements related to 1305 reliable transfer are defined in Section 3.5; additional elements 1306 related to session control are defined below. 1308 4.5.1 Subscriber ID 1309 0 1 2 3 1310 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 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 |Type=IE_SUB_ID | Length=1...N | Subscriber ID (1..N octets) ... 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 Subscriber ID 1316 The Subscriber ID field is variable length, and identifies the user of 1317 the MCD. This value is used by MNCP Session Control to provide 1318 subscriber validation/authentication (see Section 7). 1320 4.5.2 Application ID 1321 0 1 2 3 1322 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 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 |Type=IE_APP_ID | Length=2 | Service ID | Function ID | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 Service ID 1328 The Service ID field is one octet, and identifies the Information 1329 Service (specific application) involved in this MNCP packet sequence. 1330 This field identifies both the application which originated the 1331 message and the destination application that is to receive the 1332 message. 1334 Service ID values are assigned and recorded by IANA[2] for use by 1335 specific applications. Service ID is used by MNCP Session Control to 1336 provide service registration, deregistration, and filtering features. 1338 Function ID 1339 The Function ID field is one octet, and identifies the function within 1340 the specified Service requested by this MNCP packet, as enumerated 1341 below. 1343 0 FUN_DEREG_REQ Deregistration Request 1344 1 FUN_REG_REQ Registration Request 1345 2..255 TBD Application-Dependent 1347 Function ID values zero (0) and one (1) are reserved for use by MNCP 1348 Session Control. Function ID values 2 through 255 are application- 1349 dependent, and are transparent to the MNCP. 1351 4.5.3 Subscriber Password 1352 0 1 2 1353 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 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 |Type=IE_SUB_PWD| Length=4..N |Subscriber Password(4..N octets).. 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 Subscriber Password 1359 The Subscriber Password field is variable length, ranging from four to 1360 N octets, and carries a value used by MNCP Session Control for user 1361 validation/authentication (see Section 7). 1363 4.5.4 Registration Status 1364 0 1 2 9 1365 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 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 |T=IE_REG_STATUS| Length=1..N |Registration Status(1..N octets)| 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 Registration Status 1371 The Registration Status field is a variable length field, where each 1372 octet contains the ID of a Service for which this Subscriber is 1373 currently registered. 1375 4.5.5 Message Cross-Correlation ID 1376 0 1 2 3 1377 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 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 |Typ=IE_CROSS_ID| Length=2 | Cross Correlation ID | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 Message Cross-correlation ID 1383 The Message Cross-correlation ID is two octets, and carries a 16-bit 1384 unsigned integer number identifying the correlation ID of a previous 1385 message flow to which the current message flow is associated. Using a 1386 cross-correlation identifier, a receiving application correlates a 1387 response message with a previous request message. 1389 4.5.6 Acknowledge Code 1390 MNCP Session Control defines additional values for the Ack Code field 1391 specified in Section 3.5.3. 1393 ACK_ERR_SID 2 Unrecognized Subscriber ID 1394 ACK_ERR_PWD 3 Incorrect Password 1395 ACK_OOS_SID 5 Subscriber ID is suspended 1396 ACK_OOS_SVC 10 Application service unavailable 1398 4.6 FUN_REG_REQ 1399 When an application wishes to explicitly register for a specific 1400 Service ID (see section 2.3.2), it MUST first generate a Registration 1401 Request by issuing a PT_CMD packet with the desired Service ID and 1402 Function ID set to FUN_REG_REQ. 1404 Upon reception of a Registration Request, MNCP session control performs 1405 authentication based upon Service ID, Subscriber ID, and Password, 1406 marking the subscriber as "registered" and recording the IP address of 1407 the MCD from which the request was received if the subscriber is 1408 determined to be authentic and authorized to use the service. A PT_ACK 1409 MUST be transmitted in response, containing a positive or negative Ack 1410 Code as described in Section 4.5.6. In addition, as an implementation 1411 option, the PT_ACK MAY contain the IE_REG_STATUS Information Element 1412 described in Section 4.5.4. 1414 4.7 FUN_DEREG_REQ 1415 When an application wishes to stop using a specific Service ID, it may 1416 generate a Deregistration Request by issuing a PT_CMD packet with the 1417 desired Service ID and Function ID set to FUN_DEREG_REQ. 1419 The MCD MNCP MAY deregister from a service by generating a 1420 Deregistration Request, either implicitly on behalf of the application, 1421 explicitly upon application request, or both. Upon receiving an MCD- 1422 initiated Deregistration Request, the MS MNCP session control performs 1423 authentication based upon Service ID, Subscriber ID, and Password, 1424 marking the subscriber as "deregistered" if authorized to use the 1425 service. A PT_ACK MUST be transmitted in response, containing an Ack 1426 Code as described in Section 4.5.6. 1428 An MS MNCP that has not detected activity on the part of a registered 1429 subscriber for a given period of time (INACTIVITY_TIMER) MAY attempt to 1430 deregister the subscriber implicitly by generating a Deregistration 1431 Request. Upon receiving an MS-initiated Deregistration Request, the 1432 MCD MNCP determines whether the application identified by the service 1433 ID is still running. If so, the MCD MNCP MUST return a PT_ACK (ACK_OK) 1434 and the MS MNCP MUST re-register the subscriber. Otherwise, the MCD 1435 MNCP returns a PT_ACK (ACK_OOS_SVC) and the MS interprets this as a 1436 confirmation that the application service is no longer running on the 1437 subscriber's MCD. 1439 In addition, as an implementation option, these PT_ACKs MAY contain the 1440 IE_REG_STATUS Information Element described in Section 4.5.4. As a 1441 security precaution, this field SHOULD NOT be included when 1442 acknowledging a Deregistration Request that has not passed 1443 authentication. 1445 4.8 FUN_ 1446 When an application wishes to send a request with a specific Service 1447 ID, it MUST generate an Application Request by issuing a PT_CMD or 1448 PT_NTFN packet with the desired Service ID and Function ID. 1450 Upon reception of an Application Request, and if the subscriber is 1451 currently registered to use the service, MNCP session control performs 1452 authentication based upon Service ID, Subscriber ID, and Password, and 1453 forwards the request to the destination application. 1455 If the subscriber is not currently registered to use the service, MNCP 1456 session control performs authentication based upon Service ID, 1457 Subscriber ID, and Password. If the subscriber is determined to be 1458 authentic and permitted to access the service, MNCP session control 1459 marks the subscriber as "registered" and forwards the request to the 1460 destination application (implicit registration). 1462 For either case, a PT_ACK MUST be transmitted in response, containing a 1463 positive or negative Ack Code as described in Section 4.5.6. A 1464 positive Ack Code indicates that the request can be delivered to the 1465 destination application; a negative Ack Code indicates why the request 1466 cannot be delivered. 1468 5. MNCP Reliable Delivery Processing 1470 5.1 Phase Diagram 1471 MNCP reliable delivery goes through three distinct phases which are 1472 specified in the following simplified diagram. 1474 +------+ +---------------+ 1475 | | PT_CMD | | 1476 | |---------------------------------->| | 1477 | Idle | +-------------+ | Data Transfer | 1478 | | PT_NTFN | | PT_DATA | | 1479 | |---------->| Negotiation |-------->| | 1480 | | ^ | | ^ | | 1481 +------+ | +-------------+ | +---------------+ 1482 ^ PT_ACK(C) | | | | | | 1483 | or TMO <----+ | TMO <----+ | 1484 <--------------------------+-------------------------+ 1485 PT_ACK(OK), PT_ACK(ERR), or TMO & retries exhausted 1487 TMO = timeout expires 1488 PT_ACK(C) = PT_ACK (ACK_OOS_COMPRESS) received 1489 PT_ACK(OK) = PT_ACK (ACK_OK) sent/received for final packet 1490 PT_ACK(ERR)= PT_ACK (any other IE_ACK_CODE) sent/received 1492 Idle Phase 1493 The MNCP necessarily begins and ends with this phase. When an 1494 application or session control request causes a PT_NTFN packet to be 1495 sent or received, the MNCP proceeds to the Negotiation phase. When an 1496 application or session control request causes a PT_CMD packet to be 1497 sent or received, the MNCP proceeds to the Data Transfer phase. 1499 The MNCP returns to the Idle phase automatically if: 1501 - the ack timeout expires while waiting for any packet (i.e., packet 1502 lost or silent discard of badly-formed packet) and all retries have 1503 been exhausted; 1505 - a PT_ACK packet with IE_ACK_CODE equal to ACK_OK is sent or received 1506 confirming the final packet in a packet sequence (i.e., confirming a 1507 PT_DATA packet that contained an IE_DATA_FINAL element); or 1509 - a PT_ACK packet with IE_ACK_CODE not equal to ACK_OK is sent, or a 1510 PT_ACK packet with IE_ACK_CODE not equal to ACK_OK or 1511 ACK_OSS_COMPRESS is received. 1513 Negotiation Phase 1514 The MNCP enters this phase when sending or receiving a PT_NTFN packet. 1516 The receiving MNCP processes the incoming packet and returns a 1517 positive or negative PT_ACK as follows. 1519 - If the PT_ACK is negative, the receiver returns to the Idle phase. 1521 - If the PT_ACK is positive, the receiver enters the Data Transfer 1522 phase. 1524 The sending MNCP awaits and processes the PT_ACK. 1526 - If the PT_ACK is positive, the sender enters the Data Transfer 1527 phase. 1529 - If the PT_ACK indicates ACK_OSS_COMPRESS, the sender SHOULD retry 1530 sending the PT_NTFN with a different compression method and remain 1531 in the Negotiation phase. 1533 - Otherwise, the sender returns to the Idle phase. 1535 Any locally-initiated application request received during this phase 1536 MUST NOT be processed by this MNCP instance until the Idle Phase is 1537 re-entered. Such requests MAY be rejected or buffered locally by the 1538 implementation. 1540 Data Transfer Phase 1541 The MNCP enters this phase when sending or receiving a PT_CMD or 1542 PT_DATA packet. 1544 The receiving MNCP processes the incoming packet and returns a 1545 positive or negative PT_ACK as follows. 1547 - If the PT_ACK is negative or confirms receipt of a packet containing 1548 an IE_DATA_FINAL element, the receiver returns to the Idle phase. 1550 - Otherwise (confirming PT_DATA packet with IE_DATA_MORE), the 1551 receiver remains in the Data Transfer phase. 1553 The sending MNCP awaits and processes the PT_ACK. 1555 - If PT_ACK is negative or the outgoing packet contained an 1556 IE_DATA_FINAL element, the sender returns to the Idle phase. 1558 - Otherwise (PT_ACK confirmed packet containing IE_DATA_MORE), the 1559 sender remains in the Data Transfer phase and sends the next PT_DATA 1560 packet. 1562 Any locally-initiated application request received during this phase 1563 MUST NOT be processed by this MNCP instance until the Idle Phase is 1564 re-entered. Such requests MAY be rejected or buffered locally by the 1565 implementation. 1567 5.2 State Diagram 1568 The MNCP reliable delivery finite-state automaton is defined by events, 1569 actions and state transitions. Events include reception of application 1570 requests, expiration of the Ack timer, and reception of packets from a 1571 peer. Actions include the starting of the timers and transmission of 1572 packets to the peer. 1574 Events Actions 1576 REQ = Receive Application Request scm = send PT_CMD 1577 RCM = Receive PT_CMD snt = send PT_NTFN 1578 RNT = Receive PT_NTFN fsc = fwd to Session Control 1579 RSP = Receive Session Response sak = send PT_ACK 1580 RAK = Receive PT_ACK sdt = send PT_DATA 1581 RDT = Receive PT_DATA sto = start timers 1582 TMO = Ack Timeout ind = send Appl Indication 1583 cnf = send Appl Confirm 1585 The complete state transition table follows. States are indicated 1586 horizontally, and events are read vertically. State transitions and 1587 actions are represented in the form action/new-state. Multiple actions 1588 are separated by commas, and may continue on succeeding lines as space 1589 requires; multiple actions may be implemented in any convenient order. 1590 The state may be followed by a letter, which indicates an explanatory 1591 footnote. The dash ('-') indicates an illegal transition. 1593 | State 1594 | 0 1 2 3 4 5 1595 Events| Listen Cmd-Sent Ntfn-Sent Data-Sent Await-Rsp Await-Data 1596 ------+------------------------------------------------------------- 1597 REQ | scm/1 or - - - - - 1598 | snt/2 1599 RCM | sak/0 or - - - - - 1600 | fsc/4 1601 RNT | sak/0 or - - - - - 1602 | fsc/4 1603 RSP | - - - - sak/0 or - 1604 | sak/5 or 1605 | ind,sak/0 1606 RAK | - cnf/0 cnf/0 or cnf/0 or - - 1607 | snt/2 sdt/3 1608 | sdt/3 1609 RDT | - - - - - sak/5 or 1610 | ind,sak/0 1611 TMO | - cnf/0 or cnf/0 or cnf/0 or - 0 1612 | scm/1 snt/2 sdt/3 1614 Timers are started (sto action) when sending any packet and stopped 1615 when receiving any packet. The sending MNCP runs an ACK_WAIT_TIMER; 1616 the receiving MNCP runs a DATA_WAIT_TIMER. See section 5.6 for 1617 additional detail. 1619 5.3 States 1620 Following is a more detailed description of each automaton state. 1622 Listen 1623 The MNCP automaton begins and ends in this state, awaiting either a 1624 locally-initiated application or session control request, or receipt 1625 of a PT_CMD or PT_NTFN packet. 1627 Command-Sent 1628 The MNCP automaton transitions to this state when sending a PT_CMD 1629 packet. Events expected to occur while in this state are expiration 1630 of the ACK_WAIT_TIMER or receipt of a PT_ACK packet. 1632 Notification-Sent 1633 The MNCP automaton transitions to this state when sending a PT_NTFN 1634 packet. Events expected to occur while in this state are expiration 1635 of the ACK_WAIT_TIMER or receipt of a PT_ACK packet. 1637 Await-Data 1638 The MNCP automaton transitions to this state when sending a positive 1639 PT_ACK packet in response to an incoming PT_NTFN packet. Events 1640 expected to occur while in this state are expiration of the 1641 DATA_WAIT_TIMER or receipt of a PT_ACK packet. 1643 Await-Session-Response 1644 The MNCP automaton transitions to this state when forwarding an 1645 incoming PT_CMD or PT_NTFN packet to MNCP session control. The only 1646 event expected to occur while in this state is a response from session 1647 control. 1649 Data-Sent 1650 The MNCP automaton transitions to this state when sending a PT_DATA 1651 packet. Events expected to occur while in this state are expiration 1652 of the ACK_WAIT_TIMER or receipt of a PT_ACK packet. 1654 5.4 Events 1655 Transitions and actions in the automaton are caused by events. 1657 Receive Application Request (REQ) 1658 This event occurs when a locally-initiated application or session 1659 control request is submitted to the MNCP for processing. If the data 1660 contained in the request is shorter than (DEFAULT_PACKET_SIZE - 1661 header) octets, uncompressed, the MNCP automaton sends a PT_CMD (scm 1662 action). Otherwise, it sends a PT_NTFN (snt action). 1664 Receive PT_CMD (RCM) 1665 This event occurs when a remotely-initiated PT_CMD packet is received 1666 by the MNCP as an incoming UDP datagram. If the packet is badly 1667 formed, contains an invalid version, a system error occurs, or 1668 resources are unavailable to further process the request, the MNCP 1669 automaton sends a PT_ACK (sak action) with a negative Ack Code. 1670 Otherwise, it forwards the PT_CMD packet to the MNCP session control 1671 automaton (fsc action). 1673 Receive PT_NTFN (RNT) 1674 This event occurs when a remotely-initiated PT_NTFN packet is received 1675 by the MNCP as an incoming UDP datagram. If the packet is badly 1676 formed, contains an invalid version, a system error occurs, resources 1677 are unavailable to further process the request, or the proposed 1678 compression method is not supported, the MNCP automaton sends a PT_ACK 1679 (sak action) with a negative Ack Code, and an alternative compression 1680 method (if applicable). Otherwise, it forwards the PT_NTFN packet to 1681 the MNCP session control automaton (fsc action). 1683 Receive Session Response (RSP) 1684 This event occurs when a response is returned from the local MNCP 1685 session control automaton, indicating the success or failure of 1686 authentication, registration, or deregistration. If the response is 1687 negative, the MNCP automaton sends a PT_ACK (sak action) with the 1688 negative Ack Code supplied by session control. If the response is 1689 positive, the MNCP automaton sends a PT_ACK (sak action) ACK_OK. If 1690 the incoming request was a PT_CMD packet, the MNCP automaton supplies 1691 any application-specific information elements (including data) to the 1692 destination application (ind action). 1694 Receive PT_ACK (RAK) 1695 This event occurs when a remotely-initiated PT_ACK packet is received 1696 by the MNCP as an incoming UDP datagram. If the Ack Code is 1697 ACK_OOS_COMPRESS, the MNCP automaton SHOULD resend the PT_NTFN with 1698 another compression method (snt action). If the Ack Code is any other 1699 negative value, the MNCP automaton notifies the requesting application 1700 of the failure (cnf action). If the Ack Code is ACK_OK and confirms a 1701 PT_NTFN or PT_DATA(more) packet, the MNCP automaton sends a PT_DATA 1702 packet (sdt action). Otherwise (the Ack Code is ACK_OK and confirms 1703 the final packet in a sequence), the MNCP automaton notifies the 1704 requesting application that its request was delivered successfully 1705 (cnf action). 1707 Receive PT_DATA (RDT) 1708 This event occurs when a remotely-initiated PT_DATA packet is received 1709 by the MNCP as an incoming UDP datagram. The MNCP automaton uses the 1710 packet contents to reassemble and decompress application data (see 1711 Sections 5.6 through 5.8) and send a PT_ACK (sak action). If incoming 1712 packet contained an IE_DATA_FINAL element, the MNCP automaton supplies 1713 all application-specific information elements received during the 1714 packet sequence, including the reassembled/decompressed application 1715 data, to the destination application (ind action). 1717 Ack Timeout (TMO) 1718 This event occurs when the ACK_WAIT_TIMER or DATA_WAIT_TIMER started 1719 by this MNCP automaton expires. The automaton applies its 1720 retransmission algorithm (see Section 5.6) to determine the 1721 appropriate action: resending a PT_CMD packet (scm action), PT_NTFN 1722 packet (snt action), PT_DATA packet (sdt action), or PT_ACK packet 1723 (sak action), or abandoning the packet sequence. When abandoning the 1724 packet sequence, if this MNCP was the sequence initiator, it also 1725 notifies the requesting application of the failure (cnf action). 1727 5.5 Actions 1728 Actions in the automaton are caused by events and typically indicate 1729 the transmission of packets and/or the starting or stopping of the 1730 timers. 1732 send PT_CMD (scm) 1733 The MNCP automaton sends a PT_CMD packet as a result of a locally- 1734 initiated application or session control request, or as a retry 1735 (ACK_WAIT_TIMER expired with retry remaining). 1737 The MNCP builds a PT_CMD packet as follows. 1738 - Protocol Version is set to the value for this implementation. 1739 - Packet Type is set to PT_CMD. 1740 - Correlation Identifier is assigned by the MNCP (new request) or set 1741 to the previously-assigned value (retry). 1742 - Sequence Number is set to zero(0). 1743 - Session Control fields supplied in the request (Service ID, Function 1744 ID, Subscriber ID, Subscriber Password) are appended. 1745 - Any application-specific IEs supplied in the request are appended. 1746 - Any application-specific data supplied in the request is 1747 encapsulated in a Data(Final) information element. 1749 The PT_CMD packet is sent as a UDP packet to the "well-known" MNCP 1750 port, the PKT_RETRY count is incremented, and the ACK_WAIT_TIMER is 1751 started (see Section 5.6). The MNCP automaton then transitions to the 1752 Command-Sent state. 1754 send PT_NTFN (snt) 1755 The MNCP automaton sends a PT_NTFN packet as a result of a locally- 1756 initiated application or session control request, or as a retry 1757 (ACK_WAIT_TIMER expired with retry remaining or PT_ACK 1758 ACK_OOS_COMPRESS received and alternative method available). 1760 The MNCP builds a PT_NTFN packet as follows. 1761 - Protocol Version is set to the value for this implementation. 1762 - Packet Type is set to PT_NTFN. 1763 - Correlation Identifier is assigned by the MNCP (new request) or set 1764 to the previously-assigned value (retry). 1765 - Sequence Number is set to zero(0). 1766 - Data Compression Method is chosen by the MNCP, influenced by values 1767 returned in earlier PT_ACKs (if any); see Section 5.8. If the 1768 default value (COMPRESS_OFF) is selected, this field SHOULD be 1769 omitted. 1770 - Uncompressed Message Length is set to the number of octets of 1771 application-specific data supplied in the request. 1772 - Compressed Message Length is set to the number of octets yielded 1773 when compressing this data using the proposed Compression Method. 1774 - As an implementation option, Packet Size may be set to a value 1775 larger than DEFAULT_PACKET_SIZE; see Section 5.7. If the default 1776 value is desired, this field SHOULD be omitted. 1777 - Session Control fields supplied in the request (Service ID, Function 1778 ID, Subscriber ID, Subscriber Password) are appended. 1779 - Any application-specific IEs supplied in the request are appended. 1781 The PT_NTFN packet is sent as a UDP packet to the "well-known" MNCP 1782 port, the PKT_RETRY count is incremented, and the ACK_WAIT_TIMER is 1783 started (see Section 5.6). The MNCP automaton then transitions to the 1784 Notification-Sent state. 1786 fwd to Session Control (fsc) 1787 The MNCP automaton forwards incoming PT_CMD and PT_NTFN packets to 1788 MNCP session control for registration, deregistration, and 1789 authentication. The MNCP automaton then transitions to the Await- 1790 Session-Response state. 1792 send PT_ACK (sak) 1793 The MNCP automaton sends a PT_ACK packet in response to an incoming 1794 packet. 1796 The MNCP builds a PT_ACK packet as follows. 1797 - Protocol Version is set to the value for this implementation. 1798 - Packet Type is set to PT_ACK. 1799 - Correlation Identifier and Sequence Number are both set to the 1800 corresponding values in the packet being acknowledged. 1801 - Ack Code is chosen by the MNCP to reflect the result of processing. 1803 When acknowledging a PT_NTFN only, the following fields MAY also be 1804 included in the PT_ACK packet. 1805 - If the Ack Code is ACK_OOS_COMPRESS, an alternative Data Compression 1806 Method MUST be chosen by the MNCP; see Section 5.8. Otherwise, this 1807 field MUST be omitted. 1808 - As an implementation option, PACKET_SIZE MAY be set to a value 1809 larger than DEFAULT_PACKET_SIZE and less than the proposed size, see 1810 Section 5.7. If the default value is desired, this field SHOULD be 1811 omitted. 1813 The PT_ACK packet is sent as a UDP packet to the source port which 1814 sent the packet being acknowledged. When positively acknowledging a 1815 PT_NTFN or PT_DATA(more) packet, the MNCP automaton then transitions 1816 to the Await-Data state and the DATA_WAIT_TIMER is started (see 1817 section 5.6). Otherwise, the MNCP automaton transitions to the Listen 1818 state, forwards incoming data to the receiving application (ind 1819 action), and the packet sequence is concluded. 1821 send PT_DATA (sdt) 1822 The MNCP automaton sends a PT_DATA packet when it receives a positive 1823 PT_ACK to a PT_NTFN or PT_DATA(more) packet, or as a retry 1824 (ACK_WAIT_TIMER expired with retry remaining). 1826 The MNCP builds a PT_DATA packet as follows. 1827 - Protocol Version is set to the value for this implementation. 1828 - Packet Type is set to PT_DATA. 1829 - Correlation Identifier is set to the value used in the PT_NTFN 1830 packet that started this packet sequence. 1831 - Sequence Number is set to the value used in the preceding packet 1832 (retry) or that value incremented by one (otherwise). 1833 - Data Offset is set to the starting octet position of the 1834 application-specific data to be included in this packet. 1835 - Compressed and segmented application data (see Sections 5.7 and 5.8) 1836 is encapsulated in IE_DATA_MORE or IE_DATA_FINAL information 1837 elements. When building an IE_DATA_MORE element, the MNCP MUST fill 1838 the remainder of the PT_DATA packet with compressed data. When 1839 building an IE_DATA_FINAL element, the MNCP MUST NOT pad the data. 1841 The PT_DATA packet is sent as a UDP packet to the source port which 1842 sent the last PT_ACK packet, the PKT_RETRY count is incremented, and 1843 the ACK_WAIT_TIMER is started (see Section 5.6). The MNCP automaton 1844 then transitions to the Data-Sent state. 1846 start ACK_WAIT_TIMER or DATA_WAIT_TIMER (sto) 1847 The MNCP automaton starts the ACK_WAIT_TIMER or DATA_WAIT_TIMER 1848 whenever it sends a non ACK packet, as described in Section 5.6. 1850 send Appl Indication (ind) 1851 The MNCP automaton supplies incoming session control information 1852 elements, application-specific information elements, and 1853 reassembled/decompressed data (if any) to the destination application 1854 just before sending a PT_ACK to an incoming PT_CMD or PT_DATA(final) 1855 packet as described under the sak action above. 1857 send Appl Confirm (cnf) 1858 The MNCP automaton supplies a delivery confirmation to the requesting 1859 application when it receives the final PT_ACK in a packet sequence or 1860 abandons the request. Negative confirmations include the reason why 1861 the request could not be delivered (e.g., the Ack Code value or 1862 timeout). The MNCP automaton then transitions to the Listen state and 1863 the packet sequence is concluded. 1865 5.6 Timers, Acknowledgment, and Retransmission 1866 To help ensure a reliable delivery of data between a MCD and the 1867 Mobility Server, MNCP uses a stop-and-go with timeout retransmission 1868 mechanism. 1870 Each MNCP reliable delivery packet carries a 16-bit unsigned sequence 1871 number and MUST be individually acknowledged by the receiving MNCP. 1872 The sequence number MUST start at 0 for the first packet of each packet 1873 sequence and be incremented by one for each additional packet in the 1874 flow till 65,535 and then recycled through 0 if necessary. An 1875 acknowledgment packet MUST use the same sequence number as the packet 1876 it is acknowledging. 1878 Out of sequence data packet MUST be discarded by the receiving MNCP. 1879 As part of the action associated with the processing a PT_DATA packet 1880 that arrives out of sequence, the MNCP MUST return a PT_ACK packet 1881 containing the Sequence Number of the most recently acknowledged 1882 PT_DATA packet. 1884 When sending a packet, the sending MNCP MUST start a retransmission 1885 timer (ACK_WAIT_TIMEOUT, default 15 seconds), during which the sending 1886 MNCP will wait for an acknowledgment from the receiving MNCP. When 1887 sending a PT_ACK to any packet other than PT_DATA (final), the 1888 receiving MNCP MUST start a DATA_WAIT_TIMER (typically, three times the 1889 ACK_WAIT_TIMER value). Expiration of this timer causes the transfer of 1890 the packet sequence to be abandoned. 1892 If the sending MNCP does not receive an acknowledgment from the 1893 receiving MNCP within the timeout period, which has the same sequence 1894 number as the packet been sent, it should retransmit the packet up to 1895 PKT_RETRY times (default 2 retries per packet). If there is still no 1896 acknowledgment after all the retries (i.e., for an attempt of PKT_RETRY 1897 + 1 times), the sending MNCP should abort the packet sequence. 1899 Implementation Note: In the current implementations, timers are 1900 assigned predetermined values appropriate for the wireless environment 1901 over which the MNCP operates, from a configuration file. 1902 ACK_WAIT_TIMEOUT is the same for all Service ID/Function ID 1903 combinations. 1905 5.7 Packet Size Negotiation, Segmentation and Reassembly 1906 A sending MNCP may propose a packet size larger than the 1907 DEFAULT_PACKET_SIZE in a NOTIFICATION REQUEST. Any value greater than 1908 DEFAULT_PACKET_SIZE but less than or equal to the maximum packet size 1909 of 2048 octets may be proposed by encoding the desired size in the 1910 IE_PKT_SIZE information element in the PT_NTFN. A receiving MNCP may 1911 accept the proposed packet size, or it may proposed a reduced packet 1912 size. The receiving MNCP specifies the acceptable packet size 1913 (proposed or reduced) in the IE_PKT_SIZE information element when 1914 composing a PT_ACK packet in response to a PT_NTFN packet. In the 1915 absence of an explicit IE_PKT_SIZE field, the DEFAULT_PACKET_SIZE MUST 1916 be assumed. 1918 5.7.1 Computing the payload size for PT_DATA packets 1919 The sending MNCP subtracts the MNCP common header length (7), the 1920 length of IE_DATA_OFFSET information element (6) and the length of the 1921 IE Length and IE Type components of the IE_DATA_MORE information 1922 element (3) from the value of IE_PKT_SIZE and uses this as the 1923 PAYLOAD_SIZE. 1925 5.7.2 Segmentation and PT_DATA Packet Composition 1926 The sending MNCP segments application data into "n" PT_DATA packets. 1927 All but the final PT_DATA packet contain one IE_DATA_MORE information 1928 element that conveys PAYLOAD_SIZE octets, and a monotonically 1929 incremented sequence number, and a data offset. 1931 Data compression, if selected, is performed on the application data 1932 prior to segmentation. This is required to determine the value of 1933 Compressed Message Length used in the PT_NTFN (see section 3.5.2). 1935 Initially, a local parameter, next-data-offset, is set to zero (0), and 1936 the next-sequence-number is set equal to the value of Sequence Number 1937 sent in the PT_NTFN (zero, 0). 1939 If no compression is used, then PAYLOAD_SIZE number of octets of 1940 uncompressed data are encoded in the Data field of the IE_DATA_MORE 1941 information element. The value of next-data-offset is encoded in the 1942 IE_DATA_OFFSET field, and next-data-offset is incremented by 1943 PAYLOAD_SIZE. If compression is used, then PAYLOAD_SIZE number of 1944 octets of compressed data are encoded in the Data field of the 1945 IE_DATA_MORE information element, the value of next-data-offset is 1946 encoded in the IE_DATA_OFFSET field, and next-data-offset is set to the 1947 octet location of the final octet of data that were encoded in the Data 1948 field. The Sequence number encoded in the common packet header is set 1949 to next-sequence number, and next-sequence-number is increased by one 1950 (1). 1952 The PT_DATA packet is then sent as an individual transmission in a UDP 1953 packet, and a timer is initiated. If a PT_ACK is not received before 1954 the retransmission timer expires, the PT_DATA packet is retransmitted. 1955 Retransmission upon timer expiration is repeated until a maximum number 1956 of retries (PKT_RETRY +1) is exhausted, at which time the sending MNCP 1957 notifies session control of a communications failure. 1959 Upon reception of an PT_ACK, another PT_DATA packet may be sent. If no 1960 compression is used and the value of IE_DATA_OFFSET subtracted from 1961 Original Message length is greater than PAYLOAD_SIZE, the process of 1962 composing and sending a PT_DATA packet containing an IE_DATA_MORE 1963 information element is repeated. Similarly, a PT_DATA packet 1964 containing an IE_DATA_MORE information element is composed if 1965 compression is used and more than PAYLOAD_SIZE number of compressed 1966 octets remain to be sent. Otherwise, a final PT_DATA packet is 1967 generated. 1969 The final PT_DATA packet contains an IE_DATA_FINAL information element, 1970 and conveys up to PAYLOAD_SIZE octets, compressed or uncompressed. The 1971 value of the IE_DATA_FINAL information element must not be padded. 1973 5.7.3 Reassembly 1974 The receiving MNCP processes incoming PT_DATA packets as follows. 1975 Following transmission of a positive (PT_ACK) acknowledgment to a 1976 PT_NTFN packet, the receiving MNCP sets a local parameter for next- 1977 expected-sequence-number to one (1), and awaits the arrival of a 1978 PT_DATA packet containing the same Correlation ID as encoded in the 1979 PT_NTFN packet that initiated this packet sequence and a Sequence 1980 Number equal to the parameter next-expected-sequence-number, and an 1981 IE_DATA_MORE or IE_DATA_FINAL information element. 1983 The receiving MNCP composes and returns a PT_ACK with Sequence Number 1984 set to the value of Sequence Number from the PT_DATA packet being 1985 acknowledged, then increments next-expected-sequence-number by one (1), 1986 and awaits the arrival of the next packet in the sequence. If the 1987 sequence number in the next PT_DATA packet that arrives does not equal 1988 next-expected-sequence-number, the receiving MNCP composes and returns 1989 a PT_ACK packet with the sequence number of the last acknowledged 1990 PT_DATA packet (next-expected-sequence-number minus 1) and immediately 1991 discards the PT_DATA packet. Otherwise, the receiving MNCP processes 1992 each arriving PT_DATA packet containing an IE_DATA_MORE information 1993 element in exactly the same manner as the initial PT_DATA packet. The 1994 process repeats until a PT_DATA packet containing an IE_DATA_FINAL 1995 information element is received. The receiving MNCP composes and 1996 returns a PT_ACK as previously described. 1998 If compression is used, the user data extracted from the IE_DATA_MORE 1999 and IE_DATA_FINAL information elements received by the MNCP are 2000 reassembled and then uncompressed. Reassembly uses the values of 2001 IE_DATA_OFFSET and PAYLOAD_SIZE to compose the original message from 2002 the message segments delivered, then the message in its entirety is 2003 passed to the application. 2005 Receive buffer strategies are implementation-dependent; for example, if 2006 compression is used during a transfer, the value of Compressed Message 2007 Length from the IE_MSG_LENGTH information element in the PT_NTFN may be 2008 used to allocate a buffer sufficient for the reassembly of the 2009 compressed data packet sequence, otherwise the value of Original 2010 Message Length may be used. [Note: This memo imposes no restrictions 2011 on how receive buffers are allocated in implementations.] 2013 5.8 Data Compression 2014 When issuing a PT_NTFN packet, the sending MNCP uses the 2015 IE_DATA_COMPRESSION field to indicate the compression method that it 2016 wishes to apply to the application data that will follow in PT_DATA 2017 packets. The IE_MSG_LENGTH Compressed Message Length field is computed 2018 by assuming this compression method. The receiving MNCP responds to 2019 this bid in the PT_ACK packet that confirms the PT_NTFN, as follows. 2021 To accept the proposed compression method, the responding MNCP MUST 2022 return a PT_ACK packet with IE_DATA_COMPRESSION absent and IE_ACK_CODE 2023 equal to ACK_OK. 2025 To reject the proposed compression method, the responding MNCP MUST 2026 return a PT_ACK packet with IE_DATA_COMPRESSION set to indicate an 2027 alternative compression method (which may be NONE) and an IE_ACK_CODE 2028 equal to ACK_OOS_COMPRESS. 2030 If the sender's proposed compression method was rejected, the sending 2031 MNCP SHOULD issue another PT_NTFN packet with an alternative 2032 compression method, repeating the above negotiation until a mutually 2033 acceptable method is agreed upon (signaled by a PT_ACK with IE_ACK_CODE 2034 equal to ACK_OK and IE_DATA_COMPRESSION absent). Note that the 2035 IE_MSG_LENGTH Compressed Message Length field is recomputed by assuming 2036 the compression method, which can either be the alternative method 2037 proposed by the receiver, or a new method proposed by the sender. If 2038 no compression method is specified, the Compressed Message Length field 2039 value MUST be the same as the value of Original Message Length. 2041 Once a compression method has been agreed, the sending MNCP applies the 2042 negotiated method to compress the data content of PT_DATA packet 2043 IE_DATA_MORE and IE_DATA_FINAL elements sent in this MNCP packet 2044 sequence. The receiving MNCP applies the same negotiated method to 2045 decompress the data content upon arrival, ultimately yielding the 2046 number of octets indicated by the IE_MSG_LENGTH Original Message Length 2047 field. 2049 6. MNCP Session Control Processing 2050 The phase diagram and state machine described in this section operates 2051 on unique Subscriber ID/Service ID pairs. When responding to any 2052 event, the session control automaton must first determine the current 2053 state associated with the Subscriber ID/Service ID pair, and then 2054 follow the course of action specified for that state. 2056 6.1 Phase Diagram 2057 Session control goes through two distinct phases which are specified 2058 in the following simplified diagram. 2060 +------+ +------------+ DEREG(FAILED) 2061 | |REG(ACK_OK)| | and APPL REQs 2062 | Idle |---------->| Registered |---------+ 2063 | | | |<--------+ 2064 +------+ +------------+ 2065 ^ | 2066 | DEREG(SUCCESS)OR LOS | 2067 <-----------------------+ 2069 REG(ACK_OK) = Send or receive Ack Code ACK_OK to FUN_REG_REQ 2070 or FUN_ 2071 DEREG(SUCCESS)= Send/receive positive Ack accepting FUN_DEREG_REQ 2072 PT_ACK from MCD to MS containing ACK_OOS_SVC 2073 PT_ACK from MS to MCD containing ACK_OK 2074 DEREG(FAILED) = Send/receive negative Ack rejecting FUN_DEREG_REQ 2075 PT_ACK from MCD to MS containing ACK_OK 2076 PT_ACK from MS to MCD containing any other value 2077 APPL REQs = Send or receive FUN_ app-specific request 2078 LOS = Loss of signal assumed when DEREG_REQ abandoned 2080 Idle Phase 2081 MNCP session control necessarily begins and ends with this phase. 2082 When a positive acknowledgment (Ack Code ACK_OK) is returned to a 2083 Registration Request (FUN_REG_REQ or FUN_ in the case of an 2084 implicit registration performed by the MS), session control 2085 transitions to the Registered phase. 2087 MNCP session control returns to the Idle phase automatically after 2088 receiving or sending a successful Deregistration Request, and after 2089 timeout of a Deregistration Request, as signaled by the MNCP reliable 2090 delivery automaton. 2092 Registered Phase 2093 MCD MNCP session control enters this phase when receiving a positive 2094 Registration Request acknowledgment. MS MNCP session control enters 2095 this phase when it has received and processed a valid Registration 2096 request from an MCD and has responded to the request with a positive 2097 acknowledgment. MS MNCP session control also enters this phase when 2098 it has received and processed a valid service request from an MCD that 2099 has not previously (explicitly) registered with the service and has 2100 responded to the request with a positive acknowledgment. 2102 In this phase, MNCP session control processes incoming Deregistration 2103 Requests and any other Application Request. All requests are 2104 authenticated, and service access control is verified. Application 2105 Requests are forwarded to the destination application service only if 2106 the subscriber is currently registered for that service. 2108 The Mobility Server runs an INACTIVITY_TIMER to reaffirm the 2109 registration status on a periodic basis. 2111 MCD MNCP session control remains in the Registered phase until it 2112 completes a successful Deregistration Request. MS MNCP session 2113 control remains in the Registered phase until it either completes a 2114 successful Deregistration, or a Deregistration Request is abandoned 2115 due to timeout. When Deregistration is completed, the MNCP returns to 2116 the Idle phase. 2118 6.2 State Diagram 2119 The session control finite-state automaton is defined by events, 2120 actions and state transitions. Events include reception of application 2121 requests and expiration of the Inactivity timer. Actions include the 2122 starting of the INACTIVITY_TIMER and transmission of requests and 2123 responses. 2125 Events Actions 2127 ORR = Outgoing Registration Request srr = send FUN_REG_REQ 2128 ODR = Outgoing Deregistration Request sdr = send FUN_DEREG_REQ 2129 OAR = Outgoing Application Request sar = send FUN_ 2130 IRR = Incoming FUN_REG_REQ au = authenticate subscriber 2131 IDR = Incoming FUN_DEREG_REQ up = update registr. status 2132 IAR = Incoming FUN_ spk = send Positive Ack 2133 IAK = Incoming Ack snk = send Negative Ack 2134 TMO = Inactivity Timeout it = start INACTIVITY_TIMER 2136 The complete state transition table follows. States are indicated 2137 horizontally, and events are read vertically. State transitions and 2138 actions are represented in the form action/new-state. Multiple actions 2139 are separated by commas, and may continue on succeeding lines as space 2140 requires; multiple actions may be implemented in any convenient order. 2141 The state may be followed by a letter, which indicates an explanatory 2142 footnote. The dash ('-') indicates an illegal transition. 2144 | State 2145 | 0 1 2 3 4 2146 Events| Listen Reg-Sent Dereg-Sent App-Sent Registered 2147 ------+----------------------------------------------------- 2148 ORR | srr/1 - - - - 2149 ODR | - - - - up,sdr/2 2150 OAR | - - - - sar/3 2151 IRR | au,snk/0 or - - - - 2152 | au,up,it,spk/4 2153 IDR | - snk/1 snk/2 snk/3 au,snk/4 or 2154 | au,up,spk/0 2155 IAR | - - - - au,it,up,spk/4 or 2156 | au,it,spk/4 or 2157 | au,it,snk/4 2158 IAK | - up/4 or up,it/4 or 4 - 2159 | 0 0 2160 TMO | - - - - up,sdr/2 2162 The INACTIVITY_TIMER runs only at the Mobility Server. 2164 6.3 States 2165 Following is a more detailed description of each automaton state. 2167 Listen 2168 The session control automaton begins and ends in this state, awaiting 2169 either a locally-initiated (outgoing) Registration Request, or receipt 2170 of an incoming FUN_REG_REQ indication from MNCP reliable delivery. 2172 Registration-Request-Sent 2173 The session control automaton transitions to this state when sending a 2174 FUN_REG_REQ. The events expected to occur while in this state are 2175 receipt of an Ack Code from MNCP reliable transfer, indicating the 2176 result of the request or timeout, or receipt of a Deregister request 2177 form the MS. 2179 Deregistration-Request-Sent 2180 The session control automaton transitions to this state when sending a 2181 FUN_DEREG_REQ. Events expected to occur while in this state are 2182 receipt of an Ack Code from MNCP reliable transfer or receipt of an 2183 incoming FUN_DEREG_REQ. 2185 Application-Request-Sent 2186 The session control automaton transitions to this state when sending a 2187 FUN_REG_REQ. Events expected to occur while in this state are receipt 2188 of an Ack Code from MNCP reliable transfer or receipt of an incoming 2189 FUN_DEREG_REQ, or receipt of a Deregister request form the MS. 2191 Registered 2192 The session control automaton transitions to this state when returning 2193 a positive Ack for an incoming FUN_REG_REQ (explicit registration), 2194 returning a positive Ack for an incoming FUN_ (implicit 2195 request), receiving a positive Ack for an outgoing FUN_REG_REQ, 2196 receiving a positive Ack for an outgoing FUN_, or receiving a 2197 negative Ack for an outgoing FUN_DEREG_REQ. Events expected to occur 2198 while in this state are outgoing Deregistration or Application 2199 Requests, incoming FUN_DEREG_REQ or FUN_ packets, or expiration 2200 of the INACTIVITY_TIMER. 2202 6.4 Events 2203 Transitions and actions in the automaton are caused by events. 2205 Outgoing Registration Request (ORR) 2206 This event occurs when a Registration Request is initiated by the MCD, 2207 causing the session control automaton to send a FUN_REG_REQ (srr 2208 action). This event MAY also be initiated implicitly by the MCD 2209 session control implementation (e.g., when the first Application- 2210 specific Request for a give service is initiated). 2212 Outgoing Deregistration Request (ODR) 2213 This event occurs when a Deregistration Request is initiated by the 2214 MCD, causing the session control automaton to send a FUN_DEREG_REQ 2215 (sdr action). This event MAY also be initiated by the MS session 2216 control implementation (as a consequence of the expiry of the 2217 INACTIVITY_TIMER). 2219 Outgoing Application Request (OAR) 2220 This event occurs when an Application Request is initiated by the MCD, 2221 causing the session control automaton to send a FUN_ (sar 2222 action). 2224 Incoming FUN_REG_REQ (IRR) 2225 This event occurs when a remotely-initiated FUN_REG_REQ is received by 2226 the Mobility Server. The session control automaton attempts to 2227 authenticate the subscriber and verify the subscriber is permitted 2228 access to the service indicated in the request (au action) and returns 2229 the result to MNCP reliable delivery as an Ack Code (snk or spk 2230 action). When authentication is successful, the automaton also 2231 updates the subscriber's registration status (up action) and starts 2232 the INACTIVITY_TIMER (it action). 2234 Incoming FUN_DEREG_REQ (IDR) 2235 This event occurs when a remotely-initiated FUN_DEREG_REQ is received 2236 by either the MCD or Mobility Server. The session control automaton 2237 attempts to authenticate the subscriber (au action) and returns the 2238 result to MNCP reliable delivery as an Ack Code (snk or spk action). 2239 When authentication is successful, the automaton also updates the 2240 subscriber's registration status (up action). 2242 Incoming FUN_ (IAR) 2243 This event occurs when any other remotely-initiated request 2244 (FUN_) is received by either the Mobility Server. The session 2245 control automaton attempts to authenticate the subscriber and verify 2246 the subscriber is permitted access to the service indicated in the 2247 request (au action), and returns the result to MNCP reliable delivery 2248 as an Ack Code (snk or spk action). 2250 Incoming Acknowledgment (IAK) 2251 This event occurs when a response is received from MNCP reliable 2252 delivery, indicating success or failure of an earlier request as an 2253 Ack Code. When receiving a Registration or Deregistration Request 2254 acknowledgment, the automaton updates the subscriber's registration 2255 status (up action). When the Mobility Server receives an ACK_OK in a 2256 Deregistration Request acknowledgment, indicating the subscriber 2257 should be (re)registered for the service, the MS (re)starts the 2258 INACTIVITY_TIMER (it action). 2260 Inactivity Timeout (TMO) 2261 This event occurs when the INACTIVITY_TIMER started by the Mobility 2262 Server's session control automaton expires. Subsequent processing 2263 assumes that the MCD has become unavailable since last contact (e.g., 2264 out of range, turned off, disabled). The automaton updates the 2265 subscriber's registration status (up action) and sends a FUN_DEREG_REQ 2266 (sdr action). 2268 6.5 Actions 2269 Actions in the automaton are caused by events and typically indicate 2270 the transmission of packets and/or the (re)starting of the Inactivity 2271 timer. 2273 send FUN_REG_REQ (srr) 2274 The MCD sends a FUN_REG_REQ packet as a result of a locally-initiated 2275 Registration Request involving a Subscriber/Service combination that 2276 is not currently registered (i.e., the automaton is in the Listen 2277 state). Session Control fields (Service ID, Function ID, Subscriber 2278 ID, Subscriber Password) are supplied to the MNCP reliable delivery 2279 automaton for inclusion in a PT_CMD packet. Function ID is set to 2280 FUN_REG_REQ; all other values are obtained from the MCD 2281 subscriber/application. The session control automaton then 2282 transitions to the Registration-Request-Sent state. 2284 send FUN_DEREG_REQ (sdr) 2285 The MCD sends a FUN_DEREG_REQ packet as a result of a locally- 2286 initiated Deregistration Request (implicit or explicit) involving a 2287 Subscriber/Service combination that is currently registered (i.e., the 2288 automaton is in the Registered state). The Mobility Server also sends 2289 a FUN_DEREG_REQ packet when the INACTIVITY_TIMER expires. Session 2290 Control fields (Service ID, Function ID, Subscriber ID, Subscriber 2291 Password) are supplied to the MNCP reliable delivery automaton for 2292 inclusion in a PT_CMD packet. Function ID is set to FUN_DEREG_REQ; 2293 all other values are obtained from the subscriber/application or the 2294 registration status table. The session control automaton marks the 2295 subscriber as deregistered for this service (up action) and then 2296 transitions to the Deregistration-Request-Sent state. 2298 send FUN_ (sar) 2299 Either the Mobility Server or the MCD sends a FUN_ packet as a 2300 result of a locally-initiated Application Request involving a 2301 Subscriber/Service combination that is currently registered (i.e., the 2302 automaton is in the Registered state), or the MCD sends a FUN_ 2303 packet as a result of a locally-initiated Application Request 2304 involving a Subscriber/Service combination that has not been 2305 explicitly registered (i.e., the MS is expected to implicitly register 2306 the application at the MCD). Session Control fields provided by the 2307 application (Service ID, Function ID, Subscriber ID, Subscriber 2308 Password) are supplied to the MNCP reliable delivery automaton for 2309 inclusion in a PT_CMD or PT_NTFN packet. The session control 2310 automaton then transitions to the Application-Request-Sent state. 2312 An Application Request initiated when the automaton is in the Listen 2313 state MAY cause the MCD to attempt implicit registration before the 2314 request is further processed. Otherwise, such a request MUST be 2315 rejected using the Ack Code value ACK_OOS_SVC and the automaton 2316 remains in the Listen state. 2318 authenticate subscriber (au) 2319 The automaton attempts to authenticate the Subscriber ID and Password 2320 and verifies the subscriber's current registration status and 2321 permission to access the specified Service ID and Function ID. 2323 - If Subscriber ID is not found, return the Ack Code ACK_ERR_SID. 2324 - Else if the Subscriber Password is invalid, return the Ack Code 2325 ACK_ERR_PWD. 2326 - Else if the Subscriber does not have permission to access this 2327 Service and Function, return the Ack Code ACK_OOS_SID. 2328 - Else if the Service is not currently available (e.g., the 2329 application process bound to this Service ID is not running), return 2330 ACK_OOS_SVC. 2331 - Else return ACK_OK. 2333 The method by which the MNCP determines whether a local application 2334 service is running is not specified by this memo. Refer to Section 7 2335 for additional discussion of Security. Refer to the spk and snk 2336 actions for Ack Code processing. 2338 update Registration Status (up) 2339 The automaton updates the subscriber's current registration status for 2340 each specified service as follows. 2342 When the MNCP: Status is set to: 2343 --------------------------------------- ----------------- 2344 Sends positive FUN_REG_REQ Ack Code Registered 2345 Receives positive FUN_REG_REQ Ack Code Registered 2346 Receives positive FUN_ Ack Code Registered (implicit) 2347 Sends FUN_DEREG_REQ Deregistered (implicit) 2348 Sends positive FUN_DEREG_REQ Ack Code Deregistered 2349 (MCD sends ACK_OOS_SVC, MS sends ACK_OK) 2350 Receives positive FUN_DEREG_REQ Ack Code Deregistered 2351 (MCD rcvs ACK_OK, MS rcvs ACK_OOS_SVC) 2352 Sends negative FUN_DEREG_REQ Ack Code (Still)Registered 2353 (MCD sends ACK_OK, MS sends ACK_other) 2354 Receives negative FUN_DEREG_REQ Ack Code (Re)Registered 2355 (MCD rcvs ACK_other, MS rcvs ACK_OK) 2357 Storage methods and internal representation of subscriber information 2358 and registration status are not specified by this memo. 2360 send Positive Ack Code (spk) 2361 Successful authentication of any incoming request forwarded to session 2362 control is indicated by returning a positive ACK code to the MNCP 2363 reliable delivery automaton for inclusion in a PT_ACK packet. A 2364 positive Ack Code is ACK_OK in all cases except when an MCD responds 2365 to a FUN_DEREG_REQ; in this case, it is ACK_OOS_SVC. The session 2366 control automaton changes state when acknowledging initial Application 2367 Requests (FUN_ packets) that cause implicit registration. The 2368 automaton transitions to the logical next state: Registered after a 2369 FUN_REG_REQ, FUN_, or Listen after a FUN_DEREG_REQ. 2371 send Negative Ack Code (snk) 2372 Failed authentication of any incoming request forwarded to session 2373 control is indicated by returning a negative ACK code to the MNCP 2374 reliable delivery automaton for inclusion in a PT_ACK packet. A 2375 negative ACK code is one of {ACK_ERR_SID, ACK_ERR_PWD, ACK_OOS_SID, or 2376 ACK_OOS_SVC}, except in the case where an MCD rejects a FUN_DEREG_REQ, 2377 in which case the ACK code is ACK_OK. The session control automaton 2378 does not change state when acknowledging Application Requests 2379 (FUN_ packets) or failed Registration Requests, but transitions 2380 back to the Registered state after a failed Deregistration Request 2381 (i.e., MS requests deregistration after inactivity time expires, but 2382 MCD indicates the application is still active). 2384 start INACTIVITY_TIMER (it) 2385 The Mobility Server's session control automaton (re)starts an 2386 INACTIVITY_TIMER whenever it receives a FUN_REG_REQ, FUN_, or 2387 failed FUN_DEREG_REQ Ack from the MCD. This timer allows the Mobility 2388 Server to refresh the registration status associated with an MCD on a 2389 periodic basis in the absence of other traffic. This timer does not 2390 apply to the MCD's session control automaton. 2392 7. Security Considerations 2393 The only form of security provided in this protocol is a validation 2394 (weak authentication) scheme based on clear text subscriber 2395 identification and password, so it is vulnerable to several known forms 2396 of attacks on clear text, against which only limited defenses can be 2397 taken (password aging/expiration, use of one-time long, system- 2398 generated passwords, etc.). Only subscriber validation is performed 2399 (the subscriber has no mechanism to determine the authenticity of a 2400 mobility server). 2402 [NOTE: A means of negotiating or selecting a strong authentication 2403 method and (additionally, optionally) a method for providing data 2404 integrity and confidentiality at the session control level of MNCP is 2405 under investigation.] 2407 Since MNCP operates over UDP/IP, it may be appropriate to make use of 2408 security services offered by other layers. For example, an IP 2409 Authentication Header can be used to provide integrity and 2410 authentication without confidentiality to IP datagrams [6], whereas an 2411 IP Encapsulating Security Payload (ESP) can be used to provide 2412 integrity, authentication, and confidentiality to IP datagrams (see 2413 also [7]). 2415 For other applications, it may be appropriate to adopt/adapt 2416 application-specific security services. For example, Mobile Messaging 2417 application, having already adapted POP3 [8] and SMTP [9], could also 2418 adapt PGP [10] to provide non-repudiation of sender and data privacy 2419 through encryption. 2421 8. References 2423 [1]Postel, J., "User Datagram Protocol," RFC 768, USC/Information 2424 Sciences Institute, 28 August 2880. 2426 [2] Reynolds, S. and Postel, J., "ASSIGNED NUMBERS", RFC 1700, 20 2427 October 1994. 2429 [3] Friend, R. and Simpson, W., "PPP Stac LZS Compression Protocol", RFC 2430 1974, USC/Information Sciences Institute, 13 August 2896. 2432 [4] Malkin, G., "Internet Users' Glossary", RFC 1983, USC/Information 2433 Sciences Institute, 16 August 2896. 2435 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2436 Levels", RFC 2119, USC/Information Sciences Institute, 26 March 2437 1997. 2439 [6] Atkinson, R., "IP Authentication Header", RFC 1826, 2440 USC/Information Sciences Institute, 9 August 2895. 2442 [7] Atkinson, R., "Security Architecture for the Internet Protocol", 2443 RFC 1825, USC/Information Sciences Institute, 9 August 2895. 2445 [8] Atkins, D., Stallings, W., Zimmermann, P., "PGP Message 2446 Exchange" Formats", RFC 1991, , USC/Information Sciences 2447 Institute, 16 August 2896 2449 [9] S Myers, J., M. Rose, "Post Office Protocol - Version 3", RFC 2450 1939, USC/Information Sciences Institute, 14 May 1996 2452 [10] Postel, J., "Simple Mail Transfer Protocol", RFC 821, 2453 USC/Information Sciences Institute, January 8 1982 2455 9. Authors' Addresses 2457 Dave Piscitello Lisa Phifer 2458 Core Competence Core Competence 2459 1620 Tuckerstown Road 1620 Tuckerstown Road 2460 Dresher, PA 19025 Dresher, PA 19025 2461 (215) 830-0692 (215) 830-0692 2462 dave@corecom.com lisa@corecom.com 2464 Richard Hovey Yangwei Wang 2465 Bellcore Bellcore 2466 445 South Street, MRE-2N264 331 Newman Springs Rd, NVC-3C221 2467 Morristown, NJ 07960-6438 Red Bank, NJ 07701 2468 (201)829-4176 (908)758-5107 2469 hovey@bellcore.com ywang@cc.bellcore.com 2470 Appendix A. HDML Transactions using MNCP 2472 The design of the Mobile Network Computing Protocol (MNCP) makes it 2473 possible to implement a wide range of services efficiently and reliably 2474 using low-bandwidth, high-latency wireless links. In this Appendix, we 2475 describe the implementation of a Web browsing and information push 2476 service based on the Handheld Device Markup Language (HDML). 2478 HDML has been proposed as a means of bringing interactive browsing 2479 services to devices with limited processing, storage, display and input 2480 capabilities. The language is based on the concept of decks (the basic 2481 unit transported) and cards (the basic unit displayed). The language 2482 is a replacement for HTML for portable devices such as screen 2483 telephones and two-way pagers, and makes use of the infrastructure of 2484 HTTP connections and Web servers that has been created for HTML 2485 browsers. (See http://www.w3.org/pub/WWW/TR/NOTE-Submission-HDML.html 2486 for a copy of the HDML proposal) 2488 An HDML browser on an MNCP-capable client device begins by registering 2489 with the Mobility server. The client registers by submitting a request 2490 with the Function ID set to 1, and the Service ID set to the pre- 2491 defined HDML service (assume 85 is assigned to HDML). During the 2492 registration process, the Mobility server validates the user, based on 2493 the submitted Subscriber ID and password, ensuring both that the 2494 subscriber is registered with the server and authorized to use the 2495 requested service. Once registered, the client device can perform 2496 interactive browsing of HDML sites and receive unsolicited (pushed) 2497 messages encoded in HDML. 2499 Browsing of HDML sites is initiated by the subscriber, pointing the 2500 browser to the desired URL. The HDML browser formulates a HTTP request 2501 (e.g., GET or POST) of the specified URL, and submits this to the MNCP 2502 agent code on the client device. The MNCP code then formulates a single 2503 packet or multi-packet request to a pre-defined Service ID (i.e., 85) 2504 on the Mobility server. The MNC protocol handles reliable delivery of 2505 the request to the Mobility server, invisible to the HDML browser. 2507 The Mobility server routes incoming messages to code modules based on 2508 the Service ID. Any message with a Service ID of 85 are routed to the 2509 HDML service module. The HDML service module then extracts the HTTP 2510 request from the MNCP message. The HTTP request could be implemented 2511 by using a Function ID to correspond to each HTTP function (i.e., 2512 Function ID 2 maps to GET, Function ID 3 maps to PUT) or the HTTP 2513 request as formulated by the client could be included as the body of 2514 the message. The HDML service module then forwards the HTTP request to 2515 the HDML information server. When the Mobility server receives the 2516 response from the HDML information server, it encodes the response with 2517 the previously negotiated compression algorithm and delivers it to the 2518 client device. The subscriber could then continue browsing in a 2519 similar fashion, based on the contents of the HDML deck that was 2520 returned. 2522 The process of `pushing' a message to the HDML browser is implemented 2523 from the server side. An external server begins the process by 2524 formulating an HDML deck to be delivered to a particular HDML service 2525 subscriber. Alternatively, a person may wish to send an email- or 2526 page-type notice to the subscriber. The information server or the 2527 individual must deliver the message to the Mobility server, using the 2528 interface specified by the Mobility server. (HTTP connections or e- 2529 mail messages are two possibilities.) When the Mobility server 2530 receives such a message, it first determines if the subscriber to whom 2531 the message is addressed is registered. If the subscriber is not 2532 registered for HDML service, the message might be returned or placed in 2533 a message store. If the subscriber is currently registered, the 2534 Mobility server routes the message to the HDML service module. The 2535 HDML service module takes the incoming message and formats it for 2536 delivery. This formatting might include converting a plain-text 2537 message to HDML, as well as compression and segmentation for MNCP 2538 delivery. The HDML service assigns the proper Service ID (85) and a 2539 pre-defined Function ID that corresponds to pushed messages. In fact, 2540 multiple Function IDs could be assigned to pushed messages, with 2541 different values indicating different levels of priority, for example. 2542 Using single- or multiple-packet reliable delivery, the Mobility server 2543 then forwards the message to the HDML client. The browser code 2544 receives the HDML deck, interprets the format for proper display and 2545 informs the user in an appropriate fashion. The user can then interact 2546 with the delivered message in standard browsing mode. 2548 When the subscriber has completed browsing and/or no longer wishes to 2549 receive pushed messages, terminating the browser will perform a de- 2550 registration operation, separating the subscriber from the Mobility 2551 server. The de-registration message again uses the HDML-assigned 2552 Service ID (85) and the Function ID of 0. 2554 A variety of services can be implemented using HDML. Currently, public 2555 services such as phone-number searches, news reports and weather 2556 forecasts are available. Users of such services would not generally 2557 benefit from the overhead of sophisticated security measures. However, 2558 HDML could be used in intranet-like applications, such as salespeople 2559 querying market data, which would require encryption and 2560 authentication. To properly protect the data transmitted in such 2561 applications, the security measures must protect the entire path from 2562 client to server, not just the wireless portion of the link. End-to- 2563 end encryption and authentication protocols could be built into HDML 2564 browsers and HDML information servers to protect sensitive data. 2566 Figure A-1 depicts the MNC architecture as used to support HDML 2567 transactions. Figure A-2 illustrates the message flows. 2569 MCD MS HDML Server 2570 +-----------+ +----------+ +--------+ 2571 | | HDML | | HDML | Info | 2572 |HDML Client| <--> |HDML Proxy| <--> | Server | 2573 +-----------+ +-----+----+ +--------+ 2574 | MNCP | |MNCP |HTTP| | HTTP | 2575 +-----------+ +-----+----+ +--------+ 2576 | UDP | |UDP |TCP | | TCP | 2577 +-----------+------+-----+----+------+--------+ 2578 | Wireless Network | Wireline Network | 2579 +------------------------+--------------------+ 2581 Figure A-1. 2583 MCD MS HDML Server 2584 | | | 2585 REG_REQ |PT_CMD(S85,F1) | | 2586 ------->|-------------->| | 2587 REG_CNF |PT_ACK(ACK_OK) | Register MCD | 2588 <-------|<--------------| | 2589 | | | 2590 | | | 2591 FUN_REQ |PT_CMD(S85,Fx) | Browser Pull | 2592 ------->|-------------->| HDML GET:URL | 2593 FUN_CNF |PT_ACK(ACK_OK) |-------------->| 2594 <-------|<--------------| |Perform GET 2595 | | |Return PUT 2596 | | HDML PUT | 2597 |PT_NTFN(S85,Fy)|<--------------| 2598 |<--------------| | 2599 |PT_ACK(ACK_OK) | | 2600 |-------------->| | 2601 |PT_DATA(M,DECK)| | 2602 |<--------------| | 2603 |PT_ACK(ACK_OK) | | 2604 |-------------->| | 2605 |PT_DATA(F,DECK)| | 2606 <-------|<--------------| | 2607 FUN_IND |PT_ACK(ACK_OK) | | 2608 | | | 2609 | | | 2610 | | |Server Push 2611 | | HDML POST:URL | 2612 |PT_NTFN(S85,Fz)|<--------------| 2613 |<--------------| | 2614 |PT_ACK(ACK_OK) | | 2615 |-------------->| | 2616 |PT_DATA(M,DECK)| | 2617 |<--------------| | 2618 |PT_ACK(ACK_OK) | | 2619 |-------------->| | 2620 |PT_DATA(F,DECK)| | 2621 <-------|<--------------| | 2622 FUN-IND |PT_ACK(ACK_OK) | | 2623 | | | 2624 | | | 2625 DEREGREQ|PT_CMD(S85,F0) | | 2626 ------->|-------------->| | 2627 DEREGCNF|PT_ACK(ACK_OK) |Deregister MCD | 2628 <-------|<--------------| | 2629 | | | 2630 | | |Server Push 2631 | | HDML POST:URL | 2632 | X<--------------| 2633 | | | 2634 Key: S85 = Service ID of HDML-based service 2635 F1 = Function ID of FUN_REG_REQ 2636 F0 = Function ID of FUN_DEREG_REQ 2637 Fx,y,z = Function IDs of FUN__REQs 2638 M,DECK = IE_DATA_MORE containing segment of HDML deck 2639 F,DECK = IE_DATA_FINAL containing last segment of HDML deck 2641 Note: This flow illustrates explicit registration. For implicit 2642 registration, omit first MNCP packet sequence; MS registers 2643 MCD upon receipt of FUN__REQ instead. 2645 Figure A-2. 2647 Appendix B. Future Protocol Extensions 2649 Several extensions are under consideration for the MNCP. 2651 A reliable delivery that uses a sliding window mechanism to improve 2652 performance. The objective is to extend the current positive 2653 acknowledgment of packets with retransmission by allowing more than one 2654 packet to be transmitted before waiting for acknowledgment from the 2655 receiver. Full or partial window credit indications would accompany 2656 cumulative acknowledgments returned by the receiver, and selective 2657 acknowledgments would be a desirable extension as well 2659 A means of providing data synchronization at the session control level 2660 that persists beyond the possibly abrupt termination or interruption of 2661 an underlying connection is desirable. Such a mechanism would allow a 2662 mobile computing device to continue a transfer from a commonly agreed 2663 upon starting point in an octet stream rather than from the beginning 2664 of the stream. 2666 It would be desirable to be able to extend the existing "per reliable 2667 transfer" authentication model in MNCP to support strong authentication 2668 whether applications are explicitly or implicitly registered. It would 2669 also be useful to allow the MCD to verify the authenticity of a 2670 Mobility Server. 2672 One method under consideration is to identify an authentication method 2673 and encode the authentication information appropriate for that method 2674 in the same registration request or data request packet. The initiator 2675 (MCD or MS) chooses a method, performs whatever computation is required 2676 to generate the strong authentication information for that method, and 2677 then sends the packet. The initiator decides what security is 2678 appropriate. A new IE identifying authentication-method can be sent in 2679 the clear, with the remainder of the PT_NTFN (PT_CMD) (including 2680 authentication information) encrypted as per the indicated security 2681 method.