676 TCP/IP Tutorial and Technical Overview implementing an end-to-end connection, WP-TCP behaves like any other TCP application, establishing a connection directly with the origin server. This is illustrated in Figure 18-9. Figure 18-9 The end-to-end approach The decision to implement the end-to-end approach over the split-TCP approach is usually determined by service, server, and hardware provisioning or the specific needs of the application layer. WP-TCP optimizations As noted previously, certain scenarios exist on a wireless network that make a purely TCP connection less desirable. Such scenarios include:  Frequent packet loss  Smaller window sizes  Long periods of silence or connection loss due to exponential back-off retransmission mechanisms  Redundant transmission  Periods of disconnection due to lack of coverage Upper Layers WP-TCP IP Wireless Bearer Upper Layers TCP IP Wireless Bearer Wireless client Origin server Wireless Bearer Wired Interface IP Router Chapter 18. Wireless Application Protocol 677 The profiling of TCP for WP-TCP sought to optimize the protocol to compensate for these scenarios. Specifically, eight optimizations were included in WP-TCP. These are:  Large window size: Built in to TCP is the use of the Bandwidth Delay Product (BDP), calculated from the available bandwidth and the round-trip time, to calculate the minimum window size. It also calculates the maximum window size using the smallest value of the send or receive buffers. WP-TCP can opt to use the maximum window size, relying on the congestion control mechanisms built into TCP to regulate the data as needed. The WP-TCP specification indicates that implementation of this optimization is recommended, but not required.  The window scale option: Entities that opt to use the large window size are required to also implement the window scale option defined by RFC 1323. If an entity does not support the large window size optimization, implementation of the window scale optimization is optional.  Round-trip time measurement: Also defined in RFC 1323, round-trip time measurement (RTTM) is recommended for use by any entity that implements window sizes larger than 64 K. This also requires the use of the time stamp option.  Large initial window: The standard TCP implementation includes an initial window up to two segments in size. However, WP-TCP employs an extension defined in RFC 2414 that allows WP-TCP to send an initial window of three or four segments. This is limited to 4380 bytes. Implementation of this optimization is optional.  Path MTU discovery: WP-TCP now supports the procedures, defined in RFCs 1191 and 1981, used to discover the maximum transmission unit (MTU) of any given path. This allows WP-TCP to optimize the amount of data sent in each packet to avoid fragmentation or dropped packets. Implementation of this optimization is recommended, but not required.  MTU larger than the default IP MTU: If an entity cannot support path MTU discover (for example, if some of the routers in the path do not support the needed ICMP messages), a WP-TCP implementation can assume a value exceeding the default IPv4 or IPv6 values. However, the value assumed must not exceed 1500 bytes, and must reflect the maximum segment size negotiated when establishing the TCP connection.  Selective acknowledgement: The fast recover algorithm, defined in RFC 2581, tends to be less efficient when attempting to recover from multiple losses in a single window. This scenario is very likely on wireless connections, and therefore, an alternative to the fast recover algorithm was implemented. Selective acknowledgement (SACK) was defined in RFC 2018 678 TCP/IP Tutorial and Technical Overview and allows WPT-TCP to send acknowledgements selectively, indicating what data needs to be retransmitted. Implementation of this optimization is required.  Explicit congestion notification (ECN): Defined in RFC 2481, ECN allows a WP-TCP receiver to notify the sender of the data of congestion in the network. This allows the sender to reduce it’s congestion window. Implementation of this optimization is optional. 18.9.3 Wireless Control Message Protocol (WCMP) The Wireless Control Message Protocol (WCMP) very closes mirrors the functionality of the Internet Control Message Protocol (ICMP) defined in RFCs 792 and 2463. Defined in the OMA WAP-202-WCMP-20010624-a specification, it is used by the WDP to provide ICMP-like capability when using wireless bearers that do not support IP. Specifically, WCMP is used to report problems occurring when processing datagrams. Errors reported by WCMP messages can be broken into six types, some of which can be further divided into codes. These are listed in Table 18-2. Table 18-2 WCMP types and codes WCMP message WCMP type WCMP code Destination unreachable 51 Communication administratively prohibited 1 Address unreachable 3 Port unreachable 4 Parameter problem 54 Erroneous header field 0 Message too big 60 0 Reassembly failure 61 Reassembly time exceeded 1 Buffer overflow 2 Echo request 178 0 Echo reply 179 0 Chapter 18. Wireless Application Protocol 679 WCMP message structure The message structure of WCMP messages varies based on the type of wireless bearer used by the originator or the message, as well as the type of the WCAMP message. However, every WCMP does adhere to a general format, as defined in Figure 18-10. Figure 18-10 General WCMP message structure 18.9.4 Wireless Transaction Protocol (WTP) The Wireless Transaction Protocol, defined in the OMA WAP-224-WTP-20010710-a specification, provides a mechanism especially designed for WAP terminals with limited resources over networks and with low to medium bandwidth. This technology allows more subscribers on the same network due to reduced bandwidth utilization. WTP provides unreliable and reliable data transfer based on the request/reply paradigm. Unlike TCP, there is no connection setup and tear down. Compared to TCP, where a SYN and ACK flow is started before the first data is transmitted, WTP carries data in the first packet of the protocol exchange. Additionally, WTP employs a message-oriented model, as opposed to TCP’s stream-oriented implementation. WTP classes of operation There are three classes of operation, numbering zero through two. Class 0 Class 0 is defined by the OMA specification as “unconfirmed invoke message with no result message.” This is a datagram that can be sent within the context of an existing WSP session (see 18.9.5, “Wireless Session Protocol (WSP)” on page 682). However, it is not intended to be a primary method of sending Bit/Octet 0 1 2 3 4 5 6 7 1 Type of control message 2 Code of control message 3-n Data fields for WCMP (0 n octets) 680 TCP/IP Tutorial and Technical Overview datagrams. For that functionality, use WDP instead. The sequence of events in a Class 0 transaction is as follows: 1. An initiator sends an invoke message to the responder. After the message has been sent, the initiator’s role in the transaction has ended. No retransmissions are sent of the message. 2. The responder receives the invoke message. No response is sent acknowledging receipt of the invoke message. After the message has been received, the transaction is complete. Because there are no retransmissions or replies, this type of transaction is considered stateless and cannot be aborted. An additional illustration of a Class 0 transaction can be found in Figure 18-12 on page 685). Class 1 Class 1 is defined as “confirmed invoke message with no result message.” This is used for reliable data push (see 18.6, “WAP push architecture” on page 664), where no response from the destination is expected, though the transaction is still termed a reliable datagram service. The sequence of events in a Class 1 transaction is as follows: 1. An initiator sends an invoke message to the responder. 2. The responder receives the invoke message and returns an acknowledgement (but not a result message). If the initiator does not receive an acknowledgement, the invoke message is retransmitted. The transaction remains in an active state until the acknowledgement arrives at the initiator. Upon receipt of the acknowledgement, the Initiator considers the transaction to have ended. The Class 1 transaction can be aborted at any point during the sequence of events. Class 2 Class 2 is defined as “confirmed invoke message with one confirmed result message.” In this class, one single request produces a single reply. This comprises the typical request/response interaction model most widely employed by applications. The sequence of events in a Class 2 transaction is as follows: 1. An initiator sends an invoke message to the responder. 2. The responder might send back an acknowledgement to this message. This happens if the responder is not able to send back a result message immediately. 3. The responder sends back a result message. If no acknowledgment had been previously sent to the initiator, this result message implicitly acknowledges the receipt of the invoke message. If the initiator receives no acknowledgement or result message, it retransmits the invoke message. Chapter 18. Wireless Application Protocol 681 4. The initiator sends back an acknowledgement upon receiving the result message. The transaction is considered complete when the responder receives the acknowledgement. If no acknowledgement is received, the responder retransmits the result message. The transaction can be aborted at any time during the sequence of events. An additional illustration of a Class 2 transaction is in Figure 18-15 on page 692. Layer-to-layer communication Service primitives are used to control the transaction traffic between the layers of the client and server. These service primitives have a similar syntax as described for WSP: X - generic name. type (parameters) Where X designates the layer providing the service. For the transaction layer, it is TR. The primitive types and their abbreviations are the same as described for WDP (see Table 18-1 on page 674). There are three primitives for the service to the upper layer: TR-Invoke Initiates a new transaction. TR-Result Sends back a result of a previously initiated transaction. TR-Abort Aborts an existing transaction. 682 TCP/IP Tutorial and Technical Overview Example of a WSP-WTP sequence flow Figure 18-11 depicts the flow of a primitive sequence and shows the relationship between WSP and WTP requests and responses. The flow is based on a Class 2 transaction which, as defined earlier, is a reliable, confirmed message exchange. Figure 18-11 WSP-WTP primitive sequence for request-response The following steps describe the flow of a primitive sequence: 1. The first sequence is initiated through a client application (for example, an inquiry for a service), which starts with a S-MethodInvoke.req operation to the server application within a session. 2. The second sequence is a response from the server to confirm to WSP in the client stack that the invoke message (the inquiry) has been received by the server. 3. The third sequence returns the result request (reply to the inquiry) from the server to the client. 4. The fourth sequence confirms the receipt to the server that the reply was received correctly. 18.9.5 Wireless Session Protocol (WSP) WSP, defined by the OMA WAP-230-WSP-20010705-a specification, establishes a reliable session between the client and the server and releases that session in an orderly manner. An illustration of a client/server session is in Figure 18-13 on page 686. WSP session establishment agrees on a common level of protocol functionality using the capability of negotiation. WSP exchanges WTP Client WSP Server WSP TR-Invoke.req TR-Invoke.ind S-MethodInvoke.req TR-Invoke.ind S-MethodInvoke.ind S-MethodInvoke.res S-MethodInvoke.cnf TR-Invoke.res TR-Invoke.cnf S-MethodResult.req S-MethodResult.ind TR-Invoke.req TR-Invoke.ind TR-Invoke.res S-MethodResult.res TR-Invoke.cnf S-MethodResult.cnf Chapter 18. Wireless Application Protocol 683 content between the client and server using compact encoding, and also controls communication interrupt. Communication interrupt happens with change of a bearer, such as SMS (see Figure 18-3 on page 661). WSP defines two protocols:  Connection-mode session services over a transaction service This mode is used for long-lived connections. A session state is maintained. There is reliability for data sent over a connection-mode session.  Non-confirmed, connection-less services over a datagram transport service This service is suitable when applications do not need reliable delivery of data and do not care about confirmation. It can be used without actually having established a session. WSP provides semantics and mechanisms based on Hypertext Transport Protocol (HTTP) 1.1 and enhancements for wireless networks and its WAP terminals. Such enhancements include things such as long-lived sessions and data pushing, capability negotiation, and the ability to suspend and resume a session. Basic functionality Content headers are used to define content type, character set encoding, languages, and so on. Compact binary encoding is defined for the well-known headers to reduce protocol inefficiencies. A compact data format is supported that provides content headers for each component within the composite data object. This is a semantically equivalent binary form of the MIME-multipart/multimixed format used by HTTP 1.1. As part of the session establishment process, request and response headers that remain constant over the life of the session can be exchanged between the service users in the client and the server. WSP passes through client and server session headers, as well as request and response headers, without additions or removals. The life cycle of a WSP session is not tied to the underlying transport protocol. A session re-establishment protocol has been defined that allows sessions to be suspended and resumed without the processing costs of initial establishment. This allows a session to be suspended while idle to release network resources or save battery power. The session can be resumed over a different bearer network. Layer-to-layer communication Communications between layers and between entities within the session layer are accomplished through service primitives. They represent the logical 684 TCP/IP Tutorial and Technical Overview exchange of information and control between the session layer and adjacent layers. Service primitives consist of commands and their respective response associated with the service provided and parameters. For example: X-service.type (parameter) Where X designates the layer providing the service; for WSP, it is S. The service types are the same as those used for WDP, illustrated in Table 18-1 on page 674. When using service primitives, additional parameters are possible. They describe certain types of parameters. For example: Addresses They describe client and server addresses to establish the session. Headers and body They describe the HTTP entity-body. The headers distinguish between requests and responses sent from client to the server or reverse. The body contains the content of the message. Capabilities These are service facilities, for example: • Largest transaction data unit • Set of code page names • Maximum of outstanding requests The capabilities can be negotiated between the client and the server. Push identifier Indicates that the received message is a push transaction of the session that is pending on the service interface. Reason The service provider uses the reason type to report the cause of a particular state of a primitive. Valid reasons are: PROTOERR The rules of the protocol prevented the peer from performing the operation in its current state. For example, the used PDU was not allowed. DISCONNECT The session was disconnected while the operation was still in progress. SUSPEND The session was suspended while the operation was still in progress. Chapter 18. Wireless Application Protocol 685 RESUME The session was resumed while the operation was still in progress. CONGESTION The peer implementation could not process the request due to lack of resources. CONNECTERR An error prevented session creation. MRUEXCEEDED The SDU size in a request was larger than the maximum receive unit negotiated with the peer. MOREXCEEDED The negotiated upper limit on the number of simultaneously outstanding method or push requests was exceeded. PEERREQ The service peer requested the operation to be aborted. NETERR An underlying network error prevented completion of a request. USERREQ An action of the local service user was the cause of the indication. Service primitive sample The behavior of service primitives is illustrated using a time sequence chart (Figure 18-12). Figure 18-12 Non-confirmed service This figure depicts a simple non-confirmed service. The client invokes an S-request primitive, which results in an S-indication primitive in the server (WSP Wireless Network Client Server S-request S-indication [...]... WAP-217_105-WPKI-2002 081 6-a – WAP Public Key Infrastructure SIN 105 (August 2002) WAP-219-TLS-20010411-a – WAP TLS Profile and Tunneling Specification (April 2001) 704 TCP/IP Tutorial and Technical Overview WAP-219_100-TLS-20011029-a – WAP TLS Profile and Tunneling SIN 100 (October 2001) WAP-266-WTA-200109 08- a – Wireless Telephony Application Specification (September 2001) WAP-2 68- WTAI-200109 08- a – Wireless... WAP-255-WTAIGSM-200109 08- a – WTAI, GSM Specific Addendum (September 2001) WAP-269-WTAIIS136-200109 08- a – WTAI, IS-136 Specific Addendum (September 2001) WAP-270-WTAIPDC-200109 08- a – WTAI, PDC Specific Addendum (September 2001) WAP-2 28- WTAIIS95-200109 08- a – WTAI, IS95 Specific Addendum (September 2001) Chapter 18 Wireless Application Protocol 705 706 TCP/IP Tutorial and Technical Overview 19 Chapter 19... – Key refreshing rules – Session ID 6 98 TCP/IP Tutorial and Technical Overview SEC-Exchange: Performs public key authentication or key exchange with a client Additional information about public keys is in OMA specifications WAP-217-WPKI-20010424-a, WAP-217_103-WPKI-20011102-a, and WAP-217_105-WPKI-2002 081 6-a SEC-Commit: Initiated when the handshake is completed and either peer requests to switch to... RFCs provide detailed information about the TCP/IP protocol suite and architectures presented throughout this chapter: RFC 0792 – Internet Control Message Protocol (September 1 981 ) RFC 0793 – Transmission Control Protocol (September 1 981 ) 702 TCP/IP Tutorial and Technical Overview RFC 1122 – Requirements for Internet Hosts - Communication Layers (October 1 989 ) RFC 1191 – Path MTU Discovery (November... ConnectReply Figure 18- 15 WSP WTP normal session establishment Normal session termination Figure 18- 16 shows the normal session termination process Client/Server S-Disconnect.req S-Disconnect.ind Server/Client WTP Class 0 Transaction Disconnect Figure 18- 16 WSP WTP normal session termination 692 TCP/IP Tutorial and Technical Overview S-Disconnect.ind Normal session suspend and resume Figure 18- 17 shows the... WAP-261_101-WTLS-20011027-a, and WAP-261_102-WTLS-20011027-a WTLS is based upon the industry-standard Transport Layer Security (TLS) protocol, but has been optimized for use over narrow-band communication channels It ensures data integrity, privacy, authentication, and denial-of-service 696 TCP/IP Tutorial and Technical Overview protection For Web applications that employ standard Internet security techniques... headers (equivalent to HTTP headers), and request body (to contain the data associated with the request) 688 TCP/IP Tutorial and Technical Overview S-MethodResult This service primitive returns the response to an operation request It can be invoked only after a preceding S-MethodInvoke has occurred The following parameters can be used for this service primitive: client and server transaction ID (distinguishes... required for particular transactions (see 18. 9.4, “Wireless Transaction Protocol (WTP)” on page 679) WAP client WAP server WAE WAE WSP WSP WTP WDP Bearer Wireless Network WTP Bearer Figure 18- 13 Client/server connection flow showing two WSP sessions 686 TCP/IP Tutorial and Technical Overview WDP WSP connection-mode Connection-mode session services provide two standard facilities: Session management facility... WAP-266-WTA-200109 08- a – Wireless Telephony Application Specification WAP-2 68- WTAI-200109 08- a – Wireless Telephony Application Interface Specification WAP-255-WTAIGSM-200109 08- a – WTAI, GSM Specific Addendum WAP-269-WTAIIS136-200109 08- a – WTAI, IS-136 Specific Addendum WAP-270-WTAIPDC-200109 08- a – WTAI, PDC Specific Addendum WAP-2 28- WTAIIS95-200109 08- a – WTAI, IS95 Specific Addendum 18. 12 RFCs relevant... passed between the server and client, nor passing the message up to higher layers in the architecture This is illustrated in Figure 18- 22 WAP client WAP server Upper Layers Upper Layers TLS TLS Transport and IP Layers Transport and IP Layers Wireless WAP proxy Transport and IP Layers Transport and IP Layers Wireless Wireless Wireless Figure 18- 22 An example of TLS tunnelling 18. 10.2 Wireless Identity . transaction. 682 TCP/IP Tutorial and Technical Overview Example of a WSP-WTP sequence flow Figure 18- 11 depicts the flow of a primitive sequence and shows the relationship between WSP and WTP requests and. connections, and therefore, an alternative to the fast recover algorithm was implemented. Selective acknowledgement (SACK) was defined in RFC 20 18 6 78 TCP/IP Tutorial and Technical Overview and allows. Transaction Resume ResumeReply 694 TCP/IP Tutorial and Technical Overview Normal method invocation Figure 18- 18 shows the normal method invocation process. Figure 18- 18 WSP-WTP normal method invocation WSP