其他TR-069相关名词
TR-069里的NAT穿透
这里首先要说一下,TR-069标准的交互场景,主要是基于ACS和CPE能够互相找得到对方的前提下进行的。通常会要求ACS和CPE双方都拥有公网IP,这样才能保证ACS下发的命令能够到达CPE端。
图1 - 通常情况下的TR-069拓扑
但有些地区的ISP往往会遇到公网IP不足只能使用CGNAT,亦或者是他们需要管理一连串多个CPE(比如Mesh组网)的情况,这种时候ISP便需要借助一些用于NAT穿透的协议来达到管理目的。STUN和XMPP便是里面的代表。
图2 - 有NAT设备的TR-069拓扑
STUN
STUN,全名是Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators,是在 RFC 3489 中公布的一组标准化方法,它允许应用程序发现它们与公共互联网之间的 NAT 设备或防火墙的存在,并且判断出NAT的类型。
后来,在 RFC 5389 中进行了更新,保留了许多原始规范作为方法子集,但删除了其他一些规范,其名字也被改成了Session Traversal Utilities for NAT。
RFC 5389 - Session Traversal Utilities for NAT (STUN)
STUN交互采用classicstun和UDP报文,全程均采用明文,安全性相比XMPP来说比较低。
STUN通信时需要有STUN客户端和STUN服务器,STUN客户端内嵌在CPE的程序中,作为一个功能使用,而STUN服务器则部署在ACS的网络环境中,双方通过进行STUN Binding来保持链路畅通(也就是我们常说的"保活")。
XMPP
XMPP,全名是Extensible Messaging and Presence Protocol(旧名叫做Jabber),是一种开放式的通信协议。它基于XML格式,支持两个或多个网络组件之间近乎实时地交换结构化数据。
它的定义内容主要包含于下方一系列文档:
- RFC 3920(已被 RFC 6120 取代)
- RFC 3921(已被 RFC 6121 取代)
- RFC 3922
- RFC 3923
- RFC 4622(已被 RFC 5122 取代)
- RFC 4854
- RFC 4979
- RFC 6122(已被 RFC 7622 取代)
其中最广泛使用的是下面的三个:
RFC 6120 - Extensible Messaging and Presence Protocol (XMPP): Core
RFC 6121 - Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
RFC 7622 - Extensible Messaging and Presence Protocol (XMPP): Address Format
和STUN相同,XMPP通信时也需要有XMPP客户端和XMPP服务器,XMPP客户端内嵌在CPE的程序中,作为一个功能使用,而XMPP服务器则部署在ACS的网络环境中,双方通过XMPP的正常通信来维持链路的畅通。
Option 43
DHCP Option 43,这是DHCP报文里的一个字段,在官方文档RFC2132中定义为用于传输Vendor特定信息的字段。
在ISP网络设备中,它常被用于给样机提供TR-069的配置信息。
也就是说,CPE在向DHCP Server获取IP地址时,DHCP Server会将ACS的信息也一并传递给CPE。
配合Option 43,Zerotouch的场景也就变得更加丰富了。终端用户家里的CPE无需提前进行ACS信息的配置,只需连上DHCP Server获取IP和Option 43后,CPE便可了解ACS的地址并向其发送交互信息。
图3 - Option 43示意图
那么关于TR-069的基本介绍就到这里告一段落了,后面会开始介绍一些详细的TR-069报文交互,如果有兴趣的话,不妨点个小小的订阅,也欢迎大家积极发言,我们一同讨论更多的技术知识~