GPRS工作原理以及其通信协议(5)

7E FF 03 C0 21 01 04 00 17 02 06 00 0E 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 仔细观察是不是新的配置请求报文与老的配置请求的报文ID不一样。 ", 当接收Config-Request报文的一端不能识别所有的发送端发送过来的配置参数选项时，此时接收端将会向对端回一个Config-Reject报文，该报文中的数据域只携带那些不能识别的配置参数选项（当配置参数选项的类型域不识别时）。当对端接收到Config-Reject报文后，同样会再次发送一个Config-Request报文，这个配置请求报文与上一次发送的区别在于将 不可识别的那些配置参数选项给删除了。

例4：假设点对点通信的一端发送了一个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 下划线所表示的配置参数选项为对端不可识别的。

当对端正确接收到了该报文后，发现类型域为0x02的配置参数选项不识别，应该回应一个Config-Reject报文，报文内容如下：

7E FF 03 C0 21 04 01 00 0A 02 06 00 0A 00 00 7E

该报文如果被原发送端接收后，又会重新发送一个Config-Request报文，报文内容如下：

7E FF 03 C0 21 01 04 00 11 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 这时我们能看到，类型域为02的配置选项在下一次的请求报文中被删除了。所以我们能够看出，链路配置阶段也可能要经过几次协商后才能完成，但这与点对点两端的设备有着密切的联系。对于PPP的两个端点而言，两者是独立完成各自的配置参数选项的协商过程的。具体的配置参数选项待后续的章节中讲解。 3.1.2.4 LCP的链路终止报文

链路终止报文分为Terminate-Request和Terminate-Reply两种报文。LCP报文中提供了一种机

制来关闭一个点对点的连接，想要关断链路的一端会持续发送Terminate-Request报文，直到收到一个Terminate-Reply为止。接收端一旦收到了一个Terminate-Request报文后，必须回应一个Terminate-Reply报文，同时等待对端先将链路断开后，再完成本端的所有断开的操作。 LCP的链路终止报文的数据域与链路配置报文的数据域不一样，链路终止报文中无需携带各配置参数选项。对于链路终止报文也同样需要ID一致，当接收到Terminate-Reply报文才会做链路终止操作。

3.1.2.5 LCP的链路维护报文

除上述两种报文类型以外，剩余的所有报文类型均归属链路维护报文。 ", 当接收端发现LCP报文的代码域是一个不合法的值时，将会向发送端回应一个Code-Reject报文，在回应报文中会将所拒绝报文的内容附加上。

例5：假设点对点通信的一端发送了一个Config-Request报文，报文内容如下：

7E FF 03 C0 21 0E 01 00 19 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 1F02 7E 有下划线的部分表示这个代码域在标准中未定义，从而无法识别。

当对端正确接收到了该报文后，发现LCP数据报文的代码域为0x0E时，应该发送一个 Code-Reject报文，报文内容如下：

7E FF 03 C0 21 07 01 00 1D 0E 01 00 19 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 1F 02 7E ", 当接收端发现所接收到的数据帧的协议域是一个不合法的值时，将会向发送端回应一个Protocol-Reject报文，发送端收到该拒绝报文后将停止发送该种协议类型的数据报文了。Protocol-Reject报文只能在LCP的状态机处于Opened状态时才可被处理，而在其它状态接收到该报文将被丢弃。在Protocol-Reject报文的数据域内将携带所拒绝报文的协议类型和报文内容。

例6：假设点对点通信的一端发送了一个协议域未定义（无法识别）的报文，报文内容如 下：

7E FF 03 77 77 01 01 00 19 02 06 00 0D 00 00 05 07 03 09 02 0D 04 06 2F 02 7E 其中下划线部分为PPP数据帧的协议域，0x7777表示一个未定义的类型（也即对端无法识别）。当对端正确接收到了该报文后，发现该报文的协议域为0x7777，该值未在RFC中未有明确定义，应该发送一个Protocol-Reject报文，报文内容如下：

7E FF 03 C0 21 08 01 00 18 77 77 01 00 00 19 02 06 00 0D 00 00 05 07 03 09 02 0D 04 06 2F 02 7E ", Echo-Request报文和Echo-Reply报文主要用来检测双向链路上自环的问题， 除此之外还可附带做一些链路质量的测试和其它功能。当LCP状态机处于Opened状态时，如果接收到了Echo-Request，就需向对端回送一个Echo-Reply报文。否则在其它LCP状态下，该类型的报文会被丢弃。这种类型数据报文的长度域后不是直接跟数据域，而是要插入4个字节的Magic-Number（魔术字），该魔术字是在LCP的Config-Request的配置参 数选项协商时获得的。

例7：假设点对点通信的一端接收到了一个Echo-Request报文，报文内容如下： 7E FF 03 C0 21 09 01 00 08 02 06 00 0D 7E 有下划线的部分表示魔术字。

当对端正确接收到了该报文后，应该发送一个Echo-Reply报文，报文内容如下： 7E FF 03 C0 21 0A 01 00 08 02 06 00 0D 7E 3.1.3 NCP协议

NCP协议的数据报文是在网络层协议阶段被交换的，在这个阶段所需的一些配置参数选项协商完后，就可以进行网络层的通信，也即是在点对点的链路上可以开始传送网络层的数据报文了。NCP协议主要包括IPCP、IPXCP等，但我们在实际当中最常遇见的也只有IPCP协议了，

如果对IPXCP或其它的一些网络控制协议有兴趣，则可参见RFC1552。 3.1.3.1 IPCP

IPCP控制协议主要是负责完成IP网络层协议通信所需配置参数的选项协商的。IPCP在运行的过程当中，主要是完成点对点通信设备的两端动态的协商IP地址。我们依据两端设备的配置选项可将IPCP的协商过程分为”静态”和”动态”。何为静态，何为动态，这是一个相对的概念，也是自已总结出来的，可能不太准确，只作为参考使用。我们在下面会具体描述这两个过程。IPCP的数据的文同LCP的数据报文非常类似，只不过一个是在网络层协议阶段协商 配置参数选项，而LCP协议则是在链路建立阶段协商配置参数选项的。除此之外是两者在所使用报文上的相似之处，我们知道LCP共包括十几种报文，而IPCP也包括多种报文，但它的报文类型只是LCP数据报文的一个子集（只 有LCP代码域从1到7这七种报文），而且实际的数据报文交换过程中也仅涉及以下几种：Config-Request、Config-Ack、Config-Nak和Config-Reject（代码域从1到4，而链路终止报文一般而言是不在网络协议阶段使用的，而且也是不需要的）。以下就具体介绍一下IPCP控制协议的静态和动态的两个过程，

实际上两者的区分是在于互连设备IP地址的获取过程。 ", 静态协商，也即是不协商。点对点的通信设备两端在PPP协商之前已配

置好了IP地址，所以就无须在网络层协议阶段协商IP地址，而双方唯一要做的就是告诉对方自身的IP地址。在IPCP控制协议完成整个配置的过程时，最理想的情况将会看到如图所示的四种报文，而无其它报文再被发送。如果当配置请求中所携带的网络层配置参数选项类似于LCP配置参数选项协商过程一样，可能会有对方不识别的配置参数选项或不被对 方所认可的配置参数选项的内容。这样在这个阶段的协商过程中可能还会看到其它的一些报文。

在静态协商时，如果IPCP的Config-Request报文中只含有地址配置参数选项时（实际中可能还会附带其它配置参数选项，这些配置参数选项的协商与LCP阶段的一样，而 …… 此处隐藏：5191字，全部文档内容请下载后查看。喜欢就下载吧 ……