PPP的网络控制协议根据不同的网络层协议可提供一族网络控制协议，常用的有提供给TCP/IP网络使用的IPCP网络控制协议和提供给SPX/IPX网络使用的IPXCP网络控制协议等，但最为常用的是IPCP协议，当点对点的两端进行NCP参数配置协商时，主要是用来通信双方的网络层地址。 ",",说明
详细内容请见3.1.3节NCP协议 2.2 总结 ", PPP协议的三组件包括PPP协议的封装方式、LCP协议和NCP协议 ", PPP协议是数据链路层协议，它的数据帧封装格式非常类似于HDLC ", PPP协议可通过协议域来区分数据域中净载荷的数据类型 ", PPP协议通过LCP协议完成数据链路的配置和测试 ", PPP协议通过NCP协议完成点对点通信设备之间网络层通信所需参数的配置
第三章 PPP链路的建立 3.1 PPP链路的建立过程 3.1.1 PPP的状态转移图
数据通信设备（在本文中指路由器）的两端如果希望通过PPP协议建立点对点的通信，无论哪一端的设备都需发送LCP数据报文来配置链路（测试链路）。一旦LCP的配置参数选项协商完后，通信的双方就会根据LCP配置请求报文中所协商的认证配置参数选项来决定链路两端设备所采用的认证方式。协议缺省情况下双方是不进行认证的，而直接进入到NCP配置参数选项的协商，直至所经历的几个配置过程全部完成后，点对点的双方就可以开始通过已建 立好的链路进行网络层数据报文的传送了，整个链路就处于可用状态。只有当任何一端收到LCP或NCP的链路关闭报文时（一般而言协议是不要求NCP有关闭链路的能力的，因此通过情况下关闭链路的数据报文是在LCP协商阶段或应用程序会话阶段发出的）；物理层无法检测到载波或管理人员对该链路进行关闭操作，都会将该条链路断开，从而终止PPP会话。以下为PPP协议整个链路过程需经历阶段的状态转移图：
在点对点链路的配置、维护和终止过程中，PPP需经历以下几个阶段： ", 链路不可用阶段，有时也称为物理层不可用阶段，PPP链路都需从这个阶段开始和结束。当通信双方的两端检测到物理线路激活（通常时检测到链路上有载波信号）时，就会从当前
这个阶段跃迁至下一个阶段（即链路建立阶段）。先简单提一下链路建立阶段，在这个阶段主要是通过LCP协议进行链路参数的配置，LCP在此阶段的状态机也会根据不同的
事件发生变化。当处于在链路不可用阶段时，LCP的状态机是处于initial（初始化状态）或starting（准备启动状态），一旦检测到物理线路可用，则LCP的状态机就要发生改变。当然链路被断开后也同样会返回到这个阶段，往往在实际过程中这个阶段所停留的时间是很短的，仅仅是检测到对方设备的存在。 ", 链路建立阶段，也是PPP协议最关键和最复杂的阶段。该阶段主要是发送一些配置报文来配置数据链路，这些配置的参数不包括网络层协议所需的参数。当完成数据报文的交换后，则会继续向下一个阶段跃迁，该下一个阶段既可是验证阶段，也可是网络层协议阶段，下一阶段的选择是依据链路两端的设备配置的（通常是由用户来配置，但对NAS或BAS设备的PPP模块缺省就需要支持PAP或CHAP中的一种认证方式）。在此阶段LCP的状态机会发生两次改变，前面我们说了当链路处于不可用阶段时，此时LCP的状态机处于initial或starting，当检测到链路可用时，则物理层会向链路层发送一个UP事件，链路层收到该事件后，会将 LCP的状态机从当前状态改变为Request-Sent（请求发送状态），根据此时的状态机LCP会进行相应的动作，也即是开始发送Config-Request报文
来配置数据链路，无论哪一端接收到了Config-Ack报文时，LCP的状态机又要发生改变，从当前状态改变为opened状态，进入Opened状态后收到Config-Ack报文的一方则完成了当前阶段，应该向下一个阶段跃迁。同理可知，另一端也是一样的，但须注意的一点是在链路配置阶段双方是链路配置操作过程是相互独立的。如果在该阶段收到了非LCP数据报文，则会的将这些报文丢弃。在实际配置当中在该阶段可能会遇到很多情况，在LCP协议章节中会详细介绍可能遇到的情况，但最好结合一些troubleshooting案例能更好的帮助理解。 ", 验证阶段，多数情况下的链路两端设备是需要经过认证后才进入到网络层协议阶段，缺省情况下链路两端的设备是不进行认证的。在该阶段支持PAP和CHAP两种认证方式，验证方式的选择是依据在链路建立阶段双方进行协商的结果。然而，链路质量的检测也会在这个阶段同时发生，但协议规定不会让链路质量的检测无限制的延迟验证过程。在这个阶段仅支持链路控制协议、验证协议和质量检测数据报文，其它的数据报文都会被丢弃。如果在这个阶段再次收到了Config-Request报文，则又会返回到链路建立阶段。 ", 网络层协议阶段，一旦PPP完成了前面几个阶段，每种网络层协议（IP、IPX和AppleTalk）会通过各自相应的网络控制协议进行配置，每个NCP协议可在任何时间打开和关闭。当一个NCP的状态机变成Opened状态时，则PPP就可以开始在链路上承载网络层的数据包报文了。如果在个阶段收到了Config-Request报文，则又会返回到链路建立阶段。", 网络终止阶段，PPP能在任何时候终止链路。当载波丢失、授权失败、链路质量检测失败和管理员人为关闭链路等情况均会导致链路终止。链路建立阶段可能通过交换LCP的链路终止报文来关闭链路，当链路关闭时，链路层会通知网络层做相应的操作，而且也会通过物理层强制关断链路。对于NCP协议，它是没有也没有必要去关闭PPP链路的。 3.1.2 LCP协议
3.1.2.1 LCP数据报文的封装方式
LCP数据报文是在链路建立阶段被交换的，它作为PPP的净载荷被封装在PPP数据帧的信息域中，此时PPP数据帧的协议域固定填充0xC021，但在链路建立阶段的整个过程中信息域的内容是在变化的，它包括很多种类型的报文，所以这些报文也要通过相应的字段来区分。LCP数据报文的一般封装方式如下图所示：
", 代码域的长度为一个字节，主要是用来标识LCP数据报文的类型的。在链路建立阶段时，接收方收到LCP数据报文的代码域无法识别时，就会向对端发送一个LCP的代码拒绝报文（Code-Reject报文）。根据RFC的规定，到目前为止LCP共包括以下几种类型的数据报文：
", 标识域也是一个字节，其目的是用来匹配请求和响应报文。一般而言在进入链路建立阶段时，通信双方无论哪一端都会连续发送几个配置请求报文（Config-Request报文），而这几个请求报文的数据域可能是完全一样的，而仅仅是它们的标志域不同罢了。通常一个配置请求报文的ID是从0x01开始逐步加1的，当对端接收到该配置请求报文后，无论使用何种 报文（回应报文可能是Config-Ack、Config-Nak和Config-Reject三种报文中的一种）来回应对方，但必须要求回应报文中的ID要与接收报文中的ID一致，当通信设备收到回应后就可以将该回应与发送时的进行比较来决定下一步的操作。 ",",说明
后面教材中的所有例子，均可参考以下色标的含义
范例中报文色标含义如下图所示：
例1：假设点对点通信的一端发送了一个Config-Request报文，报文内容如下：
7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 从报文中可以看出这个配置请求报文包括5个配置参数选项。
当对端正确接收到了该报文后，应该回应一个Config-Ack报文，报文内容如下：
7E FF 03 C0 21 02 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 该报文中唯一修改的内容就是代码域（02表示是Config-Ack报文），标识域与原报文中的一样。 ", 长度域的内容 = 总字节数据（代码域+标志域+长度域+数据域）。长度
域所指示字节数之外的字节将被当作填充字节而忽略掉，而且该域的内容不能超过MRU的值。 ", 数据域的内容依据不同LCP数据报文的内容也是不一样的。 ",",说明
数据域的详细内容请见3.1.2.3节 3.1.2.2 LCP数据报文的分类
在前一小节我们可以看到，一共包括12种LCP数据报文，我们依据各报文的 的功能又将其具体细化为以下三类： ", 链路配置报文，主要用来建立和配置一条链路的。 ", 链路终止报文，主要用来终止一条链路的。 ", 链路维护报文，主要用来维护和调试链路的。 3.1.2.3 LCP的链路配置报文
链路配置报文与其它两类报文有着明显的区别，它主要是用来协商链路的配置参数选项的，因此这种报文的数据域还要携带许多配置参数选项的，而另外两类报文中部分报文的格式会稍有不同（请参见RFC1661），图3-4表明了数据配置选项的报文格式：
链路配置报文主要包括Config-Request 、Config-Ack 、Config-Nak 和Config-Reject四种报文。当通信双方需要建立链路时，无论哪一方都需要发送Config-Request报文并携带每一端自已所希望协商的配置参数选项，下表为一些可选的配置参数选项：
这个表格内的内容并非完全，可能还有一新定议的配置选项未列在其中，如有兴趣可参照相关的文档说明。当接收方收到Config-Request报文时，会在剩下的三种类型的报文中选择一 种来响应对方的请求报文，到底选择哪种报文来响应对方需依据以下两个条件： ", 不能完全识别配置参数选项的类型域，我们知道一个Config-Request报文中会同时携带多个配置参数选项，而对于一个支持PPP协议的通信设备也不一定会支持上表中所有列出的配置选项，即使支持，也可能在实际应用中关闭掉某些选项功能。（例如：当使用PPP协议通信的一端可能将一些无用的配置选项都关闭了，而仅支持0x01和0x03两个配置参数选
项，因此当对方发送的Config-Request报文中含有0x04配置选项时，对于本端而言这个配置参数选项就无法识别，也即是不支持这个配置参数选项的协商）。 ", 如果能支持完全识别配置参数选项， 但接收端也可能不认可
Config-Request报文中配置参数选项数据域中的内容（例如：当一端发送魔术字配置参数选项中的魔术字为全0，而对端认为应该为其它值，这种情况就属于不支持配置参数选项中的内容）。所以依据上面的两个条件，我们就可以明确在回应对方配置请求报文时，采用何种报文回应。 ", 当接收Config-Request报文的一端能识别发送过来的所有配置参数选项且 认可所有配置参数选项数据域的内容时，接收端将会给对端回一个Config-Ack报文并将配置请求报文中的配置参数选项原封不动的放置在Config-Ack报文的数据域内（根据协议的规定是不可改变配置参数选项的顺序）。当配置请求报文的发送端收到Config-Ack报后，则会从当前阶段进入到下一个阶段。
例2：假设点对点通信的一端发送了一个Config-Request报文，报文内容如下：
7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 当对端正确接收到了该报文后，应该发送一个Config-Ack报文，报文内容如下：
7E FF 03 C0 21 02 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 唯一改变的内容就是代码域（02表示是Config-Ack报文），此例与例1完全一样，但两都说明的问题有则重点。 ", 当接收Config-Request报文的一端能识别发送端所发送过来的所有配置参数选项，但对部分配置参数选项数据域中的内容不认可时，接收端将会给对端回应一个Config-Nak报文，该报文中只携带不认可的配置参数选项，而这些配置参数选项的数据内容为本端希望的值。然而当接收端收到Config-Nak 报文后， 会重新发送Config-Request 报文， 而这个Config-Request报文与上一次所发送的Config-Request报文区别在于那些被对端不认可的配置参数选项的内容被填写到刚刚协商完后再次发送的Config-Request报文中（Config-Nak报文发送回来的那些配置参数选项）。
例3：假设点对点通信的一端发送了一个Config-Request报文，报文内容如下：