As per Relevance of the word implementation, we have this rfc below:
Network Working Group G.
Request for Comments: 2363 Lucent
Category: Standards Track M.
A.
Shasta
A.
Ascend
J.
Cayman
July 1998
PPP Over
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
The Point-to-Point Protocol (PPP) [1] provides a standard method
transporting multi-protocol datagrams over point-to-point links
This document describes the use of ATM Frame User Network
(FUNI) for framing PPP encapsulated packets
This specification is intended for those implementations which
to use the facilities which are defined for PPP, such as the
Control Protocol, Network-layer Control Protocols, authentication
and compression. These capabilities require a point-to-
relationship between the peers, and are not designed for the multi
point relationships which are available in ATM and other multi-
environments
Gross, et. al. Standards Track [Page 1]
RFC 2363 PPP Over FUNI July 1998
1.
ATM FUNI protocol is designed to provide virtual connections
end stations attached to the same network. These connections offer
packet delivery service that includes error detection, but does
do error correction
Most existing implementations of PPP use ISO 3309 HDLC as a basis
their framing [3].
When an ATM network is configured with point-to-point connections
PPP can use FUNI as a framing mechanism
2.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
document, are to be interpreted as described in [10].
3. FUNI Layer Service
The PPP layer treats the underlying ATM FUNI layer service as a bit
synchronous point-to-point link. In this context, the PPP
corresponds to an ATM FUNI virtual connection. The
connection MUST be full-duplex, point to point, and it MAY be
dedicated (i.e. permanent, set up by provisioning) or switched (
up on demand). In addition, the PPP/FUNI service interface
MUST meet the following requirements
Interface Format - The PPP/FUNI layer boundary presents an
service interface to the FUNI layer. There is no provision
sub-octets to be supplied or accepted
Transmission Rate - The PPP layer does not impose
restrictions regarding transmission rate or the underlying
layer traffic descriptor parameters
Control Signals - The FUNI layer MUST provide control signals
the PPP layer which indicate when the virtual connection
has become connected or disconnected. These provide the "Up
"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
This specification uses the principles, terminology, and
structure described in "Multiprotocol Encapsulation over
Adaptation Layer 5" [4].
The purpose of this specification is not to document what is
standardized in [4], but to specify how the mechanisms described
[4] are to be used to map PPP onto a FUNI-based ATM network
Section 1 within [4] defines the two mechanisms for identifying
Protocol Data Unit (PDU) payload field's protocol type:
circuit based multiplexing, and Logical Link Control (LLC
encapsulation. In the former technique, the payload's protocol
is implicitly agreed to by the end points for each virtual
using provisioning or control plane procedures. When using the
encapsulation technique, the payload's protocol type is
identified on a per PDU basis by an in-band LLC header, followed
the payload data
When transporting a PPP payload over FUNI, an implementation
1. MUST support virtual circuit multiplexed PPP payloads
described in section 5 below by mutual configuration
negotiation of both end points. This technique is referred
as "VC-multiplexed PPP".
2. MUST support LLC encapsulated PPP payloads on PVCs
described in section 6 below by mutual configuration
negotiation of both end points. This technique is referred
as "LLC encapsulated PPP".
3. For SVC set up, an implementation MUST negotiate using
Q.2931 [9] Annex C procedure, encoding the Broadband Lower
Interface (B-LLI) information element to signal either VC
multiplexed PPP or LLC encapsulated PPP. The details of
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
MUST use LLC encapsulated PPP payloads. Frame Relay/ATM FRF.8
inter-working units are exempted from the requirement to
VC-multiplexed PPP. This exemption allows the FR/ATM IWU
remain compliant with FRF.8 when the PPP over FUNI end point
inter-operating with an RFC 1973 end point
5. Virtual Circuit Multiplexed PPP Over
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
| | |
| | |
+-------------------------------+ |
| FUNI FCS (2 or 4 octets) |
+-------------------------------+---------
| 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
Priority bit, and four Reserved bits
The User SDU field contains user information up to 4096 (
up to 64K) octets
The FCS field protects the entire FUNI PDU except for the FCS
itself
A VC-multiplexed PPP frame SHALL constitute the User Service
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
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.
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
destination SAP of routed OSI PDU (values 0xFE 0xFE),
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
+-------------------------+ |
| Frame Type = UI (0x03) |
+-------------------------+ --------
| NLPID = PPP (0xCF) |
+-------------------------+ --------
| Protocol Identifier | ^
| (8 or 16 bits) | |
+-------------------------+ PPP
| . | |
| . | |
| PPP information field | |
| . | |
| . | |
+-------------------------+ |
| padding |
+-------------------------+ --------
| FUNI FCS (2 or 4 octets)| FUNI
+-------------------------+---------
Figure 3
The end points MAY be bi-laterally provisioned to send
LLC-encapsulated protocols besides PPP across the same
connection. However, they MUST NOT send packets belonging
any protocol that has an active NCP within the PPP session
Implementations SHOULD do packet scheduling that minimizes
performance impact on the quality of service
associated with both the LLC-encapsulated PPP and non-
protocol flows
Gross, et. al. Standards Track [Page 5]
RFC 2363 PPP Over FUNI July 1998
7. Out-Of-Band Control Plane
When originating a switched virtual circuit FUNI connection,
caller MUST request in the SETUP message either VC-
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
Indicator IE in the order of their preference. The
implementation MUST be able to accept an incoming call
offers LLC-encapsulated PPP in the caller's request. The
implementation MUST reject a call set up request that
offers an encapsulation that it does not support
Implementations originating a call offering both
encapsulation techniques MUST be able to negotiate the use
LLC-encapsulated PPP
When originating a virtual circuit multiplexed call that is
carry a PPP payload, the ITU Q.2931 [9] B-LLI element
information layer 3 protocol field is encoded to select ISO/
TR 9577 [5] in octet 7. The extension octets specify an
value of PPP (0xCF). By definition, the first bytes of the
frame's payload field will always contain a PPP header
by a packet
When originating an LLC encapsulated call that is to carry a
payload, the ITU Q.2931 B-LLI element user information layer 2
protocol field is encoded to select LAN Logical Link
(ISO/IEC8802-2) in octet 6. See RFC 1755 [8] appendix A for
example. By definition, the first bytes of the FUNI frame'
payload field will contain an LLC header, followed by a
and the PPP payload
8. Detection And Recovery From Unsolicited PPP Encapsulation
When the virtual connection loses state, the PPP
technique may uni-laterally and unexpectedly change across
transitions. Detection and recovery procedures are defined
the following state transitions
VC-multiplexed PPP changing to LLC encapsulated
LLC encapsulated PPP changing to VC-multiplexed
When LLC-encapsulated PPP is being used, the inital 6 octets of
LCP packets contain the sequence: fe-fe-03-cf-c0-21. This
constitutes the first 6 octets of the FUNI frame. In the case
VC-multiplexed PPP, initial LCP packets contain the sequence c0-21.
Gross, et. al. Standards Track [Page 6]
RFC 2363 PPP Over FUNI July 1998
In the case of FUNI, this sequence follows the FUNI Header. When
LCP Configure-Request packet is received and recognized, the PPP
enters Link Establishment phase
Once PPP has entered the Network-layer Protocol phase,
successfully negotiated a particular NCP for a PPP Protocol, if
frame arrives using an alternate but equivalent data encapsulation
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
message, enter the Termination state, and silently drop
received packets
These policies prevent "black-holes" that occur when the peer
state. An implementation which requires PPP link configuration,
other PPP negotiated features (such as authentication), MAY
Termination state when configuration fails
9. LCP Configuration
The Magic Number LCP configuration option is RECOMMENDED, and
Protocol Field Compression (PFC) option is NOT RECOMMENDED.
implementation MUST NOT request any of the following options,
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
larger size than the maximum CPCS-SDU size specified in
associated direction for the virtual connection's traffic contract
When viewed peer to peer, a PPP link may be bridged over
physical layer sections. For each such FUNI section, the LCP
options MUST be actively negotiated by the bridging
independently of the LCP framing options in use by other
layer sections
Gross, et. al. Standards Track [Page 7]
RFC 2363 PPP Over FUNI July 1998
Implementation Note
When an ATM FUNI PVC is in the "Stopped" state, it
RECOMMENDED that the implementation wait for Configure-Requests
See the implementation option in reference [1] section 4.2,
"Stopped State" sub-section
10. Security
Generally, ATM networks are virtual circuit based, and security
implicit in the public data networking service provider'
administration of Permanent Virtual Circuits (PVCs) between
network boundaries. The probability of a security breach caused
mis-routed ATM cells is considered to be negligible
When a public ATM network supports Switched Virtual Circuits,
protocol model becomes analogous to traditional voice band modem
up over the Public Telephone Switched Network (PTSN). The
PAP/CHAP authentication protocols that are already widely in use
Internet dial up access are leveraged. As a consequence, PPP
FUNI security is at parity with those practices already
by the existing Internet infrastructure
Those applications that require stronger security are encouraged
use authentication headers, or encrypted payloads, and/or ATM-
security services
When using LLC-encapsulated PPP over a virtual connection, an
point can not assume that the PPP session authentication and
security mechanisms also secure the other LLC encapsulated flows
that same virtual connection
11.
This design is based on work performed in ADSL Forum's Packet
Working Group. It is inspired by "PPP in Frame Relay", RFC 1973,
William Simpson. Special thanks to Phil Rakity of Flowpoint,
Kwok of Microsoft, and David Allan of Nortel for their
review and commentary
Gross, et. al. Standards Track [Page 8]
RFC 2363 PPP Over FUNI July 1998
12.
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
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,
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] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D.,
A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755,
February 1995.
[9] International Telecommunication Union, "Broadband
Service Digital Network (B-ISDN) Digital Subscriber
System No.2 (DSS2) User Network Interface Layer 3
for Basic Call/Connection Control", ITU-T
Q.2931, (International Telecommunication Union: Geneva, 2/95)
[10] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
Gross, et. al. Standards Track [Page 9]
RFC 2363 PPP Over FUNI July 1998
Chair's
The working group can be contacted via the current chair
Karl
Ascend
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
EMail: karl@ascend.
Authors'
Questions about this memo can also be directed to
George
Lucent Technologies,
184 Liberty Corner
Warren, NJ 07059
Phone: +1.908.580.4589
EMail: gmgross@lucent.
Manu
Paradyne
21 Bear Meadow
Londonderry, NH 03053-2168
Phone: +1.603.434.6088
EMail: mjk@nj.paradyne.
Arthur
Shasta Networks Inc
249 Humboldt
Sunnyvale, CA 94089-1300
Phone: +1.408.747.5051
EMail: alin@shastanets.
Gross, et. al. Standards Track [Page 10]
RFC 2363 PPP Over FUNI July 1998
Andrew
Ascend Communications, Inc
1 Robbins
Westford, MA 01886
Phone: +1.978.952.7414
EMail: malis@ascend.
John
Cayman Systems, Inc
100 Maple
Stoneham, MA 02180
Phone: +1.617.279.1101
EMail: john@cayman.
Gross, et. al. Standards Track [Page 11]
RFC 2363 PPP Over FUNI July 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Gross, et. al. Standards Track [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
