[はじめに]
[オリジナル] *この論文は、それが「テレメトリ」それと呼ばれる理由リモートセンシング、ネットワークテレメトリのネットワークは、？私の個人的な理解では、データネットワークは、実際にネットワークデータを収集する手段である「コレクション」のようなものになるということです。必要性のためには、我々は、リモートセンシング技術でちょうど主流のネットワークのリモートセンシング技術について話をするこの記事をネットワークの数に連絡しました。代表とIETF IPFIX標準は、最近人気のある技術のINTに、INTテクノロジーは、シスコとHuawei社PBT IOAMをハイライト表示されますので、この記事では、CiscoのNetflowの技術へのリモートセンシング技術の「流れ」に基づく伝統的なネットワークをご紹介します2種類。
[シーン]
リモートセンシングネットワークは、目的は、ネットワーク上の収集情報にある、ネットワークトラフィック分析のいくつかの技術的な事実は、ネットワークの自動化を監視したり、トラブルシューティングを行うことができます必要な大規模ネットワーク、問題を解決することはより困難、ネットワーク情報技術の集合体であります「休憩」、そしてより多くのニーズのセットを達成するために監視し、検出ネットワーク実装、およびネットワーク技術のリアルタイム監視するDCNネットワーク（データセンターネットワーク）への手段を必要とし、リモートセンシングのネットワークが誕生の問題を解決するために使用されます一つの技術。リモートセンシングネットワークは、一般に2つのタイプ、すなわち、受動的および能動的検出プローブに分割されます。シスコとパッシブ検出のNetFlow代表として技術、およびアクティブ検出は、マイクロソフトに最も類似しているEverflowにおけるプローブガイド付きのVMware仮想ネットワークとHuaweiのFusionNetDoctorの代表としてだけでなく（代表Traceflowコンポーネントは、当然のことながら、Huawei社はビット低いを行います...）本当のことを言います。
アクティブ検出[]
アクティブ検出は、定義によって、導かれたプローブのマイクロソフトEverflow代表へのシステムのための「イニシアチブは、ネットワークの状態を検出するために、」アセンブリで2016年のMicrosoftの代表としてSIGCOMM大でパケットレベルテレメトリ」と題する論文を発表しましたパケットレベルのMicrosoftのセットを達成するためのリモートセンシング技術のネットワークを記述するデータセンターネットワーク「の記事は、興味を持って、私は個人的に記事を書くために非常に良い感じ、Googleに行くことができます。これはと呼ばれる重要なコンポーネントと呼ば「導かれたプローブ」、それから導かれたプローブは、それを行うために使用されていますか？
図1.典型的な仮想ネットワーク・トポロジ
図1は、仮想ネットワークの典型的なトポロジーであり、仮想マシンA、仮想マシンBは、3つの仮想スイッチを通過する必要がある2つの仮想ルータは、モーメントがいるとする「発生している」 A B「がトリップ」が発生した仮想マシンに仮想マシンをAどこの仮想マシントラフィックBに仮想マシンを引き起こし、どのように障害それの具体的な故障箇所や原因を特定するには？
Microsoftのガイド付きプローブとVMware traceflowはこの事を行うことです。導かれたプローブVM A「がプローブパケットに注入 『および多数の設定』 NEに検出および認識ポイント」であろう、パケットのそれぞれは、図1のようなネットワーク要素のステータス情報を介してアップロードされます。2。
図2能動一の実施プロービング
一例として、私は「プローブ識別ポイント」を介して各ネットワーク要素の入力および出力における「検出と認識点」の数、「プローブパケット」を提供している2は、それが仮想Aへの仮想マシンと仮定され、制御装置にステータス情報をアップロードします3、マシンの仮想スイッチ入力Bは、情報が最終的なアップロード「3 OUT仮想スイッチ」を欠落され、失敗し、コントローラは、障害の存在を決定することができる仮想スイッチ3で「起こっている」、それがすることができますノーザンにより、チャネルに管理プレーンを通知する管理プレーンと、ユーザ、または直接警報を知らせます。
データプレーンは、独自の研究開発である場合は、「トリップ発生バックグラウンドトラフィックの特定の部分の」知覚することができる場合はもちろん、また、より多くのそれよりも、それから、最大の遊びがあり、「流れ」SRC IP（識別5タプルであってもよいし、 DST IP、SRCポート、DSTポート、L4プロトコルまたは）はTOSを追加するとき、私はバックグラウンドトラフィックに「ブレイク」で構築テンプレートとしてバックグラウンドトラフィックの「枯渇」を取る、注入プローブパケットになります同じアクティブ、データパケットをプローブパケット損失は、データプレーンは、独自の研究開発である場合、それはデータ・プレーンを転送できる「プローブ識別点」に設けられ、切り欠きのみならず背景が流れ特定ブレーカを知っているように見えます位置は、また、アップ乾燥なぜ、ユーザが伝えることができる「XXX物品が遮断流れ現れ、XXXの位置で、xxxは損失インタラプタ理由で」知っている、例えば、図3は、VMware Traceflowの結果を示すグラフです。
図3.VMWareの図Traceflowの使用効果
上記のプロセスのほとんどは正の検出を達成することである、マイクロソフトEverflow、VMwareのTraceflowとHuaweiのFusionNetDoctorは本当に良いのビットを行う、私は、VMwareの波を爆破する必要があり、ここで（次のように実装され、ニマは本当にクール。 ...）が、アクティブ探査致命的な欠陥の数もあります。
- 唯一の障害が発生している検出。障害が断続的である場合には、この手段は、アクティブ検出は何もできないということ。
- 強度を検出することは、たとえば、障害が起こっていること、パケット損失であり、パケットロスは意味がありません現実世界の結果を示し、おそらく失われることがない最もそれまでに送信されるプローブパケットの一部を失っている、限定されています。（しかし、この方法は、バッチ注入観察することができます）
- 私は戻って行くことはできません。これは、時間内にブレークポイントの原因と場所を知ることができませんアクティブ検出は、過去に登場した時点でのカットオフポイントは、深夜など、過去の発生であれば、基本的に最初のポイントと同じである、と。
- データ識別点検出面を設定する必要があり、検出プローブ認識ポイント識別パケットは、通常のデータプレーン転送性能に影響を与えることができません。
マイクロソフトEverflowは、これで十分です達成するために、断線の故障が最も高い優先度行われているので、これは、主にアクティブな検出プローブブレークが起こっているであることをすべてのシナリオに対処するための簡単なテクニックを期待する方法を言及していません。
もちろん、後で私はいくつかの技術的な存在の困難や実装を説明するためのアクティブなプロービング特別な記事を書きます。
[パッシブ検出]
被动探测是与主动探测相对应的一种探测，被动探测的定义是在“不影响当前网络流量的情况下进行探测”，由于主动探测“注入探测数据包”会对当前网络中的流量做出一些影响（出现了一条新的流量）。被动探测以思科的Netflow作为代表，但是近年来也有一些新的技术分别亮相，比如思科提出的INT技术以及其具体应用IOAM，以及华为根据思科IOAM技术进行优化提出的PBT技术。由于被动探测的技术内容比主动探测的内容复杂一些，因此接下来会分别介绍，先介绍Netflow技术。
【Netflow】
Netflow技术由思科与1996年提出（和我同一年生....），到现在已经过了24年，已经是一种非常成熟的技术了，并且各家根据思科Netflow的思想还发展处了一些方言版本，例如jFlow，sFlow等等等等。Netflow的架构常常如图4所示。
图4.Netflow架构图
只要是基于Netflow的采集技术（其实不光是Netflow，主要是流量采集技术基本都差不多...），无论做成什么样，做的多大，基本都离不开Netflow架构的这几个组件。
- Netflow Exporter。Netflow导出器，用处是将流数据通过Netflow协议进行导出至Netflow Collector中。
- Netflow Collector。Netflow收集器，用处是将Netflow数据包收上来后进行解析，解析出流数据后存至Flow Storage中。
- Flow Storage。流数据库，存解析后的Netflow数据，通常流数据库用的基本以TSDB为主（时序数据库），因为需要常常回溯某个时间点，或过去一段时间内流量分布的变化与状态信息，因此TSDB更适合，比较流行的有influxDB、Prometheus。
- Analyzer/Monitor。分析器，用于对流数据库中的数据进行分析与呈现。
当然还有一个最终要的组件便是Netflow设备的Flow cache。在Netflow设备中会存在一张表，这张表会存放流的信息，如图
图5.Netflow Main Cache原理图
原理也非常简单，即：
当某条流的数据包第一次进入当前Netflow设备后，Netflow设备会根据此数据包的5-tuple信息（这里随意定义）提取并在Netflow cache中添加一条Flow Entry，这条Flow Entry便代表此条流，那么便可以统计这条流的信息，并定时（Netflow cache通常都有老化机制）导出封装为Netflow协议数据包送往Netflow Collector
Netflow技术的原理非常简单，就是采集流信息，上传，然后分析。当然Netflow也有缺点，便是：
- 采集粒度为“流”，无法到达更细粒度的“数据包”，所以统计丢包、时延有一定难度。
- 会给Netflow设备带来性能损耗，性能的损耗往往会带来“观察者效应”。比如某一网络现象，拿网络拥塞或丢包为例，原本网络中不会有拥塞或丢包，但是由于开启了Netflow采集功能，采集功能消耗Netflow设备的性能，导致Netflwo设备处理网络流量的性能下降，进而产生了拥塞或丢包，那么便是“观察者效应”，最终的结果并不是已经存在的，而是由于去“观察”这一动作才会发生，不观察就不会发生，那么这种情况就比较蛋疼。而性能问题又会带来如下几种问题。
- 性能下降导致在DCN网络无法对每一个数据包都进行更新Flow cache，所以往往会存在采样频率一说，比较常见的是“每100个数据包采集第一个数据包”，用这种方法来降低性能消耗，但是这种方法又会产生额外的问题，比如在网络中通常会存在一些“大象流”和“老鼠流”，大象流的代表如FTP数据流，这些流量的特点是量大，持续一段时间后就会消失；而“老鼠流”的一些代表是一些控制协议或者是协商协议，这些流量的特点是量少，但是会一直持续，可靠性要求较高。但是如果存在采样频率，很可能会出现采集不到“老鼠流”，最后看起来就是“大象流”覆盖了“老鼠流”，只能看见有FTP协议流量，其他一些TCP协议流量看不到。
- Netflow协议上传的信息有限，尽管Netflow v9已经支持模板的方式去采集数据，但是仍然是有限的，并且无法采集一些企业的私有数据，并且Netflow v9的传输层协议为UDP协议，UDP协议本身可靠性较差，一旦出现上传信息丢失，还得额外处理。
- Netflow协议存在太多的方言版本，例如sFlow、jFlow，兼容性会有一定的问题，并且Netflow协议属于思科提出的一种流量导出协议，并不是一种标准。
Netflow的缺点中，第一种其实并不是Netflow技术的缺陷，而是基于“流”的网络信息采样的共性缺陷，第三种为Netflow这种传输层协议在设计的时候出现的缺陷，而第二种更偏向于“哲学”问题，“想看的更多就得花费更多的代价”，不想付出代价还想对网络进行细粒度的观察，是不可能的，就好比“你不能要一把枪射程又长，精度又高，为例又大，体积又小，射击速度又高”，这是不现实的。
【IPFIX】
IPFIX协议，IETF提出的一种“标准流信息导出协议”，目的就是为了替代Netflow v9协议和众多的方言版本协议，可以看做是未来的趋势，大多数厂商都已经兼容IPFIX协议，例如思科、华三、华为的交换机，VMware同样将IPFIX导出协议作为一种标准的流信息导出协议。
但是要注意的是IPFIX协议只是一种“信息导出协议”，目的是为了替代Netflow架构中的Exporter到Collector中的信息导出协议，但是整体架构基本如Netflow架构。IPFIX协议由Netflow v9协议发展而来，Netflow协议中的协议头的version为9，意味Netflow v9，而IPFIX协议中的协议头与Netflow v9基本一致，并且version为a（10），也就是Netflow v10，如图6.
图6.IPFIX头格式和Netflow v9头格式对比
而IPFIX作为IETF推出的标准流信息协议，在Netflow v9的基础上做了如下的改进：
- IPFIX的传输层协议较于Netflow v9支持更加多样化，支持UDP、TCP、SCTP协议作为传输层协议的选择；（这点请见RFC 7011的10.1节）
- IPFIX相较于Netflow v9协议新增了企业字段、变长内容等新特性，可以支持一些企业内部私有的数据导出（这个是我认为最方便的一点特性）；（rfc 7012有详细解释）
- IPFIX协议的模板内容相较于Netflow v9增加了非常多，可以导出更多的信息。（同见rfc 7012）
可以看到，IPFIX相较于思科的Netflow更是一种协议标准，其中的企业字段可以很好的兼容一些方言版本的流信息导出协议，解决了很多兼容的麻烦，并且从功能的角度讲，IPFIX是兼容Netflow v9的（注意这里的功能值指的是导出内容上IPFIX要更全于Netflow v9），但是单纯从协议的角度讲是没法兼容的（也就是仍然得增加IPFIX的开发量）。
【INT】
INT技术是最近几年一种新型的网络遥感技术，全称是Inband Network Telemetry，意味“带内网络遥感技术”，是由思科提出的一个技术，INT是一种技术手段，一种思想，在思科产品中的应用叫做IOAM（inband OAM）那么这里就有一个新的概念，什么是“inband”？inband的意思直译是“带内”，但是“带内“又如何理解呢？
我个人的理解是：类似于Netflow或是IPFIX这类流监控技术，可以称之为”outband“，也就是带外。举个生活中的例子，带外就好比你是一个监控人，你在监控这条流的状态，你仍然处于一个旁观者的位置，既然是在一个旁观者的位置，那么观测的方法和观测的位置势必会对观测的结果有很大误差；而怎么最大化消除这种误差呢？生后中的经验告诉我们叫做”设身处地“，也就是我们把自己摆在当事人的视角去看待事情，那么我们可以看到更多有关事情的真面目，而inband就是这样，inband Network telemetry就是这么实现的，将旁观者监测流，改为将检测信息植入到数据包内部，这样就相当于监测点挂载到了流中的每一个数据包，那么这样数据包所经历的，必然是监测点所经历的。
图7.INT的实现方式
如图7所示，INT的实现方式就是将监测检查点插入到数据包的内部，也就是途中的OAM层，INT通常的做法就是将数据包的头（header）和数据包内部数据（payload）之间插入一块OAM层，那么这个数据包就从一个普通的网络数据包变成了一个被我们打上”标记“的数据包。再举个例子，相信看过动物世界节目的朋友都知道，海洋学家为了监测一些动物的行为轨迹，会在海洋动物身上装上遥感器，比如海龟、海豚、企鹅之类的，那么最后海洋学家就可以回收海豚的探测器，并根据探测器中记录的数据来分析这个海豚的行动轨迹，海豚的行为特征。那么INT就是这个原理，间图8.
图8.INT技术监测网络状况的原理示意
如图8中的例子，一个数据包（就好比一只海豚）进入”起点“网元设备（被科学家捕获）后，被插上了OAM层（被装上了探测器），而后数据包经过每一个网元（每一片海洋），都会将探测信息插入到OAM层中（被探测器记录），包括网元对数据包的行为，是转发还是丢弃（海豚死亡），最后数据包到达终点后，数据包中的OAM层被剥离出来，通过信息导出协议上传到远程的分析服务器（探测器被科学家回收分析数据）。那么这里有一个问题，网元设备，也就是OAM域内的传输节点怎么知道要收集哪些信息呢？
图8.IOAM数据包中的OAM层
实际上，OAM层是由两部分组成的，一部分叫做instruction，也就是指令，另一部分就是data，也就是数据，指令中会携带需要收集的信息，translation node只需要根据指令把相应的信息塞入data部分中即可完成数据的收集。
可以看到INT技术本身的原理还是非常简单的，就是在数据包内部插入一个自定义的层，然后记录经过每一个网元的信息，最后再将探测信息上传至远程的分析服务器。那么INT技术会带来什么样的优势，或者换句话说，可以怎么应用这种技术呢？
- 数据包粒度级别的丢包监测，由于监测的粒度从流变成了更细粒度的包，那么理想情况下，INT技术是可以得知网络中丢包的情况以及丢包的原因还有丢包的位置。
- 捕获网络中的jitter现象，网络中经常会出现一些jitter，jitter的特征往往是短暂难以捕获的，而由于INT技术是一种带内技术，那么理想情况下仍然是可以捕获到网络中的时延或是丢包的jitter。
- 智能路由和选路，根据OAM数据信息，可以得知网络中的每一条链路的时延、带宽以及丢包情况，那么就可以根据这些数据进行智能选路，将一些重要的流量进行重新reroute。
但是INT技术同样带来一些显而易见的缺点，以传统的INT技术，也就是思科的IOAM为例：
- DCN网络或者是运营商网络中，数据包数量巨大，对每一个数据包进行插入OAM层，并进行监测，会产生巨量的信息，这么多巨量的信息该如何压缩、去重分析？
- ”起点设备“（在INT技术中被称为encapsulation node）要对每一个数据包进行插入一个新的OAM层，这会产生巨大的性能消耗，如果是转发设备的转发过程是软件实现的，那对转发性能更是毁灭性的打击（你需要不断的申请新的空间，并将原有的数据包进行拷贝，然后再插入一个新的层，事实上思科也注意到了这一点，所以在encapsulation node插入新的OAM层时有两种实现，这点以后在详细分析INT时再说）。
- 转发设备需要不停的将探测数据插入到数据包内部，并对数据包的checksum需要重新计算，同样是一个性能消耗点。
- IOAM技术中，转发节点会不断的向hdr与payload间插入OAM层，那么考虑到数据包会被分片，OAM层的长度必然有限制，也进一步等于OAM数据包所经过的转发设备（在IOAM技术中，这些转发设备所组成的域称之为OAM域，OAM domain）不能太多。
IOAM的软件实现可以去看VPP的源代码，VPP 17.xx版本以后的版本中都带有IPv6的IOAM实现。
【PBT】
PBT（Postcards-Based Telemetry）技术本质上也是INT技术，是由华为提出的一种基于思科IOAM技术的”升级版“，可以理解为一种优化版，华为主要是针对IOAM缺陷中的第2条、第3条以及第4条进行了优化，并且华为推出了两种优化版，一种是PBT-I，另外一种是PBT-M，前者为超级版，后者为兼容版。那么PBT是怎么做的呢？其实PBT的优化有点类似与之前说的主动探测的包注入技术。既然PBT技术本质上和IOAM技术并无不同，同样拿海豚的例子来举例：
- IOAM：一条海豚被海洋学家捕获，海洋学家向海豚身上装了一个探测器，探测器不能联网，但是有内置硬盘，海豚带着这个探测器游遍太平洋，每经过一片海域，探测器就会收集信息，然后一年后被海洋学家蹲点捕获，拆掉探测器，海洋学家根据探测器的内置硬盘中的数据进行分析。
- PBT：一条海豚被海洋学家捕获，海洋学家向海豚身上装了一个探测器，探测器内部没有硬盘，但是有通信模块，海豚带着这个探测器游遍太平洋，每经过一片海域，探测器就会收集信息并立刻传给远程的海洋学家的服务器，海洋学家根据服务器接收的数据就可以分析，或者是可以先将数据存储到数据中心，等一年过后，海洋学家捕获了海豚，考虑到保护海洋动物的责任感，拆除了探测器，并根据数据中心完整的数据进行分析。
可以看到，PBT和IOAM技术最大的不同是PBT是没有携带OAM探测数据的，而是没经过一个转发节点（严格来说是OAM域内的translate node）都会立刻上传信息，具体如PBT-I技术的实现原理可以如图9所示。
图9.PBT-I技术的实现原理
那么PBT-T的原理叙述如下，数据包经过OAM域（可以理解为INT的监测域），并进入“起始节点”（encapsulation node），起始节点对数据包进行标记，注意这里是标记，并不是插入OAM层，和主动探测中的包注入技术相同，那么被标记的数据包，接下来可以称之为PBT探测数据包，接下来PBT探测数据包经过OAM域中每一个网络设备（translation node），传输节点都会去检查数据包中的标记位，观察是否时PBT探测数据包，如果是PBT探测数据包，则立刻上传监测数据。
但是这里仍然有一个问题，既然从原始的IOAM数据包的“监测模板” + “监测数据”缩小到只有1个bit的标记位，那么设备怎么知道要收集并上传那些信息呢？这个地方可以通过类似于ipfix的模板来实现，也就是实现管里面或者控制面向OAM域中的每一个传输节点下配置通知收集哪些信息。这样的话，管控面需要对OAM域中的所有节点下发数据收集的模板配置，而不像IOAM一样，只需要给encapsulation node下发数据收集的模板配置就好了。
那么根据上述的原理介绍，我们至少可以知道，PBT-I相较于IOAM做了如下几种较为明显的改进：
- 收集的数据多少不再受限于数据包的长度，因为收集的数据不再插入在数据包的内部。
- 不用对每一个数据包进行十分浪费性能的插入收集数据，重新计算checksum等操作，对于ipv4数据包，只需要看一下ipv4 header中的标记为，例如TOS中的reserve bit，就可以知道要上传哪些信息。
光这两点改进，其实就已经是质变了，尤其是第二条的改进，大大的增加了INT技术在软件转发平台上的可行性（软件实现的转发平台最怕的就是对数据包进行重新分配内存+内存拷贝+重新计算checksum，这些会带来大量的性能消耗），但是世界上没有一种完美的技术，PBT-I技术的改进同样带来了其他的缺点：
- 管控面需要对OAM域中所有的节点下发模板配置信息，告知OAM域中的节点碰见PBT探测数据包要上报哪些信息。
- 由于没经过一个translate node都需要上传信息，所以上传的信息次数会进一步变多，这样同样带来了某一个节点上传的信息丢失的风险。
- 需要时间同步和信息重组，即一个PBT探测数据包经过了n个网元，如何将这n个网元上传的信息进行联系组装。
- 不灵活，没办法定制化，例如网络中有A、B、C、D、E五条流，其中我需要对A、B两条流收集的信息集合为M，对C、D、E三条流收集的信息集合为N。但是标记位只有一个，没有办法进行更细粒度的进行区分。
虽然带来了这几个缺点，但是PBT-I的改进确实让人看到了软件实现INT技术的可行性。说完了PBT-I，接着说说“折中版”PBT-M，华为提出的draft中同样承认了PBT-I技术做得太绝，导致了上述几个问题的出现，那么能不能稍微做的不那么绝，来个折中点的方案呢？所以就来了PBT-M这种折中版本。
PBT-M相较于PBT-I技术，没有完全舍弃OAM层，而相比于IOAM技术，又放弃了在OAM层中插入探测数据，因此PBT-M就是相当于IOAM与PBT-I的折中，即：
数据包第一次经过encapsulation node，同样会插入OAM层，但是，直插入instruction，不插入data，相当于只插入收集指令，用于告知当前PBT探测数据包经过的每一个网元，要给这个数据包收集什么样的信息，然后再将这个信息导出至远程的分析服务器。那么根据这个特征，我们可以知道，实际上PBT-M时对PBT-T的4条缺点中的1、4进行了优化，管控面只需要给encapsulation node下发配置即可，举个例子，网络中有A、B、C、D、E五条流，其中我需要对A、B两条流收集的信息集合为M，对C、D、E三条流收集的信息集合为N。A、B两条流的数据包经过encapsulation node时，encapsulation node根据管控面下发的配置，对A、B中插入OAM层，instruction为M，对C、D、E插入OAM层，instruction为N，倘若A流的数据包经过translation node时，translation node根据内置的OAM层中的instruction M就知道该上传instruction M所对应的数据，这样灵活性大大加强。不过PBT-M这种折中版仍然会带来IOAM技术中的缺点2，也就是encapsulation node需要对这个数据包插入OAM层，对软件实现来说仍然不友好。
【总结-说一说我自己的一些看法】
- 主动包注入技术只能排查当前正在发生的一些网络故障，因此局限性较大，但是性能消耗小且易用，但是诊断的粒度很细，可以立刻得到网络中正在发生的故障、故障位置以及故障原因
- Netflow或是IPFIX这种传统的基于流的被动网络探测技术，相较于主动探测技术性能消耗要大，并且存在测不准有误差的情况，粒度也不尽人意，但是作为一种监控出身的技术，仍然是主流且容易实现的一种技术。
- INT技术对于网络探测可以说是吊打Netflow或是IPFIX这种基于流的被动监测技术，但是INT技术中的IOAM技术目前看来不适合软件实现，当然barefoot推出了支持INT技术的转发芯片，让IOAM技术可以得以应用，不过芯片的价格感人，据说一片要8000刀（去抢吧...），目前barefoot已经被intel收购，后续什么情况还犹未可知，目前IOAM这种INT技术的具体实现更多的都是基于硬件实现，然后与P4编程打组合拳。
- INT技术中的PBT技术，目前对软件实现比较友好的是PBT-I，当然对于PBT-M技术而言，如果encapsulation node是支持INT的硬件转发设备，那么PBT-M的灵活性确实是要比PBT-I更胜一筹的。
唉，网络遥感技术这块领域，大佬打架，我等渣渣只能吃瓜了....
先站一个坑，以后再慢慢具体说一说这些技术的一些具体细节，以及该怎么实现。