[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 01 02 03 04 05 RFC 2363

PPP Extensions Working Group           George Gross, Lucent Technologies
INTERNET DRAFT                                     Manu Kaycee, Paradyne
Expires October 5, 1998                      Arthur Lin, Shasta Networks
                                     Andrew Malis, Ascend Communications
                                           John Stephens, Cayman Systems
                                                         April 5th, 1998


                             PPP Over FUNI

                    <draft-ietf-pppext-funi-05.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 view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (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 describes the use of ATM Frame User Network Interface
     (FUNI)  for framing PPP encapsulated packets.

Applicability


Gross, Kaycee, et al    Expires October 5th 1998        [Page 1]

Internet Draft             PPP Over ATM FUNI              April 5th 1998


This specification is intended for those implementations which desire to
use the facilities which are defined for PPP, such as the Link Control
Protocol, Network-layer Control Protocols, authentication, and
compression.  These capabilities require a point-to-point relationship
between the peers, and are not designed for the multi-point
relationships which are available in ATM and other multi-access
environments.

1. Introduction

ATM FUNI protocol is designed to provide virtual connections between end
stations attached to the same network.  These connections offer a packet
delivery service that includes error detection, but does not do error
correction.

Most existing implementations of PPP use ISO 3309 HDLC as a basis for
their framing [3].

When an ATM network is configured with point-to-point connections, PPP
can use FUNI as a framing mechanism.

2. Specification of Requirements

In this document, several words are used to signify the requirements of
the specification.  These words are often capitalized.

     1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that
     the definition is an absolute requirement of the specification.

     2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
     definition is an absolute prohibition of the specification.

     3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
     there may exist valid reasons in particular circumstances to ignore
     a particular item, but the full implications must be understood and
     carefully weighed before choosing a different course.

     4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean
     that there may exist valid reasons in particular circumstances when
     the particular behavior is acceptable or even useful, but the full
     implications should be understood and the case carefully weighed
     before implementing any behavior described with this label.

     5. MAY   This word, or the adjective "OPTIONAL", mean that an item
     is truly optional.  One vendor may choose to include the item
     because a particular marketplace requires it or because the vendor
     feels that it enhances the product while another vendor may omit
     the same item.  An implementation which does not include a


Gross, Kaycee, et al    Expires October 5th 1998        [Page 2]

Internet Draft             PPP Over ATM FUNI              April 5th 1998


     particular option MUST be prepared to interoperate with another
     implementation which does include the option, though perhaps with
     reduced functionality. In the same vein an implementation which
     does include a particular option MUST be prepared to interoperate
     with another implementation which does not include the option
     (except, of course, for the feature the option provides.)

3. FUNI Layer Service Interface

The PPP layer treats the underlying ATM FUNI layer service as a bit-
synchronous point-to-point link.  In this context, the PPP link
corresponds to an ATM FUNI virtual connection.  The virtual connection
MUST be full-duplex, point to point, and it MAY be either dedicated
(i.e. permanent, set up by provisioning) or switched (set up on demand).
In addition, the PPP/FUNI service interface boundary MUST meet the
following requirements:

     Interface Format - The PPP/FUNI layer boundary presents an octet
     service interface to the FUNI layer.  There is no provision for
     sub-octets to be supplied or accepted.

     Transmission Rate - The PPP layer does not impose any restrictions
     regarding transmission rate or the underlying ATM layer traffic
     descriptor parameters.

     Control Signals - The FUNI layer must provide control signals to
     the PPP layer which indicate when the virtual connection link has
     become connected or disconnected.  These provide the "Up" and
     "Down" events to the LCP state machine [1] within the PPP layer.

4. Multi-Protocol Encapsulation

This specification uses the principles, terminology, and frame structure
described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
[4].

The purpose of this specification is not to document what is already
standardized in [4], but to specify how the mechanisms described in [4]
are to be used to map PPP onto a FUNI-based  ATM network.  Section 1
within [4] defines the two mechanisms for identifying the Protocol Data
Unit (PDU) payload field's protocol type: virtual circuit based
multiplexing, and Logical Link Control (LLC) encapsulation.  In the
former technique, the payload's protocol type is implicitly agreed to by
the end points for each virtual circuit using provisioning or control
plane procedures.  When using the LLC encapsulation technique, the
payload's protocol type is explicitly identified on a per PDU basis by
an in-band LLC header, followed by the payload data.



Gross, Kaycee, et al    Expires October 5th 1998        [Page 3]

Internet Draft             PPP Over ATM FUNI              April 5th 1998


When transporting a PPP payload over FUNI, an implementation:

     1. MUST support virtual circuit multiplexed PPP payloads as
     described in section 5 below by mutual configuration or negotiation
     of both end points.  This technique is referred to as "VC-
     multiplexed PPP".

     2. MUST support LLC encapsulated PPP payloads on PVCs as described
     in section 6 below by mutual configuration or negotiation of both
     end points.  This technique is referred to as "LLC encapsulated
     PPP".

     3. For SVC set up, an implementation MUST negotiate using the
     Q.2931 [9] Annex C procedure, encoding the Broadband Lower Layer
     Interface (B-LLI) information element to signal either VC-
     multiplexed PPP or LLC encapsulated PPP.  The details of this
     control plane procedure are described in section 7.

If an implementation is connecting through a Frame Relay/ATM FRF.8 [7]
service inter-working unit to an RFC 1973 [6] end point, then it MUST
use LLC encapsulated PPP payloads.  Frame Relay/ATM FRF.8 inter-working
units are exempted from the requirement to support VC-multiplexed PPP.
This exemption allows the FR/ATM IWU to remain compliant with FRF.8 when
the PPP over FUNI end point is inter-operating with an RFC1973 end
point.

5. Virtual Circuit Multiplexed PPP Over FUNI


The FUNI protocol data unit (PDU) format [2] is as follows:

                   +-------------------------------+
                   |              Flag             |
                   +-------------------------------+---------
                   |           FUNI Header         |    ^
                   +-------------------------------+    |
                   |                               |    |
                   |                               |    |
                   |            User SDU           | FUNI PDU
                   |                               |    |
                   |                               |    |
                   +-------------------------------+    |
                   |   FUNI FCS (2 or 4 octets)    |    v
                   +-------------------------------+---------
                   |              Flag             |
                   +-------------------------------+
                                Figure 1



Gross, Kaycee, et al    Expires October 5th 1998        [Page 4]

Internet Draft             PPP Over ATM FUNI              April 5th 1998


The FUNI Header includes a 10-bit or 24-bit Frame Address (a.k.a.
VPI/VCI bits), a Congestion Notification bit, a Congestion Loss Priority
bit, and four Reserved bits.

The User SDU field contains user information up to 4096 (optionally up
to 64K) octets.

The FCS field protects the entire FUNI PDU except for the FCS field
itself.

A VC-multiplexed PPP frame SHALL constitute the User Service Data Unit
(SDU) field and is defined as shown in figure 2:
               +-------------+-------------+---------+
               | Protocol ID | Information | Padding |
               |  8/16 bits  |             |         |
               +-------------+-------------+---------+
                                Figure 2

Each of these fields are specifically defined in [1].

6. LLC Encapsulated PPP Over FUNI

LLC encapsulated PPP over FUNI is the alternative technique to VC-
multiplexed PPP over FUNI.

The FUNI SDU payload  field is encoded as shown in figure 3.  The
pertinent fields in that diagram are:

     1. LLC header: 2 bytes encoded to specify a source SAP and
     destination SAP of routed OSI PDU (values 0xFE 0xFE), followed by
     an Un-numbered Information (UI) frame type (value 0x03).

     2. Network Layer Protocol IDentifier (NLPID) representing PPP,
     (value 0xCF).

     3. the PPP protocol identifier field, which can be either 1 or 2
     octets long.  See reference [1].

     4. followed by the PPP information field as per Figure 2.











Gross, Kaycee, et al    Expires October 5th 1998        [Page 5]

Internet Draft             PPP Over ATM FUNI              April 5th 1998


          +-------------------------+ --------
          |  Destination SAP (0xFE) |     ^
          +-------------------------+     |
          |  Source SAP (0xFE)      | LLC header
          +-------------------------+     |
          |  Frame Type = UI (0x03) |     V
          +-------------------------+ --------
          |  NLPID = PPP (0xCF)     |
          +-------------------------+ --------
          |   Protocol Identifier   |     ^
          |     (8 or 16 bits)      |     |
          +-------------------------+ PPP payload
          |          .              |     |
          |          .              |     |
          |  PPP information field  |     |
          |          .              |     |
          |          .              |     |
          +-------------------------+     |
          |        padding          |     V
          +-------------------------+ --------
          | FUNI FCS (2 or 4 octets)| FUNI trailer
          +-------------------------+---------


                                Figure 3

The end points MAY be bi-laterally provisioned to send other LLC-
encapsulated protocols besides PPP across the same virtual connection.
However, they MUST NOT send packets belonging to any protocol that has
an active NCP within the PPP session.  Implementations SHOULD do packet
scheduling that minimizes the performance impact on the quality of
service commitments associated with both the LLC-encapsulated PPP and
non-PPP protocol flows.

7. Out-Of-Band Control Plane Signaling

When originating a switched virtual circuit FUNI connection, the caller
MUST request in the SETUP message either VC-multiplexed PPP, LLC-
encapsulated PPP, or else both VC-multiplexed and LLC-encapsulated PPP.
When a caller is offering both techniques, the two B-LLI IEs are encoded
within a Broadband Repeat Indicator IE in the order of their preference.
The called implementation MUST be able to accept an incoming call that
offers LLC-encapsulated PPP in the caller's request.  The called
implementation MUST reject a call set up request that only offers an
encapsulation that it does not support.  Implementations originating a
call offering both protocol encapsulation techniques MUST be able to
negotiate the use of LLC-encapsulated PPP.



Gross, Kaycee, et al    Expires October 5th 1998        [Page 6]

Internet Draft             PPP Over ATM FUNI              April 5th 1998


When originating a virtual circuit multiplexed call that is to carry a
PPP payload, the ITU Q.2931 [9] B-LLI element user information layer 3
protocol field is encoded to select ISO/IEC TR 9577 [5] in octet 7.  The
extension octets specify an IPI value of PPP (0xCF).  By definition, the
first bytes of the FUNI frame's payload field will always contain a PPP
header followed by a packet.

When originating an LLC encapsulated call that is to carry a PPP
payload, the ITU Q.2931 B-LLI element user information layer 2 protocol
field is encoded to select LAN Logical Link Control (ISO/IEC8802-2) in
octet 6.  See RFC 1755 [8] appendix A for an example.  By definition,
the first bytes of the FUNI frame's payload field will contain an LLC
header, followed by a NLPID and the PPP payload.

8. Detection And Recovery From Unsolicited PPP Encapsulation Transitions

When the virtual connection loses state, the PPP encapsulation technique
may uni-laterally and unexpectedly change across such transitions.
Detection and recovery procedures are defined for the following state
transitions:

     VC-multiplexed PPP changing to LLC encapsulated PPP

     LLC encapsulated PPP changing to VC-multiplexed PPP

When LLC-encapsulated PPP is being used, the inital 6 octets of the LCP
packets contain the sequence: fe-fe-03-cf-c0-21.  This sequence
constitutes the first 6 octets of the FUNI frame.  In the case of VC-
multiplexed PPP, initial LCP packets contain the sequence c0-21.

In the case of FUNI, this sequence follows the FUNI Header.   When a LCP
Configure-Request packet is received and recognized, the PPP link enters
Link Establishment phase.

Once PPP has entered the Network-layer Protocol phase, and successfully
negotiated a particular NCP for a PPP Protocol, if a frame arrives using
an alternate but equivalent data encapsulation as defined in [4], then
the PPP Link MUST:

     For a SVC, immediately clear the call with the cause value 111,
     "protocol error, unspecified".

     For a PVC: tear down the active NCPs, SHOULD generate an error
     message, enter the Termination state, and silently drop all
     received packets.

These policies prevent "black-holes" that occur when the peer loses
state.  An implementation which requires PPP link configuration, and


Gross, Kaycee, et al    Expires October 5th 1998        [Page 7]

Internet Draft             PPP Over ATM FUNI              April 5th 1998


other PPP negotiated features (such as authentication), MAY enter
Termination state when configuration fails.

9. LCP Configuration Options

The Magic Number LCP configuration option is recommended, and the
Protocol Field Compression (PFC) option is not recommended.  An
implementation MUST NOT request any of the following options, and MUST
reject a request for such an option:

     Field Check Sequence (FCS) Alternatives,

     Address-and-Control-Field-Compression (ACFC),

     Asynchronous-Control-Character-Map (ACCM)

The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger
size than the maximum CPCS-SDU size specified in the associated
direction for the virtual connection's traffic contract.

When viewed peer to peer, a PPP link may be bridged over multiple
physical layer sections.  For each such FUNI section, the LCP framing
options MUST be actively negotiated by the bridging convertors
independently of the LCP framing options in use by other physical layer
sections.

Implementation Note:
     When an ATM FUNI PVC is in the "Stopped" state, it is recommended
     that the implementation wait for Configure-Requests.  See the
     implementation option in reference [1] section 4.2, the "Stopped
     State" sub-section.

10. Security Considerations

Generally, ATM networks are virtual circuit based, and security is
implicit in the public data networking service provider's administration
of Permanent Virtual Circuits (PVCs) between the network boundaries.
The probability of a security breach caused by mis-routed ATM cells is
considered to be negligible.

When a public ATM network supports Switched Virtual Circuits, the
protocol model becomes analogous to traditional voice band modem dial up
over the Public Telephone Switched Network (PTSN).  The same PAP/CHAP
authentication protocols that are already widely in use for Internet
dial up access are leveraged.  As a consequence, PPP over FUNI security
is at parity with those practices already established by the existing
Internet infrastructure.



Gross, Kaycee, et al    Expires October 5th 1998        [Page 8]

Internet Draft             PPP Over ATM FUNI              April 5th 1998


Those applications that require stronger security are encouraged to use
authentication headers, or encrypted payloads, and/or ATM-layer security
services.

When using LLC-encapsulated PPP over a virtual connection, an end point
can not assume that the PPP session authentication and related security
mechanisms also secure the other LLC encapsulated flows on that same
virtual connection.

11. Acknowledgments

This design is based on work performed in ADSL Forum's Packet Mode
Working Group.  It is inspired by  "PPP in Frame Relay", RFC 1973, by
William Simpson.  Special thanks to Phil Rakity of Flowpoint, Tim Kwok
of Microsoft, and David Allan of Nortel for their constructive review
and commentary.

12. References


[1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
      51, RFC 1661, July 1994.

[2]   The ATM Forum, "Frame based User-to-Network Interface (FUNI)
      Specification v2", af-saa-0088.000, May 1997.

[3]   Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51,
      RFC 1662, July 1994.

[4]   Heinanen, J., "Multiprotocol Interconnect over AAL5",
      RFC 1483, July 1993.

[5]   ISO/IEC DTR 9577.2, "Information technology -
      Telecommunications and Information exchange between systems -
      Protocol Identification in the network layer", 1995-08-16.

[6]   Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.

[7]   The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-working
      Implementation Agreement", FRF.8, April 1995.

[8]   M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis,
      "ATM Signaling Support for IP over ATM", RFC 1755, February 1995.

[9]   International Telecommunication Union, "Broadband Integrated Service
      Digital Network (B-ISDN) Digital Subscriber Signaling System No.2
      (DSS2) User Network Interface Layer 3 Specification for Basic
      Call/Connection Control", ITU-T Recommendation Q.2931, (International


Gross, Kaycee, et al    Expires October 5th 1998        [Page 9]

Internet Draft             PPP Over ATM FUNI              April 5th 1998


      Telecommunication Union: Geneva, 2/95)


Chair's Address The working group can be contacted via the current
chair:
           Karl Fox
           Ascend Communications
           3518 Riverside Drive, Suite 101
           Columbus, Ohio 43221

           EMail: karl@ascend.com


Author's Address

Questions about this memo can also be directed to:

     George Gross
     Lucent Technologies, Inc
     184 Liberty Corner Road
     Warren, NJ 07059
     Tel:   +1.908.580.4589
     Email: gmgross@lucent.com

     Manu Kaycee
     Paradyne Corporation
     21 Bear Meadow Road
     Londonderry, NH 03053-2168
     Tel: +1.603.434.6088
     Email: mjk@nj.paradyne.com

     Arthur Lin
     Shasta Networks Inc.
     249 Humboldt Court
     Sunnyvale, CA 94089-1300
     Tel:   +1.408.747.5051
     Email: alin@shastanets.com

     Andrew Malis
     Ascend Communications, Inc.
     1 Robbins Road
     Westford, MA 01886
     Tel:  +1.978.952.7414
     Email: malis@ascend.com

     John Stephens
     Cayman Systems, Inc.
     100 Maple Street


Gross, Kaycee, et al    Expires October 5th 1998       [Page 10]

Internet Draft             PPP Over ATM FUNI              April 5th 1998


     Stoneham, MA 02180
     Tel:   +1.617.279.1101
     Email: john@cayman.com















































Gross, Kaycee, et al    Expires October 5th 1998       [Page 11]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/