Point-to-Point Protocol Extension Group Mikael Latvala INTERNET DRAFT Oy L M Ericsson Ab Expires May, 1999 November, 1998 Semi Connected Mode for PPP links Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document introduces a new PPP feature called Semi Connected Mode. When both sides of a point-to-point link agree to use Semi Con- nected Mode, either side can transparently disconnect and re- establish a circuit-switched connection without having to reconfigure the point-to-point link each time. Latvala expires May 23, 1999 [Page 1] Internet Draft Semi Connected Mode for PPP links November 23, 1998 Table of Contents 1. Introduction .......................................... 3 1.1 Specification of Requirements ................... 5 1.2 Terminology ..................................... 5 2. Operation ............................................. 7 2.1 SCM negotiation ....................................... 7 2.2 Terminating and re-establishing a physical link ....... 8 3. LCP Configuration Option for SCM ...................... 10 4. Implementation Requirements ........................... 11 4.1 Remote hosts .................................... 11 4.2 Network Access Servers .......................... 11 4.2 Roaming hosts ................................... 13 5. Timers ................................................ 15 6. Security Considerations ............................... 16 REFERENCES ................................................... 16 CONTACTS ..................................................... 17 Appendix A: LCP Translation Table ............................ 18 Latvala expires May 23, 1999 [Page 2] Internet Draft Semi Connected Mode for PPP links November 23, 1998 1. Introduction General Switched Telephone Networks (GSTN) are not well suited for bursty data traffic because the end user is charged for the duration of a circuit-switched connection even though he utilizes the connection only for a fraction of the total connection length. The current practice among the GSTN customers using circuit-switched data services is to disconnect the link manually when there is no data to send or to receive. This is feasible as long as the user does not need to disconnect and reconnect the link too often and knows when he wants to receive or send data, e.g. when one is reading or sending email. But when the traffic pattern is more unpredictable this becomes quite a tedious or even impossible task, e.g. when one surfs the web or unexpectedly receives a VoIP call request. In addition, some GSTNs, i.e. cellular networks, suffer from long end- to-end delays so that disconnection/reconnection of a physical link is no longer transparent to the user. Therefore it would be convenient if there were a mechanism which would automatically drop a circuit-switched connection if it had been idle for a pre-defined amount of time and re-establish it without having to go through the PPP configuration process when there is data to send or receive. The concept of dropping the connection without informing the data link layer was introduced in RFC1662 [3]. RFC1662 says that the implementation may "choose to disconnect the physical layer during periods of inactivity". This approach, however, has three problems: 1. Currently there is no mechanism to identify a PPP session. It is crucial that in cases where CLID information is not available, implementations can associate a re-established circuit-switched connection with the existing PPP session. PPP Session-Identifier is described in [10]. 2. The PPP implementation cannot advise the peer what the peer should do in case it receives a packet(s) destined for the host in which the implementation is running. Many remote host users insist that they have a final say in whether or not the peer (usually Network Access Server, NAS) can re- establish the physical link. 3. The implementation cannot know whether or not the peer supports the functionality of disconnecting a circuit- switched connection without terminating the PPP session. The only way to deduce this is to probe the peer by sending it a network-layer packet. If the peer does not support this functionality it discards the packet and initiates the PPP link configuration. The discarded packet and the unexpected Latvala expires May 23, 1999 [Page 3] Internet Draft Semi Connected Mode for PPP links November 23, 1998 delay caused by the link configuration have a negative impact on TCP performance, e.g. on short HTTP transactions. This is especially harmful when the implementation attempts to use the circuit-switched connection in a packet-switched manner. To fix these problems and to give this concept a more formal standing among other PPP features this document introduces a new PPP feature called Semi Connected Mode (SCM). When properly configured, SCM allows PPP to re-establish a physical link without having to go through the PPP configuration process thus reducing the data connection setup time. This document introduces a PPP option which allows the implementation to find out whether or not NAS supports the SCM feature and to inform the peer of its ability to accept mobile terminated calls. Latvala expires May 23, 1999 [Page 4] Internet Draft Semi Connected Mode for PPP links November 23, 1998 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 1.2. Terminology datagram The unit of transmission in the network layer (such as IP). A datagram may be encapsulated in one or more packets passed to the data link layer. frame The unit of transmission at the data link layer. A frame may include a header and/or a trailer, along with some number of units of data. packet The basic unit of encapsulation, which is passed across the interface between the network layer and the data link layer. A packet is usually mapped to a frame; the exceptions are when data link layer fragmentation is being performed, or when multiple packets are incorporated into a single frame. peer The other end of the point-to-point link. NAS A device which is used to terminate dial-up access to a network. CLID Calling Line ID, an indication to the receiver of a call as to the phone number of the caller. Latvala expires May 23, 1999 [Page 5] Internet Draft Semi Connected Mode for PPP links November 23, 1998 PPP session A PPP session is a time interval during which the options negotiated by the Link Control Protocol remain unchanged. The session starts when the LCP reaches the Open state and is concluded by the LCP Terminate- Request packet sent by either end of the point-to-point link. Latvala expires May 23, 1999 [Page 6] Internet Draft Semi Connected Mode for PPP links November 23, 1998 2. Operation Semi Connected Mode is a new feature in PPP which allows PPP implementations to terminate and re-establish a physical link without having to reconfigure the point-to-point link. This chapter explains how SCM is negotiated and used. Appendix A describes a modified LCP state transition table for reference. Nota Bene: PPP is inherently a symmetrical protocol, i.e. it does not differentiate between the hosts on either end of the point-to- point link. This allows both uplink and downlink to be configured independently of each other. This chapter presents the operation of SCM bearing in mind the symmetrical nature of PPP. However, the way SCM is implemented makes a clear distinction between PPP implementations running on a remote host (client) and on a NAS (server) because customers using dial-up services want to fully control if and when the circuit-switched connection is dropped, and whether or not the server is allowed to re-establish the circuit-switched connection. Furthermore, only NASs should assign PPP Session-Identifier for point-to-point links because remote hosts lack the necessary information to guarantee the uniqueness of a PPP Session-Identifier within the access network. Chapter 5 explains how the SCM implementation differs between remote hosts and NASs. 2.1 SCM negotiation The use of SCM is negotiated during the link establishment phase. The implementation includes the SCM option in a Configure-Request packet thus indicating to the peer its willingness to use SCM. When the peer receives a Configure-Request packet which has the SCM option it can respond to it in three different ways: 1. If the peer has implemented the SCM feature, is ready to use it, and has accepted the Remote-Term field value it MUST include the SCM option in a Configure-Ack. 2. If the peer supports the SCM feature, but the implementation indicated to the peer that it is ready to accept remote host terminating calls (Remote-Term field) when the peer is actually not able or willing to initiate a call setup procedure, the peer MUST send a Configure-Nak and include the unmodified SCM option in the packet. Latvala expires May 23, 1999 [Page 7] Internet Draft Semi Connected Mode for PPP links November 23, 1998 3. If the peer does not support the SCM feature it MUST send a Configure-Reject and include the unmodified SCM option in the packet. Both sides of a point-to-point link must also agree on a PPP Session-Identifier so that the side which accepts a newly re- established physical link (i.e. callee) can associate the physical link with one of the existing PPP sessions. The side of a point-to-point link which can guarantee that the chosen value of a Session-Identifier is always unique within the access network MUST include the Session-Identifier option in a Configure- Request packet (see chapter 5). 2.2 Terminating and re-establishing a physical link After having agreed to use SCM and the PPP link has been properly configured (including PPP Session-Identifier) both sides can start sending and receiving network layer packets. If the link has remained idle more than the allowed number of seconds (Idle timer) the implementation MUST terminate the physical link without signaling the Down event. When the peer notices that the implementation has terminated the physical link it MUST mark the time of the event. Later on it uses this value to determine if that link has been idle more than the allowed time. The peer MUST remove all the PPP sessions from the database which uses SCM and whose physical link has been down more than the time specified by the Expiration timer. When the physical link is down and the implementation receives a packet from the network layer it MUST: 1. re-establish the circuit-switched connection. If the implementation cannot re-establish the physical link immediately (e.g. received a busy signal) it SHOULD try to re-establish the link "a few times" before signaling the Down event and discarding the network packet. 2. send a LCP Identification packet [9] which carries the value of the Session-Identifier negotiated during the link establishment phase to the peer so that the peer can associate the physical link with the right PPP session. 3. and finally, start sending network layer packets to the peer. If the implementation receives a Configure-Request from the peer after re-establishing the physical link (e.g. database holding the current PPP session information was Latvala expires May 23, 1999 [Page 8] Internet Draft Semi Connected Mode for PPP links November 23, 1998 destroyed or the PPP session entry expired) it MUST re- configure the PPP link according to [1]. Latvala expires May 23, 1999 [Page 9] Internet Draft Semi Connected Mode for PPP links November 23, 1998 3. LCP Configuration Option for SCM Description The LCP configuration option for SCM allows the remote host and the NAS implementations to negotiate whether SCM is used. By default SCM is disabled. Only the remote host implementation can include the SCM option in Configure-Request packets. The remote host implementation indicates in the Remote-Term field if it accepts remote host terminating calls. A summary of the SCM Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Remote-Term | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 3 Remote-Term The Remote-Term field is one octet and indicates whether the implementation accepts call setup requests (terminating call). If the implementation does not accept remote host terminating calls the peer SHOULD drop all the packets destined to the remote host when the physical link between the remote host and NAS is down. Acceptable values of the Remote-Term field are: 0 The remote host does not accept call setup requests. 1 The remote host accepts call setup requests. Latvala expires May 23, 1999 [Page 10] Internet Draft Semi Connected Mode for PPP links November 23, 1998 4. Implementation Requirements 4.1 Remote hosts The remote host implementation SHOULD include the SCM option in a Configure-Request packet. In case the remote host implementation receives a SCM option in a Configure-Request packet from the peer it SHOULD Configure-Nak it. The remote host implementation MUST have an Idle timer which determines how long the physical link can be idle before it is terminated. The implementation SHOULD offer the end user the option of configuring the Idle timer value so that the end user can find a value which satisfies his needs. The remote host implementation MUST ack the Session-Identifier option it receives from NAS. After having re-established the physical link the remote host implementation MUST first sent a LCP Identification packet [9] which has the value of the Session-Identifier in the Message field before it can send network layer packets to the peer. The remote host implementation MUST include a mechanism so that the end user can decide whether or not he wants to accept the call request. This can be done beforehand by listing CLIDs where calls can be originated or by prompting the end user to accept a call each time the physical layer receives a call request. An implementation whose physical layer cannot provide CLID information, or does not trust a carrier-provided CLID SHOULD request the peer to authenticate itself (see chapter 6. Security Considerations). SCM is valid only for the duration of a PPP session. When restarted after an unexpected crash or shutdown, the implementation MUST always start a new PPP session. The implementation MUST also start a new PPP session after failing to terminate the old session. To avoid NAS from having stale PPP session entries in its database the remote host implementation SHOULD terminate the PPP session properly before the end user logs off or brings the host down. 4.2 Network Access Server The NAS implementation SHOULD NOT include the SCM option in a Configure-Request. The NAS implementation MUST respond to the SCM option it receives from the remote host as explained in chapter Latvala expires May 23, 1999 [Page 11] Internet Draft Semi Connected Mode for PPP links November 23, 1998 2. Furthermore, it MUST NOT disconnect the physical link. Rather, it observes the status of the physical link and acts accordingly when the remote host disconnects the link. The NAS implementation MUST include a Session-Identifier option in a Configure-Request packet. The remote-host must accept the Session-Identifier before SCM can be used. If NAS receives a Configure-Request packet which contains a Session-Identifier option it SHOULD ack the Session-Identifier option but not use the value specified by the option to identify the point-to-point link. NAS MUST guarantee that the value of a Session-Identifier option it sends to the remote host is unique within the access network. The NAS implementation MUST re-establish the physical link when it receives a packet destined to the remote host and if the remote host told NAS that it can accept remote host terminated calls. If NAS fails to re-establish the physical link after a number of unsuccessful attempts it MUST remove the PPP session entry from the database. When a physical link belonging to a PPP session is re-established NAS must initialize the field in the PPP session entry which marks the time when the physical link was last terminated. NAS implementations MUST have a database in which they store the current PPP sessions. Session-Identifier [10] SHOULD be used as the key for the database. After having detected that the remote host has terminated the physical link, NAS implementations MUST start the Expiration timer. NAS implementations use this timer to periodically check for PPP sessions whose physical links have been down longer than the allowed time. Implementations MUST remove all the entries which do not satisfy this requirement. In order to differentiate physical links which are up from links that have been terminated, NAS SHOULD allocate a unique value for the timer which indicates that a link is up. NAS implementation SHOULD assign this value to the Expiration timer when NAS creates a new PPP session entry. NAS implementations must be able to cope with the modem hunt- group problem. It is possible that NAS has more than one entity between which the control of PPP sessions and the associated physical links is distributed. NAS MUST guarantee that the entity, which has a PPP session entry in its database when the remote host terminates the physical link of the PPP session, either: 1. regains the control of the physical link belonging to that PPP session when the link is re-established, or Latvala expires May 23, 1999 [Page 12] Internet Draft Semi Connected Mode for PPP links November 23, 1998 1. alternatively, transfers the PPP session entry to another entity which now controls the physical link between the remote host and the NAS entity, or deletes the PPP session entry thus forcing the reconfiguration of the PPP link. It is beyond the scope this document to discuss these solutions in greater detail. NAS implementations MAY inform ISP of the time durations when the physical link was up so that the remote user is not charged for the times when the link was down. If ISP honors this information NAS SHOULD pass it to the RADIUS server at the end of the RADIUS accounting service [5] delivery. When the NAS implementation receives a Terminate-Request from the remote host it MUST remove the PPP session entry from the database. Implementation Note: L2TP tunnel between NAS (=LAC) and Authenticator Server (AS, see picture in chapter 4.3) might cause problems when SCM option is negotiated. Because LAC may have negotiated LCP with the remote host without LNS being involved in the negotiation, LCP must send LCP CONFREQs to LNS for its approval. If LNS refuses to accept LCP CONFREQs and wants to renegotiate LCP, it is possible that during the second round of negotiation LNS does not accept SCM option because SCM has not been implemented in it. To be able to use SCM even though LNS does not support this feature, LAC implementers/administrators should make sure that LCP CONFREQs LAC sends to LNS are accepted by LNS. This means that LAC MUST remove at least the SCM option from CONFREQs it sends to LNS. If LNS accepts LAC's LCP CONFREQs SCM can be used because both LAC and the remote host agreed to use it. 4.3 Roaming hosts Some remote hosts may be so-called mobile hosts which can roam to a new area served by another NAS (NAS2). Roaming can be a problem if the SCM is in use (the physical link has been temporarily terminated) and the remote host has roamed to a new area without terminating the PPP session with old NAS (NAS1). In many cases the Authenticator Server (AS) does allow end users to have more than one active PPP session at any given time. If Latvala expires May 23, 1999 [Page 13] Internet Draft Semi Connected Mode for PPP links November 23, 1998 the new location is serviced by a new NAS (NAS2) it is possible that NAS2 cannot grant access to the remote host because AS refused to authenticate the remote host due to the existing PPP session. E.g. some RADIUS servers [4] do not allow end users to have more than one open PPP session at any given time. This scenario can also take place in access networks where there is a L2TP tunnel between NAS and AS (NAS = LAC, AS = LNS). +----+ +------+ | RH | ----------- | NAS1 | ---------+ +----+ +------+ | | | | +-- +----+ | roaming | AS | | +-- +----+ V | +----+ +------+ | | RH | ----------- | NAS2 | ---------+ +----+ +------+ RH = remote host AS = Authenticator server (RADIUS server, L2TP Network Server) NAS = Network access server To prevent this scenario from happening, NAS implementations should be able to inquire what PPP sessions other NASs have and, if needed, ask another NAS to release the PPP session information, or to terminate the PPP session when the remote host roams to a new location. It is beyond the scope of this document to discuss these solutions in greater detail. Latvala expires May 23, 1999 [Page 14] Internet Draft Semi Connected Mode for PPP links November 23, 1998 5. Timers Idle timer The Idle timer tells the remote host implementation how many seconds a physical link can be idle before it is terminated. The end user SHOULD be able to adjust the timer according to his preference. Remote host implementations SHOULD impose a lower boundary for the Idle timer. Considering that the most of the traffic flows use TCP the lower boundary SHOULD not be less than RTO preventing the physical link from being terminated while the remote host is waiting for an acknowledgement. However, because the value of RTO varies in time based on the state of a link(s) the only recommendation that can be given is that the value of the Idle timer SHOULD be no less than 3 sec which [6] is specified as an initial RTO value. Remote host implementations can either expect the end user to play with the Idle timer value, or implement a mechanism which mirrors the current values of RTOs and assigns the lowest of them to the Idle timer. Expiration timer The Expiration timer determines how long the physical link can be down without NAS removing the PPP session entry from its database. The value of this timer should be high enough to make circuit-switched data service resemble packet-switched data service. Latvala expires May 23, 1999 [Page 15] Internet Draft Semi Connected Mode for PPP links November 23, 1998 6. Security Considerations One way to provide security in SCM is to rely on CLID, which can be used to authenticate the peer, or on a PPP Session-Identifier. It is, however, possible that GSTN and/or hardware cannot provide CLID, or that the implementation desires a stronger authentication mechanism, e.g. CHAP [7] or some mechanism used by EAP [8]. In these cases the authenticator MUST be able to request the peer to authenticate itself immediately after the physical link has been re-established. Implementation Note: It is left up to the implementation to decide what to do with network packets which the implementation receives before the peer has authenticated itself. To make the disconnection/reconnection of the physical link as transparent as possible to the end user the implementation SHOULD accept the network layer packets within a certain time frame even though the peer has not yet authenticated itself. In case of NAS the implementation can either buffer the packets or forward them (preferred) while waiting for the authentication response from the peer. If the peer fails to authenticate itself the implementation MUST immediately close the connection, discard all the buffered packets and clear the peer's PPP session entry. REFERENCES [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point- to-Point Links," RFC 1661, July 1994. [2] Valencia, A. et al., "Layer Two Tunneling Protocol "L2TP"", draft-ietf-pppext-l2tp-09.txt, January 1998. [3] Simpson, W., Editor. "PPP in HDLC-like Framing", RFC 1662, July 1994. [4] C. Rigney, et. al., "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. [5] C. Rigney, "RADIUS accounting", RFC 2139, April 1997. [6] R. Braden, Editor, "Requirements for Internet Hosts -- Latvala expires May 23, 1999 [Page 16] Internet Draft Semi Connected Mode for PPP links November 23, 1998 Communication Layers", RFC 1122, October 1989. [7] W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [8] L. Blunk and J. Volbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [8] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994. [10] Latvala, M., "PPP Session-Identifier Option", "work in progress" draft-ietf-pppext-sessid-00.txt, November 1998. CONTACTS Questions about this paper can be directed to: Mikael Latvala Oy LM Ericsson Ab SF-02420 Jorvas, Finland E-Mail: mikael.latvala@ericsson.com Voice: +358 9 299 2850 GSM: +358 40 507 2555 Fax: +358 9 299 3247 Latvala expires May 23, 1999 [Page 17] Internet Draft Semi Connected Mode for PPP links November 23, 1998 Appendix A: LCP Translation Table The Semi-Connected phase SHOULD be implemented by adding one new state, Semi-Connected, six new events, and seven new actions to the LCP's state translation table. The new events can cause a legal transition only in the Request-Sent, Request-Ack, Opened or Semi-Connected state which is the reason why only those four states are shown in the table below. The new functionalities can be implemented without sacrificing the integrity of the "traditional" PPP implementation. Because of the asymmetrical nature of SCM small 'c' indicates events which are seen by the remote host (client) and small 's' events seen by NAS (server). Events Actions CSC = Close event, SCM configured, no peer rel = re-establish link DSC = Down event, SCM configured tel = terminate link IDT = Idle timer expired ssi = send session id ETE = Expiration timer expired dse = delete session entry DUP+ = Packet from the upper layer sit = start idle timer DUP- = Packet from the upper layer, no peer set = start expr timer iet = initialize expr timer | State | 7 8 9 10 Events| Ack-Rcvd Ack-Sent Opened Semi-Connected ------+--------------------------------------------------------------- Up-c | - - - sit/9 Up-s | - - - iet/9 Down | 1 1 tld/1 - Open | 7 8 9r - Close-c| irc,str/4 irc,str/4 tld,irc,str/4 rel,tld,irc,str/4 Close-s| irc,str/4 irc,str/4 tld,irc,str/4 rel,tld,irc,dse,str/4 | TO+ | scr/6 scr/8 - - TO- | tlf/3p tlf/3p - - | RCR+ | sit,sca,tlu/9 sca/8 tld,scr,sca/8 - RCR- | scn/7 scn/6 tld,scr,scn/6 - RCA | scr/6x sit,irc,tlu/9 tld,scr/6x - RCN | scr/6x irc,scr/8 tld,scr/6x - | RTR | sta/6 sta/6 tld,zrc,sta/5 - RTA | 6 8 tld,scr/6 - | RUC | scj/7 scj/8 scj/9 - Latvala expires May 23, 1999 [Page 18] Internet Draft Semi Connected Mode for PPP links November 23, 1998 RXJ+ | 6 8 9 - RXJ- | tlf/3 tlf/3 tld,irc,str/5 - | RXR | 7 8 ser/9 - | CSCc | - - - tld/1 CSCs | - - - tld,dse/1 DSCc | - - 10 - DSCs | - - set/10 - IDT | - - tel/10 - ETE | - - - tld,dse/1 DUP+c | - - - rel,ssi,sit/9 DUP+s | - - - rel,iet/9 DUP-c | - - - tld/1 DUP-s | - - - tld,dse/1 Events Close event when SCM configured (CSC) This event occurs when the automaton is in the Semi-Connected state, the network administrator (human or program) indicates that the link is not allowed to be Opened, and the implementation is not able to re-establish the physical link to properly terminate the point-to-point link. Down event when SCM configured (DSC) This event occurs when the PPP link is configured to use SCM, the automaton is in the Opened state, and a lower layer indicates that it is no longer ready to carry packets. Usually the event takes place when the remote host terminates the physical link because the point-to-point link has remained idle too long. Idle timer expired (IDT) This event occurs when the PPP link is configured to use SCM, the automaton is in the Opened state, and the Idle timer expires. Event noticed only by the remote host. Expiration timer expired (EXE) This event occurs when the PPP link is configured to use SCM, the automaton is in the Semi-Connected state, and the Expiration timer expires. Event noticed only by NAS. Datagram from the upper layer (DUP) Latvala expires May 23, 1999 [Page 19] Internet Draft Semi Connected Mode for PPP links November 23, 1998 This event occurs when the PPP link is configured to use SCM, the automaton is in the Semi-Connected state, and a upper layer has given a packet to PPP to transfer to the peer. The DUP+ event indicates that the peer is still available so that the physical link can be re-established and packets can be sent to the peer. The DUP- event indicates that the peer is not available and that the physical link cannot be re-established. Actions Re-establish link (rel) The physical link is re-established. Terminate link (tel) The physical link is terminated. Start expiration timer (set) This action prompts NAS to start the Expiration timer. Start idle timer (sit) This action prompts the remote host to start the Idle timer. Send session id (ssi) This action causes the implementation to send a LCP Identification packet to the peer. Initialize expiration timer (iet) This action causes NAS to initialize the Expiration timer to a value which indicates that the physical link is up. Latvala expires May 23, 1999 [Page 20]