时间：2021年4月22日
标题：客户端广域网管理协议（CPE WAN Management Protocol）CWMP

0、术语

名称	解释
ACS	自动配置服务器。是宽带网络中自动配置CPE先进服务器的组成部分。
B-NT	能够被ACS管理的宽带接入CPE的设备。
CPE	客户预定设备。DSL B-NT是宽带CPE的一种形式。
Internet Gateway Device	一种CPE设备，可以是B-NT或宽带路由器。
Option	一个可选的CPE功能，只能使用数字签名凭证来启用或禁用。
RPC	远程过程调用
Parameter	一个名称-值对，表示一个可管理的CPE参数，ACS可访问该参数进行读写。
Session	CPE和ACS之间的连续事务序列。
Voucher	一种数字签名的数据结构，它指示特定的CPE启用或禁用Options，以及决定Options在何种条件下持久存在的特征。

1、介绍

• 基本模块
• 在自动配置构建中的定位
• 安全的目标
• 构建的目标
• 假定
• 术语
• 文档转换

1.1 基本模块

（1）自动配置和动态服务供应
给定参数；
添加指定供应商；
初始化连接时访问互联网，可重复供应；
提供可选工具，例如通过数字用户签名实现安全控制；
扩展以兼容其他版本。
（2）软件或固件镜像的管理
版本识别；
文件下载初始化（ACS初始化的下载，CPE可选的初始化下载）；
下载成功或者失败的提示；
定义签名文件格式；包括可选的分包或者单独文件的下载方式；必须保证文件的完整性；附带安装指令
（3）状态和表现的监控
CPE提供状态和表项现的统计；
定义了一个共同的集合，例如参数；
提供一个标准给供应商定义新增的可用于监控的非标准参数；
定义CPE在什么条件下可以被激活，并把改动通报给ACS。
（4）诊断
提供与连接和服务事项的有用信息；
定义了共用集合譬如参数和新增供应商指定的诊断性能的机制。
（5）身份认证和web应用
支持通过基于web的应用来访问CPE的本地浏览器；
定义了一个可选机制，该机制用于允许web站点通过获取CPE的相关信息来客制化自己的内容；

1.2 在自动化配置构建中定位

• B-NT自动配置这个过程由三步组成；
  -TR-062 [3]和 TR044 [4] 指定了B-NT自动配置的前两步，定义了ATM层和IP层的自动化配置过程、代表和使用，用以初始化基本的带宽连接。
• TR-046 [2] 描述了用于B-NT自动配置的全部固件；
• TR-046 定义了第三步，是主要的一步。建建议将CWMP协议应用于ACS南桥接口；
• 注：B-NT情况下，假如一个可供选择的自动配置在被使用，TR-046模型下，ATM层的参数使用是被允许的；但是在TR-062下确实不允许的；
• 注：协议提供一种方法使诊断和表现来自ATM层和DSL调制解调器监控数据准确。TR046与此不同，它提供可选的方法来访问这些信息，即外部的管理协议例如ILMI、DSL连接的EOC。
• CWMP协议的目标是管理B-NTs，也可以用于管理其他类型的CPE，包括独立路由器和局域网侧的设备
• 除非特别说明，那么CWMP指定的规格将适用于所有任何管理设备，部分仅用于B-NT会被特别指出来；

1.3 安全的目标

• CWMP 的设计要求较高安全程度，安全模型设置为可伸缩的；
• 基础的安全健壮性较差，更好的安全提供先进的安全机制，一般目标为：
  <1>防止某种因素干预到CPE或者ACS的管理功能或者它们的汇报；
  <2>在一个CPE和ACS汇报发生时，提供认证机制；
  <3>允许适当地证明每一次的汇报
  <4>预防窃贼服务器

1.4 构建目标

• 灵活支持多种业务模型，用于建立和管理CPE，包括：
  <1>网络供应商提供和管理CPE；
  <2>对零售的CPE预先注册，以对应服务商和用户账户的关系（类似于手机）；
  <3>对于零售中购进的CPE，供应商进行用户注册，协议提供灵活的连接模式，则需要做到：
  <a>允许CPE和ACS初始化连接的建立，同时防止反复的连接出现；
  <b>ACS和CPE的交互需独立于初始化和建立连接之后；即使ACS的初始化连接不被支持，CPE的初始化处理也应该在连接初始化是进行。
  <c>一个或者多个ACS可服务于众多的CPE，CPE可以一个或者多个供应商相联系；
  <d>通过允许在单个连接上发生多个双向事务，优化已建立的连接的使用，以最小化连接开销
  <4>协议致力于支持对ACSheCPE的发现和建立联；
  <a>提供机制让CPE可以法相适当的供应商所给的ACS；
  <b>提供机制让ACS可以安全地辨识CPE及其相关联的用户；支持这种关联的过程应该支持包含用户交互的模型，以及那些完全自动的模型。
  <5>允许ACS访问控制和监控相关联CPE的参数，对于这些参数的设计需遵循：
  <a>不同的CPE有不同的能力层次，也执行不同的可选功能子集合，结果是，ACS必须去发现有相当能力的指定CPE；
  <b>ACS必须有能力控制和监控CPE当前的配置
  <c>除了ACS之外的其他控制实体可能能够控制CPE配置的一些参数，比如局域网侧的自动配置。因此，协议必须允许ACS考虑到CPE配置的外部更改。ACS还应该能够控制哪些配置参数可以通过ACS以外的方式控制;
  <d>协议应该允许定义和访问特定于供应商的参数。

• 该协议旨在最小化实现的复杂性，同时提供在复杂性与功能之间进行权衡的灵活性。该协议包含了许多可选组件，只有在需要特定功能时才能发挥作用。该协议还在适当的时候合并了现有的标准，允许利用现成的实现。

• 协议也是可扩展的。它包括支持该标准未来扩展的机制，以及针对特定于供应商的扩展的显式机制。

1.5 假定

在定义CPE广域网管理协议时所作的一些假设如下:

• 在B-NT的情况下，在使用CPE WAN管理协议之前，已经完成了在TR-062[3]和TR-044[4]中定义的初始B-NT自动配置，并且已经建立了到WAN的连接，从WAN可以访问ACS；
• 所有CPE无论类型(bridge1
  (路由器或其他)获取一个IP地址，以便与ACS通信。
• CPE一次可以与单个ACS交互。在任何时候，一个CPE都确切地知道一个它可以连接的ACS。在任何时候，一个CPE都确切地知道一个它可以连接的ACS。ACS只能通过显式地更改ACS联系人和身份验证信息来将CPE传递给另一个ACS。(注意:在本文档中，负载均衡器后面的一组ACS服务器被视为单个ACS。)

2、架构

2.1 协议组成

（1）CPE/ACS 应用
应用会使CWMP协议；但这些应用不会指定作为该协议的一部分；
（2）RPC方法
在CWMP协议中有所定义，包括了定义CPE参数用于访问一个ACS，用的时参数关联的RPC方法；指定的参数定义应用于网关设备；
（2）SOAP
一个标准的基于XML的语法，用于封装RPC（remote procedure calls），特别指定SOAP 1.1；
（3）HTTP
特别指定HTTP 1.1
（4）SSL/TLS
一个标准的传输层安全协议。特别的，SSL 3.0 （Secure Socket Layer）， TLS 1.0 （Transport Layer Security）
（5）TCP/IP
标准的TCP/IP

2.2 安全机制

• CPE广域网管理协议的设计目的是在使用它的交互中允许高度的安全性。CPE WAN管理协议旨在防止发生在CPE和ACS之间的事务被篡改，为这些事务提供机密性，并允许不同级别的身份验证；
• 本协议包含以下安全机制:
  <1>该协议支持使用SSL/TLS进行CPE和ACS之间的通信传输。这提供了事务机密性、数据完整性，并允许在CPE和ACS之间进行基于证书的身份验证。
  <2>HTTP层提供了一种基于共享秘密的CPE认证的替代方法。
  该协议包括与附录C和附录E中分别描述的可选的签名凭证机制和签名包格式相关的附加安全机制

（1）安全初始化模型

• 安全机制的初始化在用于CPE分发的各种业务模型的上下文中进行了描述。考虑三种模型:
  <1>与ACS相关的服务提供商的CPE分布。
  <2>CPE的零售分布，CPE与服务提供商和客户的联系在购买时完成。
  <3>没有与CPE进行预关联的零售分销。

• 在前两种情况下，ACS可以在CPE首次使用之前知道CPE的特定身份。在这种情况下，可以使用下列机制:
  <1>ACS
  共享秘钥法：在第一次使用CPE的时候，预先载入共享秘钥；
  认证法：法相ACS的URL作为唯一标识码，用于认证ACS的身份，一道道认证可用的目的。
  <2>CPE
  共享秘钥法：在第一次使用CPE之前，将共享秘钥提供给ACS；
  认证法：CPE使用在线认证方式，通过ACS在CA处登记，CPE需要提供必要的信息来连接CA。

• 在后一种CPE零售分布的情况下，CPE不可能与特定的ACS预先关联。下表给出了适应这种情况的可能方法，但不试图强制使用特定的方法：
  <1>ACS
  共享秘钥法：无动作
  认证法：法相ACS的URL作为唯一标识码，用于认证ACS的身份，一道道认证可用的目的。
  <2>CPE
  共享秘钥法：本规范范围之外的可能选择:
  a、建立一个公共服务器，用于在多个服务提供商之间安全分发CPE共享秘钥。
  b、初始CPE到ACS连接的一个未被识别的CPE可以不经过认证。然后ACS将为后续访问设置共享秘密参数。在ACS实现中需要注意防止拒绝服务攻击。
  认证法：CPE可以使用与CA关联的在线证书注册ACS，必须向CPE提供与此联系所需的信息CA，可以将其合并到发现过程中。

2.3 构建组成

（1）参数

• RPC方法规范(参见附录A)定义了一种通用机制，ACS可以通过该机制读写参数来配置CPE和监控CPE状态和统计信息；
• Internet网关设备定义的特定参数列表在附录b中指定，每个参数由一个名称-值对组成。该名称标识特定的参数，并且具有类似于目录中的文件的层次结构，每个层次用‘.’来分隔；
• 参数的值可以是几种已定义的数据类型中的一种(参见附录B)。参数可以定义为只读或可读写。只读参数可用于ACS确定特定的CPE特性、观察CPE当前状态或收集统计信息。可写参数允许ACS自定义CPE操作的各个方面；
• 所有可写参数也必须是可读的；
• 一些可写参数的值可以通过本规范中定义的接口以外的方式独立修改(例如，一些参数也可以通过局域网侧自动配置协议修改)。
• 该协议支持一种发现机制，该机制允许ACS确定特定CPE支持哪些参数，允许定义可选参数，并支持直接添加未来的标准参数；
• 该协议还包括一个可扩展机制，允许使用除本规范中定义的参数外的特定于供应商的参数。

（2）文件传送

• RPC方法规范(见附录A)定义了一种机制来促进文件下载或(可选)上传用于各种目的，如固件升级或特定于供应商的配置文件。
• 当ACS发起时，使用HTTP向CPE提供要传输的文件的位置（或者可以选择使用HTTPS、FTP或TFTP作为传输协议），然后，CPE执行传输，并通知ACS成功或失败；
• 下载可以选择由CPE发起。在本例中CPE首先请求下载来自ACS的特定文件类型。然后ACS可能会响应，启动下载步骤与acs发起的下载相同。
• CPE广域网路管理协议还定义了一种可选的数字签名文件格式用于下载。该签名包格式在附录E中定义。

（3）CPE初始化通告

• RPC方法规范(见附录A)定义了一种机制，允许CPE通知相应的ACS的各种条件，并确保最低频率的CPE-to-ACS通信；
• 这包括在初始CPE安装时建立通信的机制，以“引导”初始定制参数进入CPE；
• 它还包括一个建立定期通信的机制或者当必须报告给ACS的事件发生时(例如CPE的宽带IP地址发生变化)。ACS必须知道这个事件，以便建立到CPE的传入连接；
• 在每种情况下，当通信建立时，CPE通过制造商和唯一标识自己序列号信息，以便ACS知道它正在与哪个CPE通信并可以在哪个CPE中作出一个适当的方式响应。

（4）异步ACS初始化通告

• 服务自动配置的一个重要方面是ACS能够通知CPE异步配置更改。这允许使用自动配置机制需要对CPE进行近实时重新配置的服务。例如，这可以用来提供终端用户可以立即访问他们已订阅的服务或特性，而无需等待下一次定期通知间隔。
• CPE广域网路管理协议包含了ACS发出连接的机制随时向CPE请求，指示它与ACS建立通信会话。
• 而CPE WAN管理协议也允许由CPE轮询代替acs发起的轮询连接，CPE WAN管理协议不依赖于轮询或建立持久从CPE连接来提供异步通知。

3、程序和要求

3.1 ACS发现

• CPE WAN管理协议定义了以下机制，CPE可以使用这些机制来发现其关联ACS的地址:

<1>CPE可能在本地配置了ACS的URL。例如，这可以通过局域网侧CPE自动配置协议。CPE将使用DNS解析来自ACS的URL主机名组件。
<2>作为IP层自动配置的一部分，接入网中的DHCP服务器可以被配置为包含ACS URL作为DHCP选项[12]。
CPE将使用DNS解析的IP地址，从URL的主机名组件ACS。在这种情况下，第二个DHCP选项可能是用于设置提供代码，它可以用来指示主要服务提供者和向ACS提供的其他信息；
CPE通过包含该字符串向DHCP服务器标识自己支持此方法，" dslforum.org "(全小写)在供应商类标识符(DHCP选项60)的任何地方；
CPE可能使用从DHCP服务器接收到的Vendor Specific Information中的值
(DHCP选项43)设置相应参数，如表2所示。这个DHCP选项被编码为一个或多个封装供应商特定选项的列表，格式为[12]中定义的格式；
除了这里列出的选项外，这个列表可能还包括其他特定于供应商的选项。
<3>封装供应商的指定操作
ACS的URL：操作数 1，参数 InternetGatewayDevice.ManagementServer.URL
提供的代码：操作数 2， 参数 InternetGatewayDevice.DeviceInfo.ProvisioningCode
<4>CPE可能有一个默认的ACS URL，如果没有向它提供其他URL，它可以使用这个URL；
ACS地址必须是有效的HTTP或HTTPS地址[5]；
使用HTTPS URL表示ACS支持SSL协议；
如果给出了一个HTTPS URL，而CPE不支持SSL，它可能会尝试使用HTTP，假设URL的其余部分没有改变。

• CPE与ACS建立连接后，ACS可以随时修改ACS地址保存在CPE中的参数(InternetGatewayDevice.ManagementServer.URL)。一旦修改,CPE必须使用修改后的地址进行后续的ACS连接；
• 当CPE使用ACS URL的“主机”部分验证来自ACS的证书时，使用基于证书的身份验证。因为这依赖于ACS URL的准确性，总的来说该协议的安全性依赖于ACS URL的安全性；
• CPE应该将本地配置ACS URL的能力限制为需要严格的机制
  安全；
• CPE可能进一步限制仅将ACS URL本地设置为初始设置的能力，防止与ACS的初始连接成功后进行进一步的本地配置，这样，只有其现有的ACS可以随后更改此URL；
• 使用DHCP配置ACS URL应限制在以下情况，服务提供商可以保证DHCP服务器和CPE之间链路的安全性。自DHCP本身不包含安全机制，其他确保这种安全性的方法应该包含提供。

3.2 连接的建立

（1）CPE连接的初始化
CPE可以在任何时候使用预先确定的ACS地址(见3.1节)发起到ACS的连接。CPE必须与ACS建立连接，并发出Inform RPC方法
(按照第3.7节所述的程序)在下列条件下:
<1>CPE首次在初始安装时与接入网建立连接;
<2>开机或复位
<3>每隔一次PeriodicInformInterval(例如，每24小时)
<4>当由可选的ScheduleInform方法指示时
<5>当CPE从ACS接收到一个有效的连接请求时(见3.2.2节)
<6>.当ACS的URL发生变化时
<7>当一个参数被修改时，就需要启动一个更改通知。在互联网网关设备的情况下，这包括以下更改(见A.3.3.1)
o默认宽带连接IP地址
o管理IP地址(与连接请求URL关联)
o发放代码
o软件版本
<8>当ACS通过SetParameterAttributes方法标记为活动通知的参数值被外部原因(不是ACS本身的原因)修改时。ACS本身通过SetParameterValues所做的参数更改绝对不能导致一个新的会话被启动。如果在CPE能够发起会话来执行通知之前，参数被修改了多次，则只执行一次通知；
当一个会话正在进行时，如果一个参数被外部原因修改了，这个更改会导致在当前会话终止后建立一个新的会话(绝对不能影响当前会话)；
为了避免向ACS发送过多的流量，CPE可能对参数更改通知的频率设置本地指定的限制。这个限制应该被定义，只有在不寻常的情况下才会超过。如果超过了这个限制，CPE可能会延迟本地指定的发起会话的时间来通知ACS。在这个延迟之后，CPE必须向ACS发起一个会话，并指出自上次这样的通知以来发生的所有相关参数更改(那些标记为通知的参数)。

• 当没有更多未完成的消息时，CPE不应该保持到ACS的开放连接CPE或ACS上存在。

（2）ACS连接初始化

• 无论何时ACS都应要求CPE使用connection request通知机制发起到ACS的连接；

• CPE需要支持该机制，ACS推荐支持该机制，这种机制依赖于CPE拥有一个从ACS可路由的IP地址。如果CPE位于ACS和CPE之间的防火墙或NAT设备后，ACS可能无法访问CPE。在这种情况下，只能启动CPE连接。

• 连接请求通知机制定义如下:
  <1>连接请求通知是一个HTTP Get到CPE指定的特定URL。CPE上的URL值为只读参数。这个URL值的路径应该由CPE随机生成，以便每个CPE都是唯一的。
  <2>连接请求通知必须使用HTTP，而不是HTTPS。相关联的URL必须是一个“http”的URL。
  <3>Connection Request HTTP Get通知没有数据传递。CPE应该忽略可能包含的任何数据。
  <4>CPE在进行CPE之前应该使用摘要认证对ACS进行认证。不应该因为身份验证失败的请求而发起到ACS的连接。用于认证ACS的共享密钥在CPE上是可修改的参数。
  <5>CPE应该限制在给定的一段时间内接受的连接请求通知的数量，以进一步减少拒绝服务攻击的可能性。
  <6>HTTP Get到指定端口和URL的成功认证会导致CPE执行一个固定的动作:

• 该机制依赖于ACS通过CPEinitiated交互至少与CPE进行过一次事先通信。在此交互过程中，如果ACS希望允许将来由ACS发起的事务，它将读取InternetGatewayDevice.ManagementServer.ConnectionRequestURL的值
  参数。

• 如果用于管理访问的URL发生了变化，CPE必须通过发出一个通知ACS
  修改后的管理IP地址(如表33所示)，保持
  ACS最新的。

3.3 使用 SSL/TLS 和TCP

• 推荐使用SSL/TLS来传输CPE WAN管理协议，尽管该协议可以直接在TCP连接上使用。
• 如果不使用SSL/TLS，就会牺牲某些方面的安全性。具体来说，SSL/TLS提供机密性和数据完整性，并允许基于证书的身份验证来代替共享的基于秘密的身份验证。
• 使用SSL/TLS和TCP的某些限制定义如下：
  <1>如果支持SSL/TLS，则REQUIRED版本为SSL 3.0[10]或TLS 1.0[11]。
  <2>支持SSL/TLS时，支持密钥长度大于或等于的加密算法应该支持128位。
  <3>CPE必须能够向ACS发起出连接。
  <4>ACS必须能够接受cpe发起的连接。
  <5>使用SSL/TLS协议时，CPE必须使用ACS提供的证书对ACS进行认证。
  <6>如果使用SSL/TLS, ACS可以接受经过验证的cpe提供的证书来验证CPE，但是ACS必须允许SSL/TLS连接

3.4 HTTP的使用

使用HTTP 1.1[5]在CPE和ACS之间传送SOAP消息，CPE作为HTTP客户端，ACS作为HTTP服务器。

（1）在HTPP之上封装SOAP

HTTP上的SOAP编码扩展了SOAP的基本HTTP配置文件，在[8]中描述如下：
<1>从ACS发送到CPE的SOAP请求是通过HTTP响应发送的，而CPE对ACS请求的SOAP响应是通过后续的HTTP post发送的。
<2>每个HTTP post或响应可能包含多个SOAP信封(在协商的限制内)。每个信封可能包含一个SOAP请求或响应，独立于任何其他信封。
<3>当一个HTTP请求中有多个信封时，SOAPAction报头在HTTP请求必须没有值(没有引号)，表示此报头不提供关于消息意图的信息

• 通知消息包含一个名为maxenvelope的参数，该参数向ACS指示单个HTTP响应中可能包含的SOAP信封的最大数量。该参数的取值可以大于等于1。一旦收到Inform消息，来自ACS的任何HTTP响应最多可能包含这个数目的SOAP信封(请求或响应)。
• 通知响应还包含一个名为maxenvelope的参数，该参数向CPE指示单个HTTP发送中可能包含的SOAP信封的最大总数。这个参数值可以是一个或更多。收到Inform响应后，来自CPE最多可以包含SOAP信封(请求或响应)的总数。
• 在每个方向上，SOAP信封的顺序是独立于每个HTTP post/response对携带的信封数量定义的。具体来说，信封是在单个HTTP post/response中从头到尾排序，然后在连续的post/response对之间排序。也就是说，每个HTTP post/响应中的信封序列以及后续的post或响应之间的信封序列可以看作是一个信封的有序序列。
• 为了确保请求和响应之间的正确关联，请求者可以在SOAP头中包含一个ID标记，如果使用该标记，则必须在响应中以相同的值返回。这个报头的编码在3.5节中描述。
• 下面是一个来自ACS的HTTP响应示例，其中包含对先前SOAP请求的响应，其中包括一个ID头，和一个不相关的SOAP请求:

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8" 
Content-Length: xyz 
<soap:Envelope
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
 xmlns:cwmp="urn:dslforum-org:cwmp-1-0"> 
 <soap:Header> 
 <cwmp:ID soap:mustUnderstand="1">1234</cwmp:ID> 
 </soap:Header> 
 <soap:Body>
 <cwmp:Response1> 
 <argument>value</argument> 
 </cwmp:Response1> 
 </soap:Body> 
</soap:Envelope> 
<soap:Envelope
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
 xmlns:cwmp="urn:dslforum-org:cwmp-1-0"> 
 <soap:Body>
 <cwmp:Request2> 
 <argument>value</argument> 
 </cwmp:Request2> 
 </soap:Body> 
</soap:Envelope>

（2）事务会话

• 对于组成单个会话的事务序列，CPE应该维护TCP连接在整个会话期间持久化。
• 为了适应不可能维持一个连续的TCP连接的情况(例如，通过HTTP 1.0代理操作)，ACS应该使用会话cookie来维护[7]中描述的会话状态。
• ACS应该只使用标记为Discard和不应该假定CPE将在会话持续时间之后维护cookie。
  为了确保ACS可以使用会话cookie, CPE必须支持使用cookie，包括在每个后续HTTP post中返回cookie值，CPE不需要支持会话持续时间以外的cookie存储。
• 当事务会话完成时，CPE必须终止到
  ACS和丢弃所有标记为discard的cookie。

（3）文件传输

如果CPE按照ACS的来指示执行通过下载或上传文件传输，同时文件位置被指定为一个和ACS相同主机名的HTTP URL，那么CPE可以选择下列方式执行传送:
<1>CPE可以通过已经建立的连接发送HTTP get/post。一旦文件有被转移时，CPE可以继续向ACS发送额外的消息继续保持连接。
<2>CPE可以打开第二个连接来传输文件，同时维护可继续发送消息的会话。
<3>CPE可以终止与ACS的会话，然后进行转移。

• 如果文件位置不是HTTP URL或与ACS不在同一个域中，则只有后两个选项可用。

（4）认证

• 如果CPE不采用SSL/TLS认证，ACS必须采用HTTP方式对CPE进行认证。
• 如果ACS使用SSL/TLS进行加密，那么ACS可以使用基本认证[6]或摘要认证[6]；反之ACS必须使用摘要身份验证。
• ACS可以作为第一个HTTP事务的一部分发出一次身份验证，并假定在TCP连接的持续时间内保持身份验证。
• 如果ACS使用任何HTTP身份验证形式对CPE进行身份验证，CPE应该使用在所有CPE制造商中全局唯一的用户名/用户id。
  具体来说，它应该是由制造商标识符和该制造商内唯一的序列号组成的多部分字符串。这个字符串的推荐格式是:OUI- serial。
• 其中OUI是一个6个十六进制数字值，使用所有的大写字母，包括任何前导零。OUI值必须是[9]中定义的有效OUI。
• SERIAL是唯一标识来自特定制造商的CPE的字符串。
• 如果制造商有多个序列号范围重叠的CPE产品，则serial字符串必须包含额外的区分字符，以确保整个字符串是唯一的。在任何一种HTTP身份验证形式中使用的密码对于每个CPE都应该是唯一的值。也就是说，多个CPE不应该共享相同的密码。
  此密码为共享密钥，CPE和ACS都必须知道。在初始CPE安装时让两个实体都知道共享秘密的方法超出了本规范的范围(见第2.2.1节)。
• CPE和ACS都应该采取适当的步骤来防止未经授权的密码访问，或者ACS的密码列表。

3.5 SOAP的使用

CPE WAN管理协议将SOAP 1.1[8]定义为编码语法来传输附录A中定义的RPC方法调用和响应。
（1）下面描述了RPC方法到SOAP编码的映射:

• 使用SOAP 1.1 的封皮和序列化命名空间：
  封皮命名空间标识： "http://schemas.xmlsoap.org/soap/envelope/"
  序列化命名空间标识：
  "http://schemas.xmlsoap.org/soap/encoding/"
• CPE WAN管理协议的所有元素和属性都与以下命名空间标识符相关联:
  “urn:dslforum-org:cwmp-1-0”
• ：附录A中使用的数据类型直接对应于SOAP 1.1序列化名称空间中定义的数据类型。(通常，附录A中使用的类型是相应SOAP类型的受限子集。)
• 对于数组参数，给定的参数名称对应于整个数组元素的名称。
  没有为单个成员元素指定名称，因此应该按其该成员的类型来命名。例如，一个名为ParameterList的参数(它是ParameterValueStruct结构的数组)将被编码为:

<ParameterList soap:arrayType="cwmp:ParameterValueStruct[2]">
 <ParameterValueStruct> 
 <name>Parameter1</name> 
 <value xsi:type="someType">1234</value> 
 </ParameterValueStruct> 
 <ParameterValueStruct> 
 <name>Parameter2</name> 
 <value xsi:type="someType">5678</value> 
 </ParameterValueStruct> 
</ParameterList>

• 关于编码RPC方法的SOAP规范([8]的第7节)，对于附录A中定义的每个方法，方法调用中列出的每个自变量代表一个[in]参数，而方法响应中列出的每个自变量代表一个[out]参数。这里并不会使用[in/out]参数。
• 定义的RPC方法使用标准SOAP命名约定，通过在方法名中添加“Response”前缀来命名与给定方法对应的响应消息。
• 一个错误响应必须使用以下约定的SOAP fault元素:
  <1>SOAP错误代码元素必须根据特定的错误指示故障的来源，客户端或服务器。在这种用法中，Client表示SOAP请求的发起者，Server表示SOAP响应者。
  <2>SOAP faultstring子元素必须包含字符串" CWMP fault "。
  <3>SOAP细节元素必须包含一个定义在“urn:dslforumorg:cwmp-1-0”命名空间中的Fault结构。该结构包含以下元素:
  <a>一个FaultCode元素，它包含附录A中定义的单个数字故障代码.
  <b>包含人类可读的错误描述的FaultString元素。
  <c>属性的错误响应中使用的SetParameterValuesFault元素
  SetParameterValues方法，该方法包含一个或多个结构的列表，指示与错误中的每个参数相关的特定错误。该结构包含以下元素:
  <c1>ParameterName元素， 包含错误参数的完整路径名的。
  <c2>FaultCode元素，即单个数字错误码（附录A中定义），表示与错误中特定参数相关的故障。
  <c3>FaultString元素，它包含一个人们可读的错误描述，针对错误中的特定参数。
  下面是定义Fault结构的xml模式段:

<xs:element Name="Fault"> 
 <xs:complexType>
<xs:sequence> 
 <xs:element Name="FaultCode" Type="unsignedInt"/> 
 <xs:element Name="FaultString" Type="string" minOccurs="0"/> 
 <xs:element Name="SetParameterValuesFault" minOccurs="0" maxOccurs="unbounded">
 <xs:complexType> 
 <xs:sequence> 
 <xs:element Name="ParameterName" Type="string"/> 
 <xs:element Name="FaultCode" Type="unsignedInt"/> 
 <xs:element Name="FaultString" Type="string" minOccurs="0"/> 
 </xs:sequence> 
 </xs:complexType> 
 </xs:element> 
 </xs:sequence> 
 </xs:complexType> 
</xs:element> 

下面是一个包含错误响应的示例信封d：
<soap:Envelope

 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
 xmlns:cwmp="urn:dslforum-org:cwmp-1-0"> 
 <soap:Header> 
 <cwmp:ID soap:mustUnderstand="1">1234</cwmp:ID> 
 </soap:Header> 
 <soap:Body>
 <soap:Fault> 
 <faultcode>Client</faultcode> 
 <faultstring>CWMP fault</faultstring> 
 <detail> 
 <cwmp:Fault>
 <FaultCode>9000</FaultCode> 
 <FaultString>Upload method not supported</FaultString> 
 </cwmp:Fault>
 </detail> 
 </soap:Fault> 
 </soap:Body> 
</soap:Envelope>

下面是一个包含SetParameterValues方法调用的错误响应的示例封装:

 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
 xmlns:cwmp="urn:dslforum-org:cwmp-1-0"> 
 <soap:Header> 
 <cwmp:ID soap:mustUnderstand="1">1234</cwmp:ID> 
 </soap:Header> 
 <soap:Body>
 <soap:Fault> 
 <faultcode>Client</faultcode> 
 <faultstring>CWMP fault</faultstring> 
 <detail> 
 <cwmp:Fault>
 <FaultCode>9003</FaultCode> 
 <FaultString>Invalid arguments</FaultString> 
 <SetParameterValuesFault> 
 <ParameterName> 
 InternetGatewayDevice.Time.LocalTimeZone 
 </ParameterName> 
 <FaultCode>9012</FaultCode> 
 <FaultString>Not a valid time zone value</FaultString>
 </SetParameterValuesFault> 
 <SetParameterValuesFault> 
 <ParameterName> 
 InternetGatewayDevice.Time.LocalTimeZoneName 
 </ParameterName> 
 <FaultCode>9012</FaultCode> 
 <FaultString>String too long</FaultString> 
 </SetParameterValuesFault>
</cwmp:Fault>
 </detail> 
 </soap:Fault> 
 </soap:Body> 
</soap:Envelope>

• 为了将来的可扩展性，在处理接收到的信封时，ACS和CPE都必须忽略:
  (a)任何未知的XML元素3；
  (b)任何未知的XML属性及其值；
  (c)任何嵌入的XML注释；
  (d)任何XML处理指令。
• CPE WAN管理协议定义了表3中指定的一系列SOAP头元素
  <1>ID
  此头元素可用于使用每个请求的唯一标识符将SOAP请求和响应关联起来，对应的响应包含匹配的标识符。标识符的值是任意字符串，由请求者自行设置。如果在SOAP请求中使用，ID头必须出现在匹配的响应中(无论响应是成功还是失败)。因为必须支持这个头文件，所以mustUnderstand属性必须为这个头文件设置为1 (true)。
  <2>HoldRequests
  这个报头可以包含在从ACS发送到CPE的信封中，以规范来自CPE的请求的传输。这个头绝对不能出现在从CPE发送给ACS的信封中。该标签的布尔值为0 (false)或1 (true)。如果标签不存在，这将被解释为等效于0 (false)。CPE接收此报头时的行为在3.7.1.3节中定义。CPE中对此头的支持是必需的。如果ACS必须更新流控制状态，但没有其他消息要发送，它可以发送一个只包含此头和空消息体的信封。因为必须支持这个头文件，所以mustUnderstand属性必须为这个头文件设置为1 (true)。
  <3>NoMoreRequests
  这个头可能包含在ACS或CPE发送的信封中，以显式地指示收件人在会话的其余时间内是否不再发送任何请求。该标签的布尔值为0 (false)或1 (true)。如果标签不存在，这将被解释为等效于0 (false)。
  在包含最终请求的信封中或在任何后续的信封中，可以将此设置为true。一旦在会话期间设置为true，它应该在发送的其余信封中设置为true，并且发送者决不能在该会话期间发送额外的请求消息。CPE接收此报头时的行为在3.7.1.4节中定义。
  在CPE中支持传输或接收此报头是可选的。ACS接收此报头时的行为在3.7.2.4节中定义。
  在ACS中支持发送或接收这个报头是可选的。因为对这个报头的支持是可选的，所以mustUnderstand属性MUST要么不存在，要么为这个报头设置为0 (false)。
• 下面是一个消息示例，显示了所有定义的头的使用:

<soap:Envelope
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
 xmlns:cwmp="urn:dslforum-org:cwmp-1-0"> 
 <soap:Header> 
 <cwmp:ID soap:mustUnderstand="1">1234</cwmp:ID> 
 <cwmp:HoldRequests soap:mustUnderstand="1">0</cwmp:HoldRequests> 
 <cwmp:NoMoreRequests>1</cwmp:NoMoreRequests> 
 </soap:Header>
<soap:Body>
 <cwmp:Action> 
 <argument>value</argument> 
 </cwmp:Action> 
 </soap:Body> 
</soap:Envelope>

3.6 RPC支持要求

下表提供了所有方法的摘要，并指出了附录a中定义的每个RPC方法的实现是必需的还是可选的条件

CPE methods	Responding	Calling
GetRPCMethods	Required	Optional
SetParameterValues	Required	Required
GetParameterValues	Required	Required
GetParameterNames	Required	Required
SetParameterAttributes	Required	Optional
GetParameterAttributes	Required	Optional
AddObject	Required	Optional
DeleteObject	Required	Optional
Reboot	Required	Optional
Download	Required4	Required
Upload	Optional	Optional
FactoryReset	Optional	Optional
GetQueuedTransfers	Optional	Optional
ScheduleInform	Optional	Optional
SetVouchers	Optional5	Optional
GetOptions	Optional	Optional

Server methods	Calling	Responding
GetRPCMethods	Optional	Required
Inform	Required	Required
TransferComplete	Required6	Required7
RequestDownload	Optional	Optional
Kicked	Optional	Optional

3.7 交流会话程序

• 所有事务会话都必须以初始HTTP post中包含的来自CPE的Inform消息开始。这用于启动事务集，并说明CPE在消息编码方面的限制
• 当ACS和CPE都没有更多的请求发送时，会话停止，ACS和CPE都没有响应。此时，CPE可能会关闭连接。
• 一个CPE与其关联的ACS之间一次只能存在一个事务会话。
• 注意：事务会话只在有消息要在两个方向上传输时才会持久。在特定的信息交换完成后，会话及其关联的TCP连接并不打算保持打开状态。

CPE操作

（1）会话初始化
根据3.2.1节中列出的条件，CPE将向ACS发起一个事务会话。一旦与ACS的连接成功建立，CPE通过向ACS发送初始的Inform请求发起会话。
这向ACS指示CPE的当前状态，并且CPE已经准备好接受来自ACS的请求。在这个携带Inform请求的初始HTTP帖子中，只允许一个SOAP信封。
Inform响应中的maxenvelope参数表示后续HTTP发送可能携带的信封的最大数量。CPE只有在锁定了通过此接口可访问的参数，以确保不能通过任何其他机制更改这些参数时才应该发起会话。CPE应该维护这个锁，直到会话终止。
（2）即将到来的请求

• 在接收到来自ACS的SOAP请求时，CPE必须按照接收到的顺序响应每个请求，其中顺序的定义见章节3.4.1。
• 在单个HTTP发送中发送多个响应(如果ACS可以接受多个信封)，或者在多个HTTP发送中分发多个响应，不会被限制它们的顺序。
• 为了防止死锁，CPE绝对不能延迟对ACS请求的响应，以等待ACS对更早的CPE请求的响应。
  （3）即将发出的请求
• 当CPE有请求消息要发送(在初始Inform请求之后)时，它可以按照CPE向ACS发送的响应的任何顺序发送这些请求消息。也就是说，CPE可以在发送给ACS的信封序列中的任何一点插入一个或多个请求。
• CPE在接收响应之前可以发送的请求数量(未完成的请求数量)没有特定的限制。如果需要，CPE可以包含一个当地指定的限制。- 如果CPE从ACS(请求或响应)接收到一个HoldRequests头为true的信封(见3.5节)，CPE绝对不能在随后的HTTP post中发送任何请求。只有当CPE随后收到一个HoldRequests报头为false(或者相等地，没有HoldRequests报头)时，CPE才可能重新开始发送信封。
• 在确定它是否可以发送请求时，CPE必须检查通过最近的HTTP响应的结尾接收到的所有信封。由于在3.4.1节中定义的信封顺序，只有HTTP响应中的最后一个信封决定请求是否允许在下一个HTTP发送。
• 如果CPE从ACS收到一个空的HTTP响应，这可能被解释为HoldRequests等于false。如果ACS有一个或多个未完成的请求，或者CPE有一个或多个未完成的请求且HoldRequests为false，那么CPE必须在发送给ACS的任何HTTP post中发送至少一个请求或响应。

• 如果ACS没有未完成的请求或响应，则必须发送一个空的HTTP post。

  
  图片.png

（4）会话终止
CPE在一下条件发生是，必须终止会话：
<1>ACS不再发送请求到CPE情况下，假如
<a>最近的来自ACS的HTTP回应里，不包含封装;
<b>最近的来自ACS的HTTP封装内容里，包含一个NoMoreRequests 头部，并且数值为真（CPE使用这个头是可选的）；
<2>CPE不再发送请求到ACS了；
<3>CPE已经接收完所有来自ACS的的明显回应；
<4>CPE发送明显的回复信息给ACS，但是却导致优先的请求。

• 如果CPE在本地确定的时间内(不小于30秒)没有收到ACS的HTTP响应，则CPE必须终止会话。
• 如果上述条件不满足，CPE必须继续会议。
• 如果会话期间交换的一个或多个消息导致CPE需要重新启动以完成所请求的操作，则CPE必须根据上述条件等待会话完全终止后才能执行重新启动。
• 如果会话异常终止，CPE应该尝试建立新的会话，并从头开始会话建立过程。在这种情况下，CPE可能会对尝试重新建立会话的次数施加本地指定的限制。

ACS操作

（1）会话初始化

• 收到来自CPE的初始Inform请求后，ACS必须响应一个Inform响应。
• ACS可能随后向CPE发送一系列请求。
• Inform请求中的maxenvelope参数表示ACS发送给CPE的每个HTTP响应可以携带的最大信封数。
• 如果CPE可以接受多个信封，那么携带Inform响应的初始HTTP响应还可能携带附加请求，最高不超过maxenvelope规定的总限制。
  （2）即将到来的请求
• 从CPE接收到SOAP请求后，ACS必须按照接收到的顺序响应每个请求，其中顺序的定义见章节3.4.1。
• 顺序的定义对是否在单个HTTP响应中发送多个响应(如果CPE可以接受多个信封)或在多个HTTP响应中分发没有限制。
• 为了防止死锁，ACS绝对不能延迟对CPE请求的响应，以等待CPE对更早的ACS请求的响应。
• 如果ACS希望阻止CPE在会话的某个部分发送请求，它可以通过在发送给CPE的每个信封中设置HoldRequests头为true，直到ACS再次希望允许来自CPE的请求为止。ACS必须在会话完成之前允许CPE请求(这可以通过HoldRequests头显式地完成，也可以通过发送一个空HTTP响应隐式地完成)。
  （3）即将发出的请求
• 当ACS有请求消息要发送时，它可以按照ACS发送到CPE的响应的任何顺序发送这些请求消息。也就是说，ACS可以在发送给ACS的信封序列中的任意一点(在Inform响应之后)插入一个或多个请求。
• 对于ACS在接收响应之前可能发送的请求数(未完成的请求数)没有指定的限制。如果需要，ACS可以包含本地指定的限制。
• 如果ACS有一个或多个请求有待发送，并且/或CPE的一个或多个先前请求的响应未完成，那么ACS必须在发送回CPE的任何HTTP响应中发送至少一个请求或响应。只有当ACS没有更多未完成的请求或响应时，才允许使用空的HTTP响应
  （4）会话结束
  由于CPE正在驱动到ACS的HTTP连接，因此只有CPE负责连接的发起和拆除。
  当满足以下所有条件时，ACS可以认为会话终止:
  <1>CPE没有更多的请求发送到ACS，ACS会判断一下那一条为真：
  <a>有大量的最近的来袭CPE的HTTP post未包含信封；
  <b>包含信封，但是信封里的NoMoreRequests 头为真（ACS是否选择该头部是可选的）。
  <2>ACS不再有请求发送到CPE；
  <3>CPE已经发送所有的明显的回应信息到ACS，却导致了优先的请求；
  <4>ACS接收到了来自CPE的所有明显的回应信息。
• 如果以上条件没有全部满足，但是ACS没有在本地定义的不小于30秒的超时时间内收到来自给定CPE的HTTP post，则可能认为会话已终止。在这种情况下，ACS可能会尝试通过执行连接请求来重新建立会话（参见章节3.2.2）。

交互的例子

• 例子里，ACS首先读取一组参数值，然后根据结果设置一些参数值。
  （1）CPE和ACS的maxenvelope都等于1的例子
  没有来自ACS的请求管道，也没有来自CPE的每个HTTP post的多个响应。

CPE -------------------------> ACS 打开连接
CPE <==============> ACS SSL的初始化
CPE --------------------------> ACS HTTP post和Inform 请求
CPE <------------------------- ACS HTTP 回应和Infrom 回应
CPE -------------------------> ACS HTTP post
CPE <------------------------- ACS HTTP回应和 GetParameterValues请求
CPE -------------------------> ACS HTTP post和 GetParameterValues回应
CPE <------------------------- ACS HTTP回应和 SetParameterValues请求
CPE -------------------------> ACS HTTP post和 SetParameterValues请回应
CPE <------------------------- ACS HTTP回应
CPE -------------------------> ACS 关闭连接
（2）MaxEnvelopes在CPE和ACS下都为3的例子
该例子中，允许在两个方向上使用消息管道，也显示了来自ACS的一些额外请求。

CPE -------------------------> ACS 打开连接
CPE <==============> ACS SSL的初始化
CPE --------------------------> ACS HTTP post、Inform 请求
CPE <------------------------- ACS HTTP 回应、Infrom 回应、GetParameterValues 请求、ScheduleInform 请求
CPE -------------------------> ACS HTTP post、
、GetParameterValues 回应、ScheduleInform 回应
CPE <------------------------- ACS HTTP回应、SetParameterValues 请求、AddObject 请求、AddObject 请求
CPE -------------------------> ACS HTTP post、
SetParameterValues 回应、AddObject 回应、AddObject 回应
CPE <------------------------- ACS HTTP回应
CPE -------------------------> ACS 关闭连接

4、附件A：RPC方法

4.1 介绍

• 在CPE WAN管理协议中，一个远程过程调用机制用于CPE设备和自动配置服务器(ACS)之间的双向通信。
• 本附录指定了定义的特定过程调用(方法)的版本1。这包括由ACS发起并发送给CPE的方法，以及由CPE发起并发送给ACS的方法。此规范旨在独立于用于编码已定义RPC方法的语法。在CPE广域网管理协议上下文中使用的特定编码语法在第3.5节中定义。
• 前提条件：传输RPC消息的较低层提供了大多数方面的安全性，包括CPE和ACS之间的相互身份验证、机密性和数据完整性。

4.2 RPC的使用方法

数据类型

此规范中定义的RPC方法使用了缺省SOAP数据类型的有限子集
[8]。表6列出了该规范中使用的完整类型集以及用来表示这些类型的符号。
（1）string
对于本规范中列出的字符串，最大允许长度可以使用字符串(N)的形式列出，其中N是字符中的最大字符串长度。对于所有字符串，组成字符串的元素的大小可以显式地指示或暗示最大长度。
对于内容为枚举的字符串，最长的枚举值决定最大长度。如果字符串没有显式指定的最大长度或不是枚举，则默认的最大长度为16个字符。动作参数包含的字符串长度超过了指定的最大长度可能会导致无效参数错误响应。
（2）int
2147483648 ~ +2147483647(含2147483647)的整数。对于列出的某些int类型，取值范围使用int[Min:Max]的形式给出，其中Min和Max值包括在内。如果缺少Min或Max，则表示没有限制。
（3）unsignedInt
无符号整数，取值范围0 ~ 4294967295(含)。
对于列出的一些unsignedInt类型，一个取值范围使用unsignedInt[Min:Max]的形式给出，其中Min和Max值包括在内。如果缺少Min或Max，则表示没有限制。
（4）boolean
布尔值，1 = true， 0 = false
（5）dataTime
由SOAP dateTime类型定义的ISO 8601日期-时间格式的子集。除非另有明确声明，否则所有时间都用UTC(通用协调时间)表示。如果绝对时间对CPE不可用，它应该指示自启动以来的时间。例如，自启动以来的2天3小时4分5秒将表示为0000-00-02T03:04:05。
（6）base64
Base64编码的二进制文件。
允许的最大长度可以使用base64(N)的形式列出，其中N是base64编码后字符的最大长度
（7）any
包含该表中列出的任何类型的元素。
根据SOAP规范[8]，指定为这种类型的元素必须包含一个type属性，以指示元素的实际类型。例如:

<Parameter> 
 <Name>InternetGatewayDevice.ProvisioningCode</Name> 
 <Value xsi:type="xsd:string">code12345</Value> 
</Parameter>

上面使用的名称空间xsi和xsd在[8]中定义。

（8）说明

• 该规范中使用的方法还使用了结构和数组(在某些情况下包含混合类型)。数组元素在数据类型后用方括号表示。
• 如果指定，数组的最大长度将在括号中指明。如果没有指定最大长度，除非另有说明，对于接收方必须容纳的元素数量没有固定的要求。
• 如果请求的数组太大，接收者无法容纳，则应导致“参考资料”超出错误代码。

其他要求

• 所有方法都必须使用本文档中指定的确切参数数来调用。使用缺少参数或额外参数调用的方法将生成错误响应。
• 参数顺序必须与本文档中指定的相同。
• 该规范的未来版本不应该重新定义本附录中定义的RPC方法。未来版本中需要的任何更改都应该只导致定义了不同名称的新RPC方法。

4.3 RPC信息的基线

通常的方法

CPE设备和服务器均需要支持本节所列方法。一个CPE或Server可以调用这些方法。
（1）GetRPCMethods

• CPE或服务器可以使用此方法来发现与之通信的服务器或CPE所支持的方法集。
• 这个列表可能包括标准方法(在本规范或后续版本中定义的方法)和特定于供应商的方法。
• 响应的接收方必须忽略任何无法识别的方法。
• 特定于供应商的方法必须是X_<VENDOR>_MethodName格式，其中<VENDOR>是唯一的供应商标识符，可以是OUI或域名。
• OUI是[9]中定义的组织惟一标识符，必须格式化为6个十六进制数字OUI(组织惟一标识符)，包含所有大写字母和任何前导零。域名必须是大写字母，每个点“.”用连字符或下划线替换。例子：X_00D09E_MyMethod， X_ACME_COM_MyMethod。
• 这个方法的调用参数定义在表7中。响应中的参数定义如表8所示。
  <1>GetRPCMethods 参数
  为空
  <2>GetRPCMethodsResponse 参数
  MethodList
  类型为：string(64)[]
  描述：字符串数组，包含接收方支持的每个RPC方法的名称。
  例如，一个CPE只实现了这个版本规范中定义的基线方法，当服务器请求时将返回以下列表:

"GetRPCMethods" 
"SetParameterValues" 
"GetParameterValues" 
"GetParameterNames" 
“SetParameterAttributes” 
“GetParameterAttributes” 
“AddObject” 
“DeleteObject” 
“Reboot” 
“Download”

• 为CPE的响应定义了以下故障代码:9001、9002。
• 为ACS响应的这种方法定义了以下故障代码:8001、8002、8005。

CPE方法

本节中列出的方法定义为在CPE设备上支持。只有服务器可以调用这些方法。
【具体参数查看文档 31-39页的详解】
（1）SetParameterValues
设置参数的值
（2）GetParameterValues
获取参数的数值
（3）GetParameterNames
获取参数名
（4）SetParameterAttributes
设置参数名
（5）GetParameterAttributes
获取参数的属性
（6）AddObject
添加对象
（7）DeleteObject
删除对象
（8）Download
下载
（9）重启

服务器的方法

本节中列出的方法定义为在服务器上受支持。只有CPE可以调用这些方法。
【具体参数查看文档 39-43页的详解】
（1）Inform
在与ACS连接建立时，CPE必须调用Inform方法来初始化启动事务序列。这个方法的调用参数定义在表31中。响应中的参数定义在表32中。
（2）TransferComplete
-此方法通知服务器由先前的Download或Upload方法调用发起的文件传输完成(成功或不成功)。只有当关联的Download或Upload响应指出传输当时还没有完成时(通过响应中Status参数的非零值表示)，才必须调用此函数。
-在这种情况下，它可以在任何序列会话或者同一个传送已被初始化的会话中调用。当使用时，只有在传输完成(或失败)后才应该调用此方法。 CPE用这个标准来确定在传送完成的时候CPE的动作。

• 这个方法的调用参数定义在表36中。响应中的参数定义如表37所示。

4.4 可选的RPC信息

CPE方法

本节中列出的方法可能在CPE设备上被选择性地支持。只有服务器可以调用这些方法。
【具体参数查看文档 43-47页的详解】
（1）GetQueuedTransfers
服务器可以使用此方法来确定先前请求的下载或上传的状态。
（2）ScheduleInform
服务器可以使用此方法请求CPE安排一次性的Inform方法调用
(与它的定期Inform方法调用不同)。
（3）SetVouchers
服务器可以使用此方法在CPE中设置一个或多个选项凭证。
（4）GetOptions
服务器可以使用此方法来获取CPE中当前设置的选项列表及其相关的状态信息。
（5）Upload
服务器可以使用此方法使CPE将指定的文件上传到指定的位置。
（6）FactoryReset
此方法将CPE重置为出厂默认状态。使用这种方法时应格外小心。

服务器方法

在服务器上可以选择支持本节中列出的方法。只有CPE可以调用这些方法。
【具体参数查看文档 47-？页的详解】
（1）Kicked
CPE在附录D中描述的CPE被“踢开”时调用此方法。
（2）RequestDownload
这种方法允许CPE请求从服务器下载文件。在收到这一请求后
服务器可以调用Download方法来初始化下载。

4.5 错误处理

CPE的错误码

CPE可返回的故障码如下表所示。请注意，错误代码值以十进制表示。

错误码	描述
9002	内部错误
9003	无效参数
9004	资源超出(当与SetParameterValues一起使用时，这不能用于指示错误中的参数)
9005	无效参数名(与Set/GetParameterValues关联时，此参数不能用于指示错误中的参数)
9005	无效参数名(与Set/GetParameterValues, GetParameterNames,

Set/GetParameterAttributes相关联）
9006|无效的参数类型(与SetParameterValues相关联)
9007|无效的参数值(与SetParameterValues相关联)
9008|尝试设置一个不可写的参数(与SetParameterValues相关联)
9009|通知请求被拒绝(与SetParameterAttributes方法相关联)。
9010|下载失败(与Download或TransferComplete方法相关)。
9011|上传失败(与Upload或TransferComplete方法相关)。
9012|文件传输服务器鉴权失败(与Upload、Download、TransferComplete方法相关)。
9013|不支持的文件传输协议(与上传、下载方式关联)。
9800-9899|厂商定义的故障码

服务器错误码

服务器返回的故障码如下表所示。请注意，错误代码值以十进制表示。

故障代码	描述
8000	不支持方法
8001	请求被拒绝(未说明原因)
8002	内部错误
8003	无效的参数
8004	资源超过了
8005	重试请求
8800-8899	供应商提供的错误码

服务器方法的重试行为

• 如果服务器方法不成功，CPE应该重试每个服务器方法。当重新尝试一个不成功的方法调用时，CPE应该使用指数回退算法来确定重试间隔。
• 如果CPE在响应中收到“重试请求”(错误代码8005)，则必须立即重试方法调用。

5、附件B：CPE参数

5.1 介绍

本附录定义了Internet网关设备的所有CPE参数，可通过
附录a中定义的RPC参数相关方法
CPE中的必填项以及可选项。

5.2 CPE参数

• 表61列出了所有定义的互联网网关设备的参数，这些参数可以通过RPC方法SetParameterValues和GetParameterValues，以及GetParameterNames访问。
• 表定义了名称、数据类型、参数是否可写，读写参数是否为REQUIRED (R)、OPTIONAL (O)或CONDITIONAL (C)，以及描述。
• 除非另有说明，“条件”意味着如果实现了包含该参数的对象，则需要该参数。
• 参数名使用类似于目录树的层次结构形式。一个特定参数的名称由层次结构中的每个连续节点的连接用“.”表示。从层次结构的主干开始，一直到叶结点。指定部分路径时，指示层次结构中的中间节点，即末尾。“.”总是用作最后一个字符。
• 在某些情况下，一个对象可能会出现多个实例，会显示占位符节点名“{i}”。在实际使用中，该占位符将被实例号所取代，该实例号必须为正整数(>=1)。
• 对于使用AddObject方法创建的对象实例，该实例号对应于该方法在创建时返回的InstanceNumber参数。
  因为在某些情况下，对象实例也可能被删除，所以实例号通常不是连续的。
• 虽然本文档仅指定了互联网网关设备的参数列表，但一些对象预计可用于其他类型的设备。在这种情况下，每个参数的路径名应该与表61中的路径名匹配，但实际的设备类型将取代名称中的InternetGatewayDevice。
• 以下对象有望在大多数其他设备类型中使用:
  DeviceInfo
  DeviceConfig
  ManagementServer
  Time

数据类型

（1）object
参数和（或者）其他对象的容器。参数的完整路径名=object完整路径名 + 参数名。
（2）string
对于本规范中列出的字符串，最大允许长度可以使用字符串(N)的形式列出，其中N是字符中的最大字符串长度。
对于所有字符串，组成字符串的元素的大小可以显式地指示或暗示最大长度。对于内容为枚举的字符串，最长的枚举值决定最大长度。如果字符串没有显式指定的最大长度或不是枚举，则默认的最大长度为16个字符。
（3）int
整数范围为-2147483648到+2147483647，包括在内。
对于列出的某些int类型，取值范围使用int[Min:Max]的形式给出，其中Min和Max值包括在内。如果缺少Min或Max，则表示没有限制。
（4）unsignedInt
无符号整数，取值范围0 ~ 4294967295(含)。
对于列出的一些unsignedInt类型，一个取值范围使用unsignedInt[Min:Max]的形式给出，其中
最小值和最大值包含在内。如果缺少Min或Max，则表示没有限制。
（5）boolean
1 = true 0=false
（6）dataTime
由SOAP dateTime类型定义的ISO 8601日期-时间格式的子集。
除非另有明确声明，否则所有时间都用UTC(通用协调时间)表示。
如果绝对时间对CPE不可用，它应该指示自启动以来的时间。例如，自启动以来的2天3小时4分5秒将表示为0000-00-02T03:04:05
（7）base64
Base64编码的二进制文件。
允许的最大长度可以使用base64(N)的形式列出，其中N是base64编码后字符的最大长度。
（8）IP和MAC地址
所有IP地址和子网掩码都表示为IPv4点分十进制格式的字符串。注意，在这个附录中描述的参数列表中，目前没有IPv6支持。
所有MAC地址都是由12个十六进制数字(数字0-9，字母A-F或A-F)组成的字符串，以冒号分隔。

供应商自定义参数

• 供应商可以使用特定于供应商的参数和对象扩展标准化参数列表。特定于供应商的参数和对象可以在单独的命名层次结构中定义，也可以在标准化的命名层次结构中定义。
• 特定于供应商的参数或对象的名称必须具有以下形式:
  X_<VENDOR>_VendorSpecificName
• 在这个定义中，<VENDOR>是唯一的供应商标识符，它可以是OUI或域名。OUI是在[9]中定义的一个组织上唯一的标识符，它必须格式化为一个使用所有大写字母并包含任何前导零的十六进制数字字符串。
• 一个域名必须是大写字母，每个点(" . ")用连字符或下划线替换。
  VendorSpecificName必须是B.2.1中定义的有效字符串，并且不能包含"。"或空格字符。
• 注意：使用字符串“X_”来表示特定于供应商的参数意味着标准化参数不能以“X_”开头。
• 下面是一些特定于供应商的参数和对象名称示例:
  InternetGatewayDevice.UserInterface.X_00D09E_AdBanner
  InternetGatewayDevice.LANDevice.1.X_00D09E_LANInfraredInterfaceConfig.2.Status
  X_GAMECO-COM_GameDevice.Info.Type
• 在适当的情况下，供应商还可以扩展枚举值的集合。如果这样做，供应商指定的值必须是“X_<VENDOR>_VendorSpecificValue”的形式。这样一个字符串的总长度不能超过31个字符。

参数列表

【参见文档的53-90页】

6、附件C：签署凭证

6.1 介绍

• CPE WAN管理协议定义了一种可选机制，用于安全地启用或禁用可选CPE功能。与Parameters不同，Voucher机制为需要安全跟踪的可选功能(比如涉及支付的功能)提供了额外的安全层。凭证是一种数字签名的数据结构，它指示CPE启用或禁用一组选项。
• Option是CPE的任何可选功能。当一个选项被启用时，供应商可以指定不同的特征，这些特征决定了在什么条件下该选项会继续存在。

6.2 对使用凭证选项的控制

-选项可以是禁用、启用或启用过期的。

• 没有过期的启用选项将一直处于启用状态，直到服务器显式禁用它。启用了过期的期权只在凭单中指定的时间内保持启用状态。在指定的持续时间之后，CPE必须禁用该选项本身。
• 期权也可以定义为可转让或不可转让。如果没有另行指定，凭单启用的选项是不可转让的。
• 如果CPE与不同的宽带服务提供商相关联，那么non-transferable Option将被自动禁用，即使该选项是使能的，也不应该运行。CPE会维护 transferable Option 而忽略服务提供者随后发生的更改。
• 每个凭证可能包含启用或禁用一个或多个选项的指令，必须使用XML-Signature格式[13]进行数字签名。在应用凭证中的指示之前，CPE必须验证签名和签名者。
• 凭单只适用于单个CPE，不能用于凭单中所指明的CPE。这确保了用以分配凭证的机制可以用于保证只有有合适播用option的CPEs来使能那个option。
• 支持使用凭证的CPE必须支持网络时间同步协议，如NTP或SNTP，以确保访问准确的时间和日期信息。CPE接收到的凭证的申请，或者现有凭证与其到期日期的比较，应该只在CPE建立了网络时间之后才会发生。以下与凭单相关的方法在本规范的附录A中定义。
  setvoucher：允许服务器下载凭证列表到CPE。每个凭证可以启用或禁用该凭证内定义的选项。
  GetOptions:允许服务器查询CPE支持的任何或所有选项的状态。

6.3 凭证定义

• RPC方法setvoucher允许服务器启用、禁用或修改一个或多个状态选项。setvoucher方法将凭证数组作为参数。数组中的每个凭证都是分别用Base64编码的。
• 在Base64编码之前，每个凭证都是一个使用XML签名格式[13]的签名XML结构。每个独立签署的凭证可以包括一个或多个选项规范。每个选项规范都是一个为指定选项指定预期状态的结构。
• Option规范的元素定义在表62中。一个选项可能包含特定于特定选项的额外XML元素。一个示例Option规范结构如图5所示。图6显示了一个完整的签名凭证的示例。在这个例子中，在同一个凭证中启用了两个单独的选项。

指定操作的定义

【参见文档92页】
（1）VseriaNum
string(64)
识别特定凭证的唯一序列号。对于一个给定的ACS，每个新创建的凭证必须分配一个不同的凭证列号。该值在ACS管理的所有CPE和在不同时间发给给定CPE的所有凭证中必须是唯一的。
（2）DeviceId
DeviceIdStruct
这个结构体唯一标识凭证所应用的CPE。表63定义了这个结构。
在收到凭证后，CPE必须确保设备ID中的信息与它的实际身份相符。如果不是，则必须忽略凭证和响应请求拒绝错误。
（3）OptionIdent
string(64)
辨认特定操作是使能还是非使能。
（4）OpeionDesc
string(256)
操作的文档描述
（5）StartData
dataTime
属于可选的元素。选项要启用的UTC日期和时间(只有当Mode = EnableWithExpiration或
EnableWithoutExpiration)。如果此元素不存在，或者指定的时间已经过去，一个Option会被立即启用。
（6）Duration（持续）
unsignedInt
如果模式= EnableWithExpiration，则为必需。对于启用了过期的Option，此元素指定了该Option将以DurationUnits为单位保持启用的持续时间。如果指定了开始日期，则持续时间相对于该开始日期。
（7）DurationUnits
string
如果模式= EnableWithExpiration，则为必需。此元素指定duration元素所指定的单位。允许的值是:
“Days”
“Months”
（8）Mode
string
此元素指定指定的选项是启用还是禁用，如果启用，则是否指定过期时间。允许的值是：
“Disable”
“EnableWithExpiration
“EnableWithoutExpiration
（9）Transferable
boolean
可选的元素。值为true(1)表示Option被认为是可转让的，这意味着Option将一直启用到任何指定的截止日期，而不管服务提供者发生了什么变化。
如果该元素为假(0)或不存在，则该选项被认为是不可转让的，要求在服务提供商发生变更时禁用该选项，该变更与附录B中定义的规定代码的任何变更相关。

DeviceIdStruct定义

（1）Manufacturer（制造商）
string(64)
设备的制造商。此参数仅用于显示，不需要作为验证的一部分进行检查。
（2）OUI
string(6)
设备制造商的组织唯一标识符。表示为使用所有大写字母并包括前导零的6个十六进制数字值。该值必须是[9]中定义的有效OUI
（3）ProductClass
string(64)
序列号适用的产品类别的标识符。也就是说，对于给定的制造商，此参数用于标识SerialNumber参数是唯一的产品或产品类别。
（4）SerialNumber
string(64)
特定设备的标识符，对于所指示的产品类别和制造商是唯一的。

例子

（1）指定Option

<dsig:Object xmlns="" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Id="option0"> 
 <Option> 
 <VSerialNum>987654321</VSerialNum> 
 <DeviceId> 
 <Manufacturer>2Wire</Manufacturer> 
 <OUI>00D09E</OUI> 
 <ProductClass>Gateway</ProductClass> 
 <SerialNumber>123456789</SerialNumber> 
 </DeviceId> 
 <OptionIdent>Option Name</OptionIdent> 
 <OptionDesc>Option Description</OptionDesc> 
 <StartDate>20021025T12:06:34</StartDate> 
 <Duration>280</Duration> 
 <DurationUnits>Days</DurationUnits> 
 <Mode>EnableWithExpiration</Mode> 
 </Option> 
</dsig:Object>

签署凭证的例子

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
 <SignedInfo> 
 <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-
20010315"></CanonicalizationMethod> 
 <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa�sha1"></SignatureMethod> 
 <Reference URI="#option0"> 
 <Transforms> 
 <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-
20010315"></Transform> 
 </Transforms> 
 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod> 
 <DigestValue>TUuSqr2utLtQM5tY2DB1jL3nV00=</DigestValue> 
 </Reference> 
 <Reference URI="#option1"> 
 <Transforms> 
 <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-
20010315"></Transform> 
 </Transforms> 
 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod> 
 <DigestValue>/YX1C/E6zNf0+w4lG66NeXGOQB0=</DigestValue> 
 </Reference> 
 </SignedInfo> 
 <SignatureValue> 
 KAMfqOSnmGH52qRVGLNFEEM4PPkRSmMUGr2D8E3vwwW280e1Bn5pwQ== 
 </SignatureValue> 
 <KeyInfo> 
 <KeyValue> 
 <DSAKeyValue> 
 <P> 
 /X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZPY1Y+r/F9bow9s 
 ubVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fGqKYVDwT7g/bT 
 xR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAcc= 
 </P> 
 <Q>l2BQjxUjC8yykrmCouuEC/BYHPU=</Q>
<G> 
 9+GghdabPd7LvKtcNrhXuXmUr7v6OuqC+VdMCz0HgmdRWVeOutRZT+ZxBxCBgLRJFn 
 Ej6EwoFhO3zwkyjMim4TwWeotUfI0o4KOuHiuzpnWRbqN/C/ohNWLx+2J6ASQ7zKTx 
 vqhRkImog9/hWuWfBpKLZl6Ae1UlZAFMO/7PSSo= 
 </G> 
 <Y> 
 TBASA/mjLI8bc2KM7u9X6nHHvjmPgZtTBhr1/Fzs2AkdYCYMwyy+v+OXU7u5e18JuK 
 G7/uolVhjXNSn6ZgObF+wuMoyP/OUmNbSkdN1aRXXHPRsW2CcG3vjfV+Csg/LP3zfD 
 xDkImsC8LuKXht/g4+nksA/3icRQXWagQJU9pUQ= 
 </Y> 
 </DSAKeyValue> 
 </KeyValue> 
 <X509Data> 
 <X509IssuerSerial> 
 <X509IssuerName> 
 EMAILADDRESS=name@2wire.com,CN=2Wire,OU=CMS,O=2Wire,L=San\20Jose, 
ST=California,C=US 
 </X509IssuerName> 
 <X509SerialNumber>4</X509SerialNumber> 
 </X509IssuerSerial> 
 <X509SubjectName> 
 CN=eng.bba.certs.2wire.com,OU=CMS,O=2Wire,L=San\20Jose,ST=CA,C=US 
 </X509SubjectName> 
 <X509Certificate> 
MIIEUjCCA7ugAwIBAgIBBDANBgkqhkiG9w0BAQUFADCBhDELMAkGA1UEBhMCVVMxEzARBgNVBAgT 
CkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMQ4wDAYDVQQKEwUyV2lyZTEMMAoGA1UECxMD 
Q01TMQ4wDAYDVQQDEwUyV2lyZTEfMB0GCSqGSIb3DQEJARYQZWJyb3duQDJ3aXJlLmNvbTAeFw0w 
MjA5MDUyMDU4MTZaFw0xMjA5MDIyMDU4MTZaMG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTER 
MA8GA1UEBxMIU2FuIEpvc2UxDjAMBgNVBAoTBTJXaXJlMQwwCgYDVQQLEwNDTVMxIDAeBgNVBAMT 
F2VuZy5iYmEuY2VydHMuMndpcmUuY29tMIIBtzCCASwGByqGSM44BAEwggEfAoGBAP1/U4EddRIp 
Ut9KnC7s5Of2EbdSPO9EAMMeP4C2USZpRV1AIlH7WT2NWPq/xfW6MPbLm1Vs14E7gB00b/JmYLdr 
mVClpJ+f6AR7ECLCT7up1/63xhv4O1fnxqimFQ8E+4P208UewwI1VBNaFpEy9nXzrith1yrv8iID 
GZ3RSAHHAhUAl2BQjxUjC8yykrmCouuEC/BYHPUCgYEA9+GghdabPd7LvKtcNrhXuXmUr7v6OuqC 
+VdMCz0HgmdRWVeOutRZT+ZxBxCBgLRJFnEj6EwoFhO3zwkyjMim4TwWeotUfI0o4KOuHiuzpnWR 
bqN/C/ohNWLx+2J6ASQ7zKTxvqhRkImog9/hWuWfBpKLZl6Ae1UlZAFMO/7PSSoDgYQAAoGATBAS 
A/mjLI8bc2KM7u9X6nHHvjmPgZtTBhr1/Fzs2AkdYCYMwyy+v+OXU7u5e18JuKG7/uolVhjXNSn6 
ZgObF+wuMoyP/OUmNbSkdN1aRXXHPRsW2CcG3vjfV+Csg/LP3zfDxDkImsC8LuKXht/g4+nksA/3 
icRQXWagQJU9pUSjgdAwgc0wHQYDVR0OBBYEFMTl/ebdHLjaEoSS1PcLCAdFX32qMIGbBgNVHSME 
gZMwgZChgYqkgYcwgYQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMREwDwYDVQQH 
EwhTYW4gSm9zZTEOMAwGA1UEChMFMldpcmUxDDAKBgNVBAsTA0NNUzEOMAwGA1UEAxMFMldpcmUx 
HzAdBgkqhkiG9w0BCQEWEGVicm93bkAyd2lyZS5jb22CAQAwDgYDVR0PAQH/BAQDAgeAMA0GCSqG 
SIb3DQEBBQUAA4GBAF1PGAbyvA0p+6o7nXfF3jzAdoHdaZh55C8sOQ9J62IF8D1jl6JxR7pjcCp2 
iYmWkwQMncGfq+X8xP7BIqntDmIlYXuDTlXbyxXsu6lnT7nCbJwMwlLOxFwN+Axy7BM3NkAFE5Mb 
aaoJWtmD1QrvcAFfDhLeBT+tIRueK7Pq9LDS 
 </X509Certificate> 
 <X509Certificate> 
MIICeTCCAeICAQAwDQYJKoZIhvcNAQEEBQAwgYQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp 
Zm9ybmlhMREwDwYDVQQHEwhTYW4gSm9zZTEOMAwGA1UEChMFMldpcmUxDDAKBgNVBAsTA0NNUzEO 
MAwGA1UEAxMFMldpcmUxHzAdBgkqhkiG9w0BCQEWEGVicm93bkAyd2lyZS5jb20wHhcNMDEwNzMx 
MDMwNjQ5WhcNMDcwMTIxMDMwNjQ5WjCBhDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju 
aWExETAPBgNVBAcTCFNhbiBKb3NlMQ4wDAYDVQQKEwUyV2lyZTEMMAoGA1UECxMDQ01TMQ4wDAYD 
VQQDEwUyV2lyZTEfMB0GCSqGSIb3DQEJARYQZWJyb3duQDJ3aXJlLmNvbTCBnzANBgkqhkiG9w0B 
AQEFAAOBjQAwgYkCgYEA1ISJbL6i0J/6SBoet3aA8fki8s7pb/QUZueWj+0YKoDaQWh4MUCT0K06 
N/0Z2cLMVg8JyezEpdnh3lVM/Ni5ow2Mst4dpdccQQEHouqwNUWIBFU196/LPRyLjoM2NeIXSKMj 
AdPwvcenxmqeVBr/ZUmr4JQpdSI2AZJuHvCIjUsCAwEAATANBgkqhkiG9w0BAQQFAAOBgQBa3CCX 
ga9L0qrGWxpNj312Az+tYz8bpEp2e2pAVrJHdW/CJ0uRlE341oTkhfYFa5CuuieF7Jcwf1B3+cGo 
JrLWqeKqsNnrbmMFC/9hnrLlgZKEKi0POaGSFS/Pw9nodGWFZCiaQmeG+J6CWeASiFMdwgRGvESW 
axfzzIKiXsXwkA== 
 </X509Certificate> 
 </X509Data> 
 </KeyInfo> 
 <dsig:Object xmlns="" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Id="option0"> 
 <Option> 
 <VSerialNum>987654321</VSerialNum> 
 <DeviceId> 
 <Manufacturer>2Wire</Manufacturer> 
 <OUI>00D09E</OUI> 
 <ProductClass>Gateway</ProductClass> 
 <SerialNumber>123456789</SerialNumber> 
 </DeviceId> 
 <OptionIdent>First option name</OptionIdent>
<OptionDesc>First option description</OptionDesc> 
 <StartDate>20021025T12:06:34</StartDate> 
 <Duration>280</Duration> 
 <DurationUnits>Days</DurationUnits> 
 <Mode>EnableWithExpiration</Mode> 
 </Option> 
 </dsig:Object> 
 <dsig:Object xmlns="" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Id="option1"> 
 <Option> 
 <VSserialNum>987654322</VSerialNum> 
 <DeviceId> 
 <Manufacturer>2Wire</Manufacturer> 
 <OUI>00D09E</OUI> 
 <ProductClass>Gateway</ProductClass> 
 <SerialNumber>123456789</SerialNumber> 
 </DeviceId> 
 <OptionIdent>Second option name</OptionIdent> 
 <OptionDesc>Second option description</OptionDesc> 
 <StartDate>20021025T12:06:34</StartDate> 
 <Duration>280</Duration> 
 <DurationUnits>Days</DurationUnits> 
 <Mode>EnableWithExpiration</Mode> 
 </Option> 
 </dsig:Object> 
</Signature>

7、WEB身份管理

7.1 介绍

• 支持基于web的应用程序或其他CPE-related网页后端web站点访问从浏览器中CPE本地网络。
• CPE广域网管理协议提供了一个可选的机制,允许这样的网站来定制他们的内容与客户与CPE的显性知识。也就是说，用户在CPE局域网内浏览的位置可以自动识别，无需任何手动登录过程。
• 该协议定义了一组可选的接口，允许网站发起CPE和ACS之间的通信，这允许与ACS通信的网站识别用户在哪个CPE后面操作。这允许网站定制其内容，以特定于关联的宽带帐户、特定类型的CPE或ACS知道的任何其他特征。
• 注意，这种识别机制并不区分同一个CPE背后的同一网络上的不同用户。在需要识别特定用户的情况下，将需要一个独立的身份管理机制，例如手动登录

7.2 使用被驱逐的RPC方法

• CPE WAN管理协议在附录A中定义了一个可选的kicked RPC方法，它可以用来支持web身份管理功能。
• CPE对kicked方法的调用是由对CPE的外部刺激发起的。这种外部刺激被认为是基于网络的，因此相关的方法提供了一种在基于网络的交易中有用的信息交流方法。D.4节给出了刺激界面的建议定义。
• kicked方法调用中包含的信息既包括唯一标识CPE所需的信息，也包括可用于将方法调用与特定web浏览器会话关联起来的参数。
• 对kick方法的响应允许服务器指定浏览器应该重定向到的URL。这个URL可能包含CGI参数，允许服务器继续跟踪浏览器会话。

7.3 WEB身份管理程序

（1）Web身份管理机制基于一种模型，在这种模型中Web服务器与ACS相关联并可以与ACS进行通信。每当此web服务器希望识别用户的CPE或使CPE为其他目的与ACS建立通信时，就会发生以下事件序列(在正常情况下):
<1>用户的浏览器访问的网页需要了解用户的CPE或与用户的CPE进行通信。
<2>该网站将浏览器重定向到一个只能从CPE的私有网络访问的特定URL(LAN)接口，浏览器通过该接口“踢”CPE，通过CGI参数向CPE提供执行后续步骤所需的信息(参见D.4节)。
<3>CPE通知ACS它已经被踢出，使用定义中的“踢出”RPC方法调用附录A.在这个方法调用中，CPE识别自身并传递信息来唯一地识别浏览器会话。
<4>ACS通过传递一个URL来响应这个方法调用，CPE应该重定向用户的浏览器。这个URL通常包含标识会话状态的CGI参数。当连接打开时，ACS还可以启动任何其他适当的RPC事务。
<5>CPE通过将浏览器重定向到ACS指示的URL来响应浏览器的HTTP请求。
（2）

• 这个交换允许ACS唯一地标识CPE;可能会根据特定用户的知识、他们的设备和任何关联的帐户特权生成自定义页面;然后将用户引导到定制页面。
• 对于特定的用户操作，ACS还可以启动任何其他RPC事务。例如，如果用户请求从web页面升级到他们的CPE, ACS可以指示CPE在ACS响应kick方法调用的同一连接上发起文件下载。

（3）例子

图片.png

7.4 LAN侧的接口

CPE可以通过提供一个局域网端web URL来支持web身份管理，该URL可以通过本地网络上的浏览器访问。
CPE中的相关web服务器应该支持CGI参数传递给附录a中定义的kick RPC方法中的相应参数。推荐的参数列在表64中。
（1）推荐用于kick URL的CGI参数
<1>command
string(32)
在kick方法调用的Command参数中传递的值。这个CGI参数允许ACS识别它要执行的命令，以响应所产生的kicking方法调用。
<2>arg
string(256)
在kick方法调用的Arg参数中传递的值。ACS可以使用这个CGI参数为相应的命令传递参数。这个参数的特定用途没有定义。
<3>next
string(1024)
要在kick方法调用的Next参数中传递的值。这包含网站希望浏览器在踢出过程完成后发送的URL。ACS处理。kick方法可能覆盖这个请求，并在kick响应中返回一个不同的URL。
（2）

• 要启动kick进程，浏览器将被发送到CPE的URL，例如通过HTTP 302重定向或通过表单post。这种访问将包括表6中定义的CGI参数。例如，浏览器可能会被重定向到:

http://cpe-host-name/kick.html?command=<#>&arg=<arg>&next=<url>

CPE收到相应的HTTP GET请求后，CPE应该发起一个kicking方法调用，使用CGI参数填写附录a中定义的方法参数。
CPE应该将每小时发送给ACS的kick方法调用的数量限制为一个定义的最大值。接收会导致超过这个最大值的kick请求被认为是安全违规，不应该导致调用kick方法。

8、签名包的格式

8.1 介绍

• 本文档指定了一种可用于将文件安全地下载到接收设备的签名包格式。这种格式允许将一个或多个文件封装在单个签名包中。
• 包格式允许接收方对源进行身份验证，并包含用于接收方提取和安装内容的说明。
• 经过签名的包格式用于通过HTTP、HTTPS或FTP文件传输从服务器下载，或通过远程或本地源的其他文件传输方式下载。

8.2 签名包格式结构体

包格式

（1）固定长度的头
报头是一个固定长度的结构，包括序言、格式版本以及命令列表和有效负载组件的长度
（2）命令列表
命令列表包含在提取和安装包中包含的文件时要遵循的一系列指令。
每条命令都采用TLV (type-length-value)形式。
（3）签名
包的这一部分包含一个PKCS #7数字签名块，其中包含一组如E.5所述的零个或多个数字签名。
（4）负载文件
软件包的这一部分包含一个或多个要按照命令列表中的说明安装的文件。
本文档没有定义任何特定的有效载荷文件格式。

编码环境

除非另有明确说明，以下编码约定贯穿本规范:
（1）多八位数字值以网络字节顺序编码(大端字节格式)。
（2）文件或目录路径名以UNIX格式指定(例如:“/dir/dir/base.ext”)。

8.3 头部格式

有签名的包头是一个固定长度的24字节结构。标题的格式定义在表66。
（1）Preamble（序言）
8字节
包含以下十六进制值的固定八位序列:
32 57 49 52 45 5f 53 50
经过签名的包格式的解释器必须验证该前缀是否包含此值序列，这样才能认为该包有效。
（2）Major version
32位的整形数据
一个包含报文格式版本的主要部分的数值。符合此规范的实现的主要版本为1。更换为主版本表示此格式的不完整更改。
（3）Minor version
32位的整形数据
该数值表示包格式版本的次要组件。符合此规范的实现有一个小版本0(0)。
对次要版本的更改表示对包格式的兼容更改。实现该规范版本的实现应该能够解释使用具有不同次要版本值的格式编码的包
（4）Command list length
32位的整形数据
命令列表的长度
（5）Payload length
32位的整形数据
负载的长度

8.4 命令列表的格式

格式
（1）Type
32位的整形数据
指定特定的命令
（2）Length
32位的整形数据
指定Value字段的长度(以字节为单位)。该命令的总长度为length + 8个字节。
（3）Value
数据格式看情况
与特定命令类型相关的零个或多个参数字节。

命令类型

• 命令列表包含两种类型的命令：包参数和要执行的操作。
• 包参数的示例包括包含的软件映像的软件版本或下载剩余部分的超时。
• 操作示例包括添加、删除和移动。
• 一起采取的行动命令列表中指定的顺序定义了提取和安装所包含文件所需的文件系统的修改顺序。
• 与文件相关的命令有两个变体：一个操作显式文件，另一个操作版本化文件。

• 版本化文件的名称有一个长度为8个字符的固定基数，以及一个长度为3个字符的扩展名。每次更新版本化文件的内容时，文件扩展名将更改为指示文件版本的新值。因此，如果升级需要替换版本化文件，则必须删除具有相同基本名但不同扩展名的任何现有文件。
  表68列出了该规范定义的具体命令：

  
  图片.png

结束命令

该命令表示命令列表的结束。此命令不需要出现在命令列表中，但如果遇到，收件人必须停止解析包的命令列表部分的其余部分。
该命令的Length参数必须为0(零)，表示后面没有Value字段。

提取和添加命令

• extract和add命令包括extract File、extract versionedfile、add File和add versionedfile。
• 提取命令指示接收者删除任何同名的现有文件，并将其替换为有效负载中的指定文件。
• add命令指示收件人首先检查同名的现有文件，只有在没有找到现有文件时才安装新文件。对于这些命令的版本化文件变体，上述操作将现有文件视为与指定文件具有相同基名的任何文件。
• 也就是说，Extract versionedfile命令在安装新文件之前删除所有具有相同基名和扩展名的现有文件。
• 类似地，Add Versioned File命令检查与指定文件具有相同基名的任何文件，而不管扩展名如何，并且只在找不到这样的文件时安装新文件。当在一个不存在的目录中创建一个新文件时，收件人必须创建所需的目录。所有的提取和添加命令都包含命令的Value部分中的信息。这些信息的格式定义在表69中。
  （1）flag
  32位整形数据
  位域定义如下:
  第0位(LSB):不安全标志。该标志的1(1)值表示如果此命令成功完成，但命令列表中的后续命令失败，接收设备将处于不安全状态，并且
  应该遵循其程序将其文件系统恢复到已知的安全状态。
  所有其他位被保留并且必须被设置为0(零)并且必须被接收者忽略。
  （2）Path Offset
  32位整形数据
  在此命令中，从Value字段开始到Path字段的偏移量，以字节为单位
  （3）Path Length
  32位整形数据
  Path字段的长度(以字节为单位)。
  （4）Hash Type
  32位整形数据
  创建哈希字段时使用的哈希算法类型。当前定义的值如下:
  1 = SHA-1。当设置为该值时，哈希字段包含指定文件的SHA-1哈希值。这种情况下的哈希长度值必须设置为20(小数)。保留所有其他值。
  （5）Hash Offset
  32位整形数据
  在此命令中，从Value字段开始到Hash字段的偏移量(字节)。
  （6）Hash Length
  32位整形数据
  哈希字段的长度(以字节为单位)
  （7）File Offset
  32位整形数据
  从包的有效负载部分开始到指定文件开始的偏移量(以字节为单位)。
  （8）File Length
  32位整形数据
  文件有效负载的长度(以字节为单位)。文件的实际内容可以在包的文件有效负载部分中找到
  （9）Path
  String ，长度为 Path的长度
  定文件的路径，包括目录树和文件名。
  （10）Hash
  八进制string 长度为Hash长度
  负载文件的哈希值，使用哈希类型字段中定义的哈希算法。负载文件的散列包含在命令中，因为签名只验证包头和命令列表。通过在命令中包含文件哈希值，签名保证了文件内容的有效性。

删除命令

删除命令包括删除文件、删除版本文件和删除子树。

• 如果文件存在，则删除指定路径下的文件。
• 删除版本化文件命令删除与指定文件具有相同基值的所有文件，无论扩展名如何。
  删除子树命令删除指定路径下的所有文件和目录，包括指定路径。
• 所有的remove命令都包含命令的Value部分的信息。表70定义了这些信息的格式。
  （1）Flags
  32位整形数据
  位域定义如下:
  第0位(LSB):不安全标志。该标志的1(1)值表示如果此命令成功完成，但命令列表中的后续命令失败，接收设备将处于不安全状态，并且
  应该遵循其程序将其文件系统恢复到已知的安全状态。
  所有其他位被保留并且必须被设置为0(零)并且必须被接收者忽略
  （2）Path Offset
  32位的整形数据
  在此命令中，从Value字段开始到Path字段的偏移量，以字节为单位。
  （3）Path Length
  32位的整形数据
  ath字段的长度(以字节为单位)。
  （4）Path
  String，长度为Path的长度
  指定文件或目录的路径

移动命令

• move命令包括move File和move versionized File。
• Move File命令将文件重命名为此命令中指定的名称。如果指定的目标路径指示不同的目录，则将文件移动到指定的目标目录。
• Move Versioned File命令移动与源路径中指定的文件基名匹配的文件，而不管扩展名是什么。
• 如果指定目录下存在多个这样的文件，则只移动其中一个文件，删除其他文件。
• 如果版本文件扩展名字符串是十进制数，则移动编号最低的文件，删除其余文件。
• 在所有情况下，如果已经有一个文件与指定的目标文件具有相同的路径，则move命令将覆盖该文件。如果move命令中指定的源文件不存在，则不采取任何操作，接收者继续处理命令列表中的其余命令。所有的移动命令都包含命令的Value部分的信息。
• 这些信息的格式定义在表71中。
  （1）Flag
  32位的整形数据
  位域定义如下:
  第0位(LSB):不安全标志。该标志的1(1)值表示如果此命令成功完成，但命令列表中的后续命令失败，接收设备将处于不安全状态，并且应该遵循其程序将其文件系统恢复到已知的安全状态。所有其他位被保留并且必须被设置为0(零)并且必须被接收者忽略。
  （2）Source path Offset
  32位的整形数据
  在此命令中，从“值”字段开始到“源路径”字段的偏移量(以字节为单位)。
  （3）South Path Length
  32位的整形数据
  源路径字段的长度(以字节为单位)。
  （4）Destination Path Offset
  32位的整形数据
  在此命令中，从“值”字段开始到“目的路径”字段的偏移量(以字节为单位
  （5）Destination Path Length
  32位的整形数据
  目的路径字段的长度(字节)。
  （6）Source Path
  String，长度为 Source Path Length
  源文件的长度。
  （7）Destination Path
  String， 长度为Destination Path Length
  源文件要移动/重命名到的目标路径。

版本和描述命令

• Version和Description命令的Value字段都包含一个用于信息、显示或日志记录目的的UTF-8字符串。
• Version字段用于指示与包关联的整体版本。例如，如果包包含一个软件升级(可能包含许多单独的文件)，则Version字段可能用于指示与升级相关联的新软件版本。

超时命令

• timeout命令包括“Initial timeout”、“Initial Activity timeout”、“Recoverable timeout”和“Unrecoverable timeout”。
• timeout命令为在终止下载之前继续下载包文件指定一个超时值。这些命令适用于以下情况：在下载包文件的其余部分之前，先下载并解释包的命令和签名部分。
• timeout命令可用于控制与此类下载进程相关联的超时参数。
• 如果在解释包内容之前下载或接收整个包，则timeout命令可能会被忽略。
• 每条超时命令的“值”部分都包含相关信息。
• 这些信息的格式定义在表72中。
• Timeout
  32 位的整形数据
  相对于包下载操作开始时的超时值(以秒为单位)。值为0(0)表示无限超时
• 每个超时命令都允许指定不同的超时值，其中该命令中的timeout字段表示所需的值。
• 每个超时值的使用都基于接收方的状态，因为它使用图9所示的状态转换模型处理命令。该图显示了按顺序处理命令列表中的每个命令时发生的状态转换。对于所处理的每个命令，状态保持不变，直到出现状态转换箭头指示的一种情况。

• 状态图

  
  图片.png

上面的状态图用于在下载期间确定使用哪个超时值。与timeout命令相关联的每个超时类型的定义如表73所示。
（1）Initial Timeout
初始化超时
（2）Initial Activity Timeout
初始化活动的超时
（3）Recoverable Timeout
可恢复的超时
（4）Unrecoverable Timeout
不可恢复的超时

重启命令

此命令指示收件人重新启动以完成安装过程。如果使用，该命令必须是命令列表中的最后一个命令(End，如果存在)。
该命令的Length参数必须为0(零)，表示后面没有Value字段。

格式化文件系统

此命令指示收件人在安装过程中重新格式化其文件系统。如果使用此命令，则意味着文件系统中的所有现有文件(或与安装过程相关的文件系统部分)将被清除，并由包中的新文件覆盖。
该命令的Length参数必须为0(零)，表示后面没有Value字段。

最小和最大版本命令

• 最小版本号和最大版本号命令用于指定应用软件包的软件版本号范围。
  -当使用这些命令在包中指定了最小和/或最大版本号时，如果接收方的软件版本不在指定的范围内，则接收方绝对不能安装文件或采取命令列表中指定的任何其他操作。

• 只有当与收件人相关联的实际软件版本的格式是分层格式时，才可以使用此命令，这种格式可以根据下面列出的程序进行数字比较。最小版本命令和最大版本命令的“值”部分包含信息。

• 表74定义了这些信息的格式。

• Version
  32位整形数字的数组
  一个表示版本号的整数元素数组。这被认为是一个分层版本号(例如，“1.0.20.3”)，其中每个连续的整数表示版本号中更小的元素

• 以下过程用于确定一个版本是否在指定的范围内。
  如果给定了最小版本，那么对于Version数组中的每个元素，从第一个(最主要的元素)开始:
  （1）如果收件人的实际版本的该元素大于最小版本的对应元素，则收件人的版本满足要求，过程完成。
  （2）如果收件人的实际版本号的这个元素小于最小版本的对应元素，则收件人的版本不满足要求。在本例中，该过程已经完成，收件人绝对不能安装此包中的文件或遵循任何其他命令。
  （3）否则(值相等)，
  <1>如果这是数组中的最后一个元素，则接收方的版本满足要求，过程就完成了。
  <2>否则(还剩下更多元素)，该过程应该在第1步使用数组的下一个元素继续进行。

• 如果给出了Maximum Version，那么对于Version数组中的每个元素，从第一个(最主要的元素)开始:
  （1）如果收件人的实际版本的该元素小于最大版本的对应元素，则收件人的版本满足要求，过程完成。
  （2）如果收件人的实际版本号的这个元素大于最大版本的对应元素，则收件人的版本不满足要求。在本例中，该过程已经完成，收件人绝对不能安装此包中的文件或遵循任何其他命令。
  （3）否则(两个值相等)，
  <1>如果这是数组中的最后一个元素，则接收方的版本满足要求，过程完成。
  <2>否则(还剩下更多元素)，该过程应该在第1步继续使用数组的下一个元素。

角色命令

• role命令用于指示包的目标应用程序或用途。这是为了表明任何副作用或后处理可能需要为一个特定的包。
• 角色命令包含命令的“值”部分的信息。这一信息的格式见表75。
• Role
  32位整形数据
  指示包的目标应用程序或用途的枚举。定义如下值:
  1 =软件升级
  2 =软件恢复
  3 = Web内容
  4 =厂商配置
  以0xFF作为其最重要八位的值将被解释为特定于供应商的角色。在本例中，后面的三个八位包含OUI
  (组织唯一标识符)标识[9]中定义的供应商。当使用此值时，供应商可能会在此命令中定义随后的附加参数，以便具体标识角色。

最小存储命令

• 最小存储命令包括“最小Volatile storage Size”和“最小Non-Volatile storage Size”存储大小。
• 最小存储命令表明接收设备能够安装包中包含的文件的最低要求。如果存在，每个命令都表示对命令名所表示的存储类型的最低要求。
• 如果接收设备不满足指定的最低要求，接收设备绝对不能安装包中的任何文件或继续处理命令。
  最小存储命令包括信息
• Storeage Size
  32位的整形数据
  命令所指示的类型所需的最小存储空间(以字节为单位)。

请求属性命令

• Required Attributes命令用于指定接收设备所需的其他属性，以便认为包在安装时有效。
• 单个包中可能包含一个或多个Required Attributes命令，每个命令指示所需的不同类别的属性。
• “必选属性”命令包含命令“值”部分的信息。
• 这些信息的格式定义在表77中。
  （1）Defineg Entity
  32位的整形数据
  指示此命令中使用的Class和Attribute值的定义者的标识符。定义了以下值:值为0(0)表示标准的Class和Attribute定义。
  标准定义是由本规范的本版本或未来版本定义的。以0xFF作为其最重要八位的值表示特定于供应商的类和属性定义。在这种情况下，后面的三个字节包含OUI(组织唯一标识符)，标识[9]中定义的供应商。如果接收方使用它不能识别的定义实体值处理Required Attributes命令，则应该忽略该命令并继续处理后续命令。
  （2）Class
  32位的整形数据
  一种枚举，指示与接收方进行比较以确定此包是否适合于该设备的标准。
  对于给定的条件，属性数组字段指示与该条件相关联的特定允许值。
  在这个版本的规范中，没有定义标准的类值。对于特定于供应商的定义实体，类值的解释也是特定于供应商的。
  如果接收方使用它不认识的类值处理Required Attributes命令，则应该忽略该命令并继续处理后续命令。
  （3）Attribute Array
  32位整形数据为元素的数组
  变长数组属性，其中每个属性是特定类的特定允许值的枚举。
  如果与接收设备关联的实际值与此数组中列出的任何值相匹配，则接收方满足指定的要求。否则，接收方不符合要求，不能安装该包。
  在这个版本的规范中，没有定义标准属性值。对于特定于供应商的定义实体，属性值的解释是特定于供应商的。

8.5 签名

签名部分紧跟着包文件的命令列表部分。签名部分由一个使用PKCS #7签名语法[14]的数字签名块组成。
特别地，签名块只包含一个PKCS #7 SignedData对象，它包含0个或多个签名，并且有以下约束:
（1）签名是“外部签名”，这意味着已签名的消息没有封装在SignedData对象中。相反，已签名的消息数据由包的头和命令列表组件构成的八位字符串组成。
（2）contentInfo的contentType元素必须指明类型“data”。
（3）contentInfo的content元素必须为空，因为这是一个外部签名，消息数据驻留在签名本身之外。
（4）每个签名使用的摘要算法必须是SHA-1类型。
（5）每个签名使用的digestEncryptionAlgorithm必须是RSA类型。
（6）Tag值表示与整个SignedData对象关联的标识符必须小于或等于30，导致标识符的单字节编码。
（7）如果签名块中没有签名，则没有扩展的证书或证书撤销列表，SignerInfo集将为空，digestAlgorithms集可能为空。
SignedData中的所有其他字段必须正常显示。
请注意，空签名块的内容独立于包的内容，因此可以预先计算为固定的字节序列。

• 如果签名块包含多个签名，则必须成功验证至少一个签名，以便接收方认为已签名的包是受信任的。 如果包接收方期望有一个或多个签名，则接收方必须在处理命令列表中包含的命令之前验证签名。如果没有验证包含的签名，接收方绝对不能处理命令列表中的任何命令或安装包中包含的任何文件。如果接收方实现的命令列表验证和处理应该在没有从源文件加载整个包文件的情况下完成，则接收方可以假定头、命令列表和签名块的合并长度不大于150kb。
• 请注意，尽管已签名的消息数据只包括包头和命令列表，但签名保证了整个包的完整性，因为所有引用有效负载文件的命令都包括文件内容的散列。
• 还需要注意的是，除了签名块本身之外，无需修改文件的任何部分，就可以将额外的签名添加到已签名的包文件中。
• 包格式的结构是这样的：如果签名块的长度改变，包文件的其他内容(头、命令列表和有效负载)不需要改变。