[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
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
                     <draft-ietf-pppext-scm-01.txt>


Status of this Memo

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``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]