rfc2363.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 676 行 · 第 1/2 页

Network Working Group                                           G. Gross
Request for Comments: 2363                           Lucent Technologies
Category: Standards Track                                      M. Kaycee
                                                                Paradyne
                                                                   A. Li
                                                         Shasta Networks
                                                                A. Malis
                                                   Ascend Communications
                                                             J. Stephens
                                                          Cayman Systems
                                                               July 1998


                             PPP Over FUNI

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

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

   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.







Gross, et. al.              Standards Track                     [Page 1]

RFC 2363                     PPP Over FUNI                     July 1998


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. Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [10].

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.








Gross, et. al.              Standards Track                     [Page 2]

RFC 2363                     PPP Over FUNI                     July 1998


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.

   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 RFC 1973 end point.

5. Virtual Circuit Multiplexed PPP Over FUNI

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



Gross, et. al.              Standards Track                     [Page 3]

RFC 2363                     PPP Over FUNI                     July 1998


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

   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:






Gross, et. al.              Standards Track                     [Page 4]

RFC 2363                     PPP Over FUNI                     July 1998


        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.

                  +-------------------------+ --------
                  |  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.





Gross, et. al.              Standards Track                     [Page 5]

RFC 2363                     PPP Over FUNI                     July 1998


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.

        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.




Gross, et. al.              Standards Track                     [Page 6]