RFC1661PPP协议中文版.docx
《RFC1661PPP协议中文版.docx》由会员分享,可在线阅读,更多相关《RFC1661PPP协议中文版.docx(47页珍藏版)》请在冰豆网上搜索。
RFC1661PPP协议中文版
RFC1661——PPP协议中文版
文章摘要:
PPP为基于点对点连接的多协议自寻址数据包的传输提供了一个标准方*。
PPP
包含以下三个成分:
1.压缩多协议自寻址数据包的方*。
2.用于建立、设定和测试数据链路连接的LCP。
3.一族用于建立、设定不同网络层协议的NCP。
本文档定义了PPP的组织和方*,以及PPP封装,与之一起定义的还有:
扩展选项协商机制,他使得(人们)可以就丰富的设定参数进行磋商,同时还提供额外的管理功能。
PPP链路控制协议(LCP)九是用这种机制描述的。
正文:
RFC1661——PPP协议中文版
1介绍
PPP是为在同等单元之间传输数据包这样的简单的链路而设计的。
这种链路提供全双工*作,并按照顺序传递数据包。
(人们)有意让PPP为基于各种主机、网桥和路由器的简单连接提供一种共通的解决方案。
封装:
PPP封装提供了不同网络层协议同时通过统一链路的多路技术。
(人们)精心的设计PPP封装,使其保有对常用支持硬件的兼容性。
当使用默认的类HDLC帧(HDLC-likeframing)时,仅需要8个额外的字节,就可以形成封装。
在带宽需要付费时,封装和帧可以减少到2或4个字节。
为了支持高速的执行,默认的封装只使用简单的字段,多路分解只需要对其中的一个字段进行检验。
默认的头和信息字段落在32-bit边界上,尾字节可以被填补到任意的边界。
链路控制协议(LCP):
为了在一个很宽广的环境内能足够方便的使用,PPP提供了LCP。
LCP用于就封
装格式选项自动的达成一致,处理数据包大小的变化,探测looped-back链路和其他普通的配置错误,以及终止链路。
提供的其他可选设备有:
对链路中同等单元标识的认证,和当链路功能正常或链路失败时的决定。
网络控制协议:
点对点连接可能和当前的一族网络协议产生许多问题。
例如,基于电路交换的点
对点连接(比如拨号模式服务),分配和管理IP地址,即使在LAN环境中,也
非常困难。
这些问题由一族网络控制协议(NCP)来处理,每一个协议管理着各
自的网络层协议的特殊需求。
配置:
(人们)有意使PPP链路很容易配置。
通过设计,标准的默认值处理全部的配置。
执行者可以对默认配置进行改进,它被自动的通知给其同等单元而无需*作员的干涉。
最终,*作员可以明确的为链路设定选项,以便其正常工作。
1-1要求说明书
在本文档中,用以下几个词来表示说明书的要求,这些词一般以大写字体书写。
MUST--要求;MUSTNOT--禁止;SHOULD--推荐;MAY--可选。
1-2术语
本文档中,频繁使用以下术语:
datagram--在网络层中的传输单元(例如IP)。
一个datagram可能被压缩成一个或几个packets,在数据链路层中传输。
frame--在数据链路层中的传输单元。
一个frame包括一个头和/或尾字节,后面跟有几个单元的数据。
packet--封装的基本单元,它穿越网络层和数据链路层的分解面。
通常一个
packet映射成一个frame,但也有例外:
即当数据链路层执行拆分或将几个
packet合成一个frame的时候。
peer--点对点链路的另一端。
silentlydiscard
--丢弃packet而不进行进一步的处理。
执行(这个动作)应该提供记录错误,包括丢弃packet的内容,的容量,并且应该在一个统计计数器中记录这一事件。
2PPP封装
PPP封装用于消除多协议datagrams的歧义。
封装需要帧同步以确定封装的开始和结束。
提供帧同步的方*在参考文档中。
PPP封装的概要如下所示。
字段的传输从左到右。
协议字段:
协议字段由一个或两个字节组成。
它的值标识着压缩在packet的信息字段里的datagram。
字段中最有意义位(最高位)被首先传输。
该字段结构与ISO3309地址字段扩充机制相一致。
该字段必须是奇数:
最轻意义字节的最轻意义位(最低位)必须等于1。
另外,字段必须被赋值,以便最有意义字节的最轻意义位为0。
收到的不符合这些规则的frames,必须被视为带有不被承认的协议。
在范围"0***"到"3***"内的协议字段,标识着特殊packets的网络层协议。
在范围"8***"到"b***"内的协议字段,标识着packets属于联合的(相关的)网络控制协议(NCP)。
在范围"4***"到"7***"内的协议字段,用于没有相关NCP的低通信量协议。
在范围"c***"到"f***"内的协议字段,标识着使用链路层控制协议(例如LCP)的packets。
到目前为止,协议字段的值在最近的"AssignedNumbers"RFC[2]里有详细的说明。
本说明书保留以下的值:
Value(inhex)
ProtocolName
0001
PaddingProtocol填料协议
0003to001f
reserved(transparencyinefficient)保留(透明度
效率低的)
007d
reserved(ControlEscape)保留(控制逃逸)
00cf
reserved(PPPNLPID)保留(PPPNLPID)
00ff
reserved(compressioninefficient)保留(压缩效率
低的)
8001
to801f
unused(未使用)
807d
unused(未使用)
80cf
unused(未使用)
80ff
unused(未使用)
c021
LinkControlProtocol链路控制协议
c023
PassWordAuthenticationProtocol密码认证协议
c025
LinkQualityReport链路品质报告
c223
ChallengeHandshakeAuthenticationProtocol挑
战-认证握手协议
新的协议的开发者必须从theInternetAssignedNumbersAuthority(IANA),
atIANA@isi.edu.处获得号码。
信息字段:
信息字段是0或更多的字节。
对于在协议字段里指定的协议,信息字段包含datagram。
信息字段的最大长度,包含填料但不包含协议字段,术语叫做最大接收单元(MRU),默认值是1500字节。
若经过协商同意,也可以使用其它的值作为MRU。
填料:
在传输的时候,信息字段会被填充若干字节以达到MRU。
每个协议负责根据实际信息的大小确定填料的字节数。
3PPP链路*作
3-1概述
为了通过点对点链路建立通信,PPP链路的每一端,必须首先发送LCPpackets以便设定和测试数据链路。
在链路建立之后,peer才可以被认证。
然后,PPP必须发送NCPpackets以便选择和设定一个或更多的网络层协议。
一旦每个被选择的网络层协议都被设定好了,来自每个网络层协议的datagrams就能在连路上发送了。
链路将保持通信设定不变,直到外在的LCP和NCP关闭链路,或者是发生一些外部事件的时候(休止状态的定时器期满或者网络管理员干涉)。
3-2阶段划分框图
在设定、维持和终止点对点链路的过程里,PPP链路经过几个清楚的阶段,如框图所示。
这张图并没有给出所有的状态转换。
3-3链路死亡(物理连接不存在)
链路一定开始并结束于这个阶段。
当一个外部事件(例如载波侦听或网络管理员
设定)指出物理层已经准备就绪时,PPP将进入链路建立阶段。
在这个阶段,LCP
自动机器将处于初始状态,向链路建立阶段的转换将给LCP自动机器一个UP事
件信号。
执行笔记:
典型的,在与调制解调器断开之后,链路将自动返回这一阶段。
在用硬件实现的链路里,这一阶段相当的短--仅够侦测设备的存在。
3-4链路建立阶段
LCP用于交换配置信息包(Configurepackets),建立连接。
一旦一个配置成功信息包(Configure-Ackpacket)被发送且被接收,就完成了交换,进入了LCP开启状态。
所有的配置选项都假定使用默认值,除非被配置交换所改变。
有一点要注意:
只有不依赖于特别的网络层协议的配置选项才倍LCP配置。
在网络层协议阶段,个别的网络层协议的配置由个别的网络控制协议(NCP)来处理。
在这个阶段接收的任何非LCPpackets必须被silentlydiscarded(静静的丢弃)。
收到LCPConfigure-Request(LCP配置要求)能使链路从网络层协议阶段或者认证阶段返回到链路建立阶段。
3-5认证阶段
在一些链路上,在允许网络层协议packets交换之前,链路的一端可能需要peer去认证它。
默认的,认证是不需要强制执行的。
如果一次执行希望peer根据某一特定的认证协议来认证,那么它必须在链路建立阶段要求使用那个认证协议。
应该尽可能在链路建立后立即进行认证。
而,链路质量检查可以同时发生。
在一
次执行中,禁止因为交换链路质量检查packets而不确定地将认证向后推迟这一做*。
在认证完成之前,禁止从认证阶段前进到网络层协议阶段。
如果认证失败,认证者应该跃迁到链路终止阶段。
在这一阶段里,只有链路控制协议、认证协议,和链路质量监视协议的packets是被允许的。
在该阶段里接收到的其他的packets必须被静静的丢弃。
执行笔记:
一次执行中,仅仅是因为超时或者没有应答就造成认证的失败是不应该的。
认证应该允许某种再传输,只有在若干次的认证尝试失败以后,不得已的时候,才进入链路终止阶段。
在执行中,哪一方拒绝了另一方的认证,哪一方就要负责开始链路终止阶段。
3-6网络层协议阶段
一旦PPP完成了前面的阶段,每一个网络层协议(例如IP,IPX,或AppleTalk)必须被适当的网络控制协议(NCP)分别设定。
每个NCP可以随时被打开和关闭。
执行笔记:
因为一次执行最初可能需要大力浪的时间用于链路质量检测,所以当等待peer设定NCP的时候,执行应该避免使用固定的timeouts。
当一个NCP处于Opened状态时,PPP将携带相应的网络层协议packets。
当相应
的NCP不处于Opened状态时,任何接收到的被支持的网络层协议packets都将
被静静的丢弃。
执行记录:
当LCP处于Opened状态时,任何不被该执行所支持的协议packets必须在Protocol-Reject里返回。
只有支持的协议才被静静的丢弃。
在这个阶段,链路通信量由LCP,NCP,和网络层协议packets的任意可能的联合组成。
3-7链路终止阶段
PPP可以在任意时间终止链路。
引起链路终止的原因很多:
载波丢失、认证失败、链路质量失败、空闲周期定时器期满、或者管理员关闭链路。
LCP用交换Terminate(终止)packets的方*终止链路。
当链路正被关闭时,PPP
通知网络层协议,以便他们可以采取正确的行动。
交换Terminate(终止)packets之后,执行应该通知物理层断开,以便强制链
路终止,尤其当认证失败时。
Terminate-Request(终止-要求)的发送
者,在收到Terminate-Ack(终止-允许)后,或者在重启计数器期满后,应该
断开连接。
收到Terminate-Request的一方,应该等待peer去切断,在发出
Terminate-Request后,至少也要经过一个Restarttime(重启时间),才允许
断开。
PPP应该前进到链路死亡阶段。
在该阶段收到的任何非LCPpackets,必
须被静静的丢弃。
执行笔记:
LCP关闭链路就足够了,不需要每一个NCP发送一个Terminatepackets。
相反,一个NCP关闭却不足以引起PPP链路的终止,即使那个NCP是当前唯一一个处于Opened状态的NCP。
4自动机协商选项
finite-stateautomaton(有限态自动机)由事件、动作和状态转换定义。
事件包括接收外部命令,例如OpenandClose(打开和关闭)、重启定时器期满、和接收从peer来的packets。
动作包括启动重启定时器和向peer传输packets。
一些packets类型--Configure-Naks(设定-成功)和Configure-Rejects(设定-拒绝),或Code-Rejects(编码-拒绝)和Protocol-Rejects(协议-拒绝),或Echo-Requests(回波-要求),Echo-Replies(回波-应答)和Discard-Requests(丢弃-要求)--在自动机描述中不加以区分。
从后面的描述可知,这些packets确实有着不同的功能。
然而他们总是引起相同的转换。
EventsActions
Up=lowerlayerisUptlu=This-Layer-Up
Down=lowerlayerisDowntld=This-Layer-DownOpen=administrativeOpentls=This-Layer-StartedClose=administrativeClosetlf=This-Layer-Finished
TO+=Timeoutwithcounter>0irc=Initialize-Restart-Count
TO-=TimeoutwithcountereXPiredzrc=Zero-Restart-Count
RCR+=Receive-Configure-Request(Good)scr=Send-Configure-RequestRCR-=Receive-Configure-Request(Bad)
RCA=Receive-Configure-Acksca=Send-Configure-Ack
RCN=Receive-Configure-Nak/Rejscn=Send-Configure-Nak/RejRTR=Receive-Terminate-Requeststr=Send-Terminate-RequestRTA=Receive-Terminate-Acksta=Send-Terminate-Ack
RUC=Receive-Unknown-Codescj=Send-Code-RejectRXJ+=Receive-Code-Reject(permitted)orReceive-Protocol-Reject
RXJ-=Receive-Code-Reject(catastrophic)
orReceive-Protocol-Reject
RXR=Receive-Echo-Requestser=Send-Echo-ReplyorReceive-Echo-Reply
orReceive-Discard-Request
4-1状态迁移图
全部的状态转换如下表。
状态在水平轴,事件在垂直轴。
状态转换和动作备表示成:
动作/新状态的形式。
多个动作用逗号分隔,无先后顺序。
状态后面跟的那个字母是说明性的脚注。
短划线('-')代表无效的转换。
State
012345
EventsInitialStartingClosedStoppedClosingStopping------
+-----------------------------------------------------------
Up2irc,scr/6----
Down--0tls/101
Opentls/11irc,scr/63r5r5r
Close0tlf/02244
TO+----str/4str/5
TO-----tlf/2tlf/3
RCR+--sta/2irc,scr,sca/845
RCR---sta/2irc,scr,scn/645
RCA--sta/2sta/345
RCN--sta/2sta/345
RTR--sta/2sta/3sta/4sta/5
RTA--23tlf/2tlf/3
RUC--scj/2scj/3scj/4scj/5
RXJ+--2345
RXJ---tlf/2tlf/3tlf/2tlf/3
RXR--2345
State
6789
EventsReq-SentAck-RcvdAck-SentOpened
------+-----------------------------------------
Up----
Down111tld/1
Open6789r
Closeirc,str/4irc,str/4irc,str/4tld,irc,str/4
TO+scr/6scr/6scr/8-
TO-tlf/3ptlf/3ptlf/3p-
RCR+sca/8sca,tlu/9sca/8tld,scr,sca/8
RCR-scn/6scn/7scn/6tld,scr,scn/6
RCAirc/7scr/6xirc,tlu/9tld,scr/6x
RCNirc,scr/6scr/6xirc,scr/8tld,scr/6x
RTRsta/6sta/6sta/6tld,zrc,sta/5
RTA668tld,scr/6
RUCscj/6scj/7scj/8scj/9
RXJ+6689
RXJ-tlf/3tlf/3tlf/3tld,irc,str/5
RXR678ser/9
那些其中运行着重启计时器的状态,是可以由存在的TO事件确认的。
只有Send-Configure-Request,Send-Terminate-Request和Zero-Restart-Count动作才启动或者重新启动重启定时器。
当从任意一个定时器运行的状态转换到一个定时器不运行的状态时,重启定时器(Restarttimer)停止。
根据消息通过体系机构而不是信号通知体系机构,(人们)定义了事件和动作。
如果希望一个动作去控制特定的信号(如DTR),那么就可能需要额外的动作。
[p]被动选项;见Stopped状态讨论。
[r]重启选项;见Open事件讨论。
[x]交叉连接;见RCA事件讨论。
4-2状态
下面是每个自动机状态的详细描述。
Initial(初始):
在初始状态,下层是不可获得的(Down),并且没有Open发生。
Restarttimer不在该状态下运行。
Starting(启动):
启动状态是初始状态的Open相似物。
一个管理的Open被初始化,但下层仍旧不可用(Down)。
Restarttimer不在该状态下运行。
#当下层变为可用(Up)时,
发送一个Configure-Request。
Closed(关闭):
在关闭状态,链路时可用的(Up),但是没有Open发生。
Restarttimer不在该状态下运行。
当收到Configure-Requestpackets时,发送一个Terminate-Ack。
Terminate-Acks被静静的丢弃,以防止造成循环。
Stopped(停止)
停止状态是关闭状态的Open相似物。
当在This-Layer-Finished动作之后,或是发送Terminate-Ack之后,自动机正等待Down事件的时候,进入该状态。
Restarttimer不在该状态下运行。
当收到Configure-Requestpackets时,发送一个适当的响应。
当收到其他
packets时,发送一个Terminate-Ack。
Terminate-Acks被静静的丢弃,以防止
造成循环。
基本原理:
停止状态是链路终止,链路设定失败,和其他自动机失败模式的一个接合(中间)状态。
这些各自独立的状态被潜在的联合起来。
在Down事件应答(从This-Layer-Finished动作)和Receive-Configure-Request事件之间,有一种竞赛条件。
当Configure-Request在Down事件之前到来,代替Down事件的是自动机返回到Starting状态。
这防止了由重复产生的攻击。
执行选项:
在peer对Configure-Requests响应失败之后,一个执行可以被动的等待peer发送Configure-Requests。
在这种情况下,在状态Req-Sent,Ack-Rcvd,和Ack-Sent里,动作This-Layer-Finished不用于TO-事件。
这个选项对于专用电路或者没有可用的状态信号的电路有用,但禁止用于交换电
路。
Closing(结束)
在结束状态里,为了终止连接作了一次尝试。
发送了一个Terminate-Request,并运行了Restarttimer,但没有收到Terminate-Ack。
当收到Terminate-Ack时,就进入了Closed状态。
当Restarttimer期满时,
传输一个新的Terminate-Request,并且Restarttimer被重新启动。
在Restarttimer达到Max-Terminate时间后,就进入了Closed状态。
Stopping(停下)
停下状态是结束状态的Open相似物。
发送了一个Terminate-Request,并运行了Restarttimer,但没有收到Terminate-Ack。
基本原理:
停下状态提供了一个很好的机会在允许新的通信量之前终止链路。
在链路终止后,经由Stopped或Starting状态,会出现一个新的配置(设定)。
Request-Sent(要求-发送)
在要求-发送状态,尝试着配置(设定)连接。
发送了一个Terminate-Request,并运行了Restarttimer,但没有收到Terminate-Ack。
Ack-Received(Ack-接收)
在Ack-接收状态,发送了一个Configure-Request,接收了一个Configure-Ack。
因为还没有发送Configure-Ack,所以Restarttimer仍旧运行。
Ack-Sent(Ack-发送)