分享
 
 
 

RFC2363 - PPP Over FUNI

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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.

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.

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 RFC1973 [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

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.

+-------------------------+ --------

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.

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 RFC1755 [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

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.

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", RFC1973, 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, RFC1661, 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", RFC1483,

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", RFC1973, 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., and

A. Malis, "ATM Signaling Support for IP over ATM", RFC1755,

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 Telecommunication Union: Geneva, 2/95)

[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement

Levels", BCP 14, RFC2119, March 1997.

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

Authors' Addresses

Questions about this memo can also be directed to:

George Gross

Lucent Technologies, Inc

184 Liberty Corner Road

Warren, NJ 07059

Phone: +1.908.580.4589

EMail: gmgross@lucent.com

Manu Kaycee

Paradyne Corporation

21 Bear Meadow Road

Londonderry, NH 03053-2168

Phone: +1.603.434.6088

EMail: mjk@nj.paradyne.com

Arthur Lin

Shasta Networks Inc.

249 Humboldt Court

Sunnyvale, CA 94089-1300

Phone: +1.408.747.5051

EMail: alin@shastanets.com

Andrew Malis

Ascend Communications, Inc.

1 Robbins Road

Westford, MA 01886

Phone: +1.978.952.7414

EMail: malis@ascend.com

John Stephens

Cayman Systems, Inc.

100 Maple Street

Stoneham, MA 02180

Phone: +1.617.279.1101

EMail: john@cayman.com

Full Copyright Statement

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

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it

or assist in its implementation may be prepared, copied, published

and distributed, in whole or in part, without restriction of any

kind, provided that the above copyright notice and this paragraph are

included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of

developing Internet standards in which case the procedures for

copyrights defined in the Internet Standards process must be

followed, or as required to translate it into languages other than

English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有