(unknown)
"Kevin Purser (QA/EMC)" <[email protected]>
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <7B2A7784F4B7F0409947481F3F3FEF830A082B9A@eammlex037.lmc.ericsson.se> |
Hello All, I would like to submit the following I-D for consideration by the PPPEXT WG. Please feel free to send comments/questions/flames directly to me. Kev Abstract: If the Internet is accessed via cellular networks, the Point-to-Point protocol (PPP) is most commonly used for configuration of the circuit-switched or packet-switched link. Thus, this PPP configuration time comes in addition to the usual call-setup time for the cellular connection. In many cases this will result in a fairly long "wait time" as perceived by end users before actual application data can be transmitted. This proposal describes a solution in which the PPP configuration time can be significantly reduced (on the order of seconds) in cases where both peer protocol entities can be modified according to this proposal, which involves modifying standard PPP. In cases where one PPP peer is modified and the other utilizes only standard PPP, the modified peer can fallback to standard PPP operation. This fallback mechanism will not noticeably affect the PPP setup time, and serves to ensure interoperability. <<draft-purser-pppext-pppcn-00.txt>>
draft-purser-pppext-pppcn-00.txt
(text/plain, 17.3 KB)
Internet Draft Kevin Purser, editor
Document: draft-purser-pppext-pppcn-00.txt Ericsson
Expires: March 2004 September 2003
PPP Adaptation for Cellular Networks
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
If the Internet is accessed via cellular networks, the Point-to-Point
protocol (PPP) is most commonly used for configuration of the
circuit-switched or packet-switched link. Thus, this PPP
configuration time comes in addition to the usual call-setup time for
the cellular connection. In many cases this will result in a fairly
long "wait time" as perceived by end users before actual application
data can be transmitted.
This proposal describes a solution in which the PPP configuration
time can be significantly reduced (on the order of seconds) in cases
where both peer protocol entities can be modified according to this
proposal, which involves modifying standard PPP. In cases where one
PPP peer is modified and the other utilizes only standard PPP, the
modified peer can fallback to standard PPP operation. This fallback
mechanism will not noticeably affect the PPP setup time, and serves
to ensure interoperability.
Purser expires March 2004 [Page 1]
Internet Draft PPP-CN September 2003
1. Introduction
In cellular networks, direct access to the internet is provided to
mobile users via the PDSN in CDMA2000 or the MSC/GSN in GSM/GPRS.
The Point-to-Point Protocol (PPP) is first used to configure the
traffic channel between the terminal equipment (TE) and the cellular
network node and subsequently to transport network layer protocol
data units (PDU) over the traffic channel. Since PPP was initially
designed to run over the wire, it normally requires numerous
exchanges of signaling messages (figure 1) between the two peers to
configure their connection, namely LCP, IPCP, etc.
+------+ +-------+
| TE | |3G Node|
+------+ +-------+
| LCP-Req |
|------------------------------>|
| LCP-Req-Ack |
|<------------------------------|
| PAP/CHAP-Req |
|------------------------------>|
| PAP/CHAP-Req-Ack |
|<------------------------------|
| IPCP-Req |
|------------------------------>|
| IPCP-Req-Ack |
|<------------------------------|
| |
Figure 1: Common message exchanges involved in PPP negotiation
For the sake of simplicity, the LCP- and IPCP- Requests initiated
concurrently by the 3G node are not shown in figure 1. In addition,
CHAP also requires a 3-way handshake as opposed to the 2-way
handshake for PAP initiated by the TE as indicated. However, this
does not change the overall PPP configuration time, since the 3G node
can send the CHAP challenge immediately following the LCP-Req-Ack.
Note that standard PPP [PPP] specifies that neither the PAP/CHAP
authentication phase, nor the IPCP configuration phase, nor the
exchange of IP packets can begin prior to the completion of the
preceding phase. This results in a minimum duration of the PPP
negotiation of 2 or 3 round trip times (RTT), depending on whether
the optional authentication phase is employed.
With PPP in use traditionally over wired links, these multiple round
trips aren't of major consequence. Cellular links on the other hand
are characterized by high latency and a much higher rate of packet
loss. Thus, the negotiation shown in figure 1 when applied to
Purser expires March 2004 [Page 3]
Internet Draft PPP-CN September 2003
cellular networks can typically comprise 7 RTTs or more, due to
retransmissions after packet loss, additional PPP negotiation
parameters, etc. This number of round trips, considering that the
average RTT in GSM today is approximately 750ms, can easily result in
PPP negotiation setup times of several seconds.
1.1. Acronyms
This section lists acronyms commonly used throughout this document.
CHAP - Challenge-Handshake Authentication Protocol
GSN - GPRS Support Node
IPCP - Internet Control Protocol
LCP - Link Control Protocol
MRU - Maximum Receive Unit
MSC - Mobile Switching Center
PAP - Password Authentication Protocol
PDSN - Packet Data Serving Node
PDU - Protocol Data Unit
PPP - Point-to-Point Protocol
RTT - Round Trip Time
TE - Terminal Equipment
1.2. Definitions
This section lists terms commonly used throughout this document.
Standard-PPP-Peer: A PPP peer which only implements PPP as specified
in [PPP].
PPPCN-Peer: A PPP Peer which implements a modified PPP state machine
which allows it to conform to standard PPP as specified in [PPP] when
required, but also to conform to the enhanced PPP as defined in this
document.
Masked PPP packets: LCP, PAP, CHAP, IPCP or IP packets with syntax
and semantics as defined in [PPP], but carrying an "incorrect" value
in the PPP protocol field. Protocol fields values of these packets
MUST NOT be reserved (see [Num]), and MUST be uniquely chosen
conforming to [PPP] with respect to how valid protocol fields values
are defined. For example, protocol field values chosen from the
0x8001 to 0x801F (hex) range would be acceptable candidates. PPPCN-
Peers will accept and process these packets, but as put forth in
[PPP], Standard-PPP-Peers MUST silently discard these packets.
2. Protocol Description
The general premise of this protocol is that when 2 PPPCN-Peers begin
Purser expires March 2004 [Page 4]
Internet Draft PPP-CN September 2003
negotiating PPP setup, the strict separation of LCP, authentication
(PAP or CHAP) and IPCP phases as well as the exchange of IP packets
will no longer be required. Instead, both peers will assume a pre-
defined set of LCP and IPCP options as defined in figure 2, and
initiate the aforementioned phases concurrently as follows.
======================================================
protocol | option | default value
---------+----------------------------+---------------
LCP | MRU | 576
---------+----------------------------+---------------
LCP | Authentication Protocol | not required
---------+----------------------------+---------------
LCP | Quality Protocol | not required
---------+----------------------------+---------------
LCP | Magic Number | not required
---------+----------------------------+---------------
LCP | Protocol Field Compression | required
---------+----------------------------+---------------
LCP | Address/Control Field Comp | required
---------+----------------------------+---------------
IPCP | IP-Addresses | not required
---------+----------------------------+---------------
IPCP | IP-Compression Protocol | not required
---------+----------------------------+---------------
IPCP | IP-Address | required
---------+----------------------------+---------------
IPCP | TCP/IP Header Compression | required
======================================================
Figure 2: Default values to be used for LCP and IPCP phases of PPP
negotiation
A PPPCN-Peer MUST begin negotiations by sending an initial set of
masked PPP packets, where each packet is sent immediately following
the preceding packet, without waiting for an acknowledgement of any
kind. This MUST be immediately followed by a standard LCP packet.
The standard LCP packet MUST carry all options of the pre-defined set
that differ from the default options specified in [PPP]. A receiving
Standard-PPP-Peer MUST silently discard the masked PPP packets as
specified in [PPP], and begin by processing the standard LCP packet.
On the other hand, a receiving PPPCN-Peer MUST silently discard the
standard LCP packet but instead begin by processing the masked PPP
packets.
Optionally, a PPPCN-Peer may change pre-defined LCP or IPCP settings
(e.g. the MRU to a value between 296 and 1500) by sending an
appropriate masked LCP or IPCP packet as a part of the aforementioned
Purser expires March 2004 [Page 5]
Internet Draft PPP-CN September 2003
initial set of masked PPP packets. This MAY or MAY NOT be accepted
by the receiving PPPCN-Peer which MUST respond with a masked ACK or
NACK, respectively.
A receiving PPPCN-Peer will be able to determine by inspecting the
first packets whether it is communicating with a Standard- or PPPCN-
Peer. Thus, in order to guarantee interoperability, a PPPCN-Peer
which only receives a standard LCP packet MUST fallback to operate as
a Standard-PPP-Peer. Likewise, a Standard-PPP-Peer which receives
any masked PPP packets will silently discard them and acknowledge the
starting standard LCP packet, thus indicating to the originating PPP-
Peer to fallback into Standard-PPP-Peer mode.
PPPCN-Peers MUST support both PAP and CHAP, but the PPPCN-Peer in the
3G cellular node dictates the authentication protocol to be used. If
authentication is required, any masked IP packets received during the
PPP negotiation by a PPPCN-Peer MUST be buffered and MUST NOT be
forwarded to the receiving IP peer until the necessary PPP
negotiation phases have succeeded.
In the case of any unsuccessful phase of the PPP negotiation between
two PPPCN-Peers (e.g. the authentication fails but an IP address has
already been assigned, and IP packets received), the link MUST be
terminated, and any state in the 3G cellular node (any assigned IP
addresses, received IP packets, etc) regarding the originating PPPCN-
Peer MUST be discarded, and any allocated IP addressed MUST be de-
allocated.
3. Use Cases
This section will illustrate a few example scenarios. The following
cases assume that a PPPCN-Peer in the TE communicates with a PPPCN-
Peer in the 3G Node, and accordingly, all packets shown are masked
PPP packets unless otherwise noted. For the sack of brevity, we have
omitted optional masked LCP/IPCP packets for changing pre-defined
settings. Also, packets sent immediately after one another are drawn
with the same arrow, to indicate concurrency.
Purser expires March 2004 [Page 6]
Internet Draft PPP-CN September 2003
Case 1: TE does not initiate authentication and the 3G node does not
require authentication.
+------+ +-------+
| TE | |3G Node|
+------+ +-------+
| LCP-Req + |
| IPCP-Req + |
| Standard LCP-Req |
|------------------------------>|
| LCP-Req-Ack + |
| IPCP (IP address) |
|<------------------------------|
| First IP packet |
|------------------------------>|
| |
Case 2: TE does not initiate authentication, but the 3G node requires
the use of PAP authentication
+------+ +-------+
| TE | |3G Node|
+------+ +-------+
| LCP-Req + |
| IPCP-Req + |
| Standard LCP-Req |
|------------------------------>|
| LCP-Req-Ack + |
| PAP-Required + |
| IPCP (IP address) |
|<------------------------------|
| PAP-UserID/Password + |
| First IP packet |
|------------------------------>|
| |
Purser expires March 2004 [Page 7]
Internet Draft PPP-CN September 2003
Case 3: TE initiates using PAP authentication, but the 3G node
requires the use of CHAP authentication
+------+ +-------+
| TE | |3G Node|
+------+ +-------+
| LCP-Req + |
| PAP-UserID/Password + |
| IPCP-Req + |
| Standard LCP-Req |
|------------------------------>|
| LCP-Req-Ack + |
| PAP-Nack + |
| CHAP-Challenge + |
| IPCP (IP address) |
|<------------------------------|
| CHAP-UserID/Password + |
| First IP packet |
|------------------------------>|
| |
4. Security Considerations
Security considerations are not discussed in this memo. However,
since the aim of this protocol is merely to reduce PPP negotiation
time by allowing the distinct negotiation phases to happen concur-
rently instead of in a serial fashion, there should not be any addi-
tional security risks introduced which are not already present in
[PPP].
5. Acknowledgements
The author wishes to acknowledge Reiner Ludwig and Martin Gerdes, the
original authors of this solution as presented in [QPPP].
6. Author's Addresses
Kevin Purser
8400 Decarie Blvd.
Town of Mount Royal, Quebec
H4P 2N2
CANADA
Phone: +1-514-345-7900
Email: [email protected]
7. References
Purser expires March 2004 [Page 8]
Internet Draft PPP-CN September 2003
[PPP] W. Simpson (editor), "The Point-to-Point Protocol (PPP)",
RFC1661, July 1994
[IPCP] G. McGregor, "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992
[PPPAuth] B. Lloyd, W. Simpson, "PPP Authentication Protocols", RFC
1334, October 1992
[Num] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1340, July
1992
[QPPP] R. Ludwig, B. Rathonyi, "Link Layer Enhancements for
TCP/IP over GSM", In Proceedings of IEEE INFOCOM, March
1999
Purser expires March 2004 [Page 9]
Internet Draft PPP-CN September 2003
[1mTable of Contents[0m
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Description . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Purser expires March 2004 [Page 1]