zoukankan      html  css  js  c++  java
  • 802.11网络协议细节(四)

          

    1.4   802.11对上层协议的封装

    和所有其他的 802 链路层一样,802.11可以传输各种不同的网络层协议。和以太网不同的是,802.11是以802.2 的逻辑链路控制封装来携带上层协议。图 1-13 显示了如何以 802.2LLC封装来携带 IP 封包。如该图所示,802.1H与RFC 1042 所使用的『MAC标头』长度为 12个bit组,其内容为以太网上的『源 MAC地址』与『目的 MAC地址』,或者前面所提到的长标头(long 802.11MAC header )。

     

                  图 1-13:802.11 里的 IP 封装

    传输时,用来封装 LLC 数据的方式有两种。其中一种是 RFC 1042 所描述的方式,另外一种则是802.1H所规范的方式。两种标准各自有其别名。RFC 1042 有时候被称为 IETF 封装,而802.1H有时候则被称为隧道式封装(tunnel encapsulation).

    这两种方式极为相似,如图 1-13所示。此图最上方为以太网帧,它具有 MAC标头(源与目的MAC地址),类型代码(type code ),内嵌封包(embedded packet )以及帧检验等位。

    在IP 领域里,Type code 不是代表IP 的本身的OX0800(十进制的 2048),就是代表地址解析协议(简称 ARP)的 OX0806(十进制的 2054)。

    RFC 1042 与802.1H均衍生自 802.2 的子网络访问协议(sub-network access protocol ,简称SNAP )。MAC地址会被复制到封装帧(encapsulation frame)的开头,然后插入 SNAP标头。SNAP 标头一开始是目的服务访问点(destination service access point,简称DSAP)与源服务访问点(source service access point, 简称SSAP)。然后是一个控制位。和高阶数据链路控制(high-level data link control, 简称HDLC)及其衍生协议一样,此控制位会被设定为 0x03,代表未编号信息(unnumbered information,简称UI),对应到IP datagram 所谓的尽力传送(best-effert delivery)范畴。SNAP 所置入的最后一个位是组织代码(organizationally unique identifier ,简称 OUI)。起初,IEEE 希望用一个 bit组的服务访问点(service access point )来涵盖网络协议编号,不过后来证明这种看法过于乐观。因此,SNAP 只得从原来的以太网帧复制一份类型代码(type code )。802.11H 与RFC 1042 之间的唯一差异,在于其使用的 OUI。

    有些产品可以让使用者在两种封装标准间进行切换,虽然这种功能并不常见。以 Microsoft操作系统而言,AppleTalk 与IPX 协议组预设使用 802.1H,其他协议则使用 RFC 1042 。目前大部分接入点均依循 Microsoft的做法,不再提供封装方式的切换选项。事实上,由于 Microsoft所采用的封装方式得到广泛的支持,因此 Wi-Fi联盟的认证测试计划亦将它包含在内。

    1.5   竞争式数据服务

    为了增加可靠性,802.11纳入了许多额外的功能。这些功能导致某些规则上的混淆,因而无法判断何时该允许使用何种类型的帧。这些额外的功能也让网络管理人员更难预测,有哪些帧会来往于所检视的网络中。本节的目的在澄清,802.11局域网络中负责运送数据的基本交换过程。(大部分的管理帧只会公告给该区域中相关的对象,信息的传递纯粹是单向的。)

    本节所陈述的是基本交换程序,也就是说数据的交换过程必须视为单一整体。举例而言,单点传播数据必须得到应答以确保数据传送无误。虽然整个数据的交换过程包含两个帧,但数据交换本身只算第一过程。只要有一方失误,整个过程就必须重新来过。802.11 定义了两组截然不同的基本交换程序。其一为 DCF,用于竞争服务。第二种交换方式为 PCF,用于免竞争服务(contention-free service)。免竞争服务所使用的帧交换方式不仅错综复杂,而且还难以理解。有鉴于商业化产品很少实现免竞争服务,其交换过程不再赘述。

    DCF说使用的帧交换方式在 802.11 MAC 中占有决定性的地位。根据 DCF的规定,所有的产品都必须提供尽力的传递功能。为了实现竞争式 MAC,处于作用状态的工作站都必须处理每个帧的 MAC标头。整个帧交换过程,始终某部工作站在 DIFS之后取得闲置介质的使用权。

    3.5.1   广播与组播数据或管理帧

    广播与组播帧的交换过程最为简单,因为这些帧无须应答。这两种帧也可以视为群组帧,

    因为其接收对象不限于单一工作站。帧封装(framing )与定位(addressing )在 802.11中较为复杂,适用此规则的帧类型如下所示:

    l  广播数据帧会在 Address1位中填入广播地址

    l  组播数据帧会在 Address1位中填入组播地址

    l  广播管理帧会在 Address1位中填入广播地址(Beacon、Probe Request 以及IBSS ATIM帧)

    组播帧无法加以分段,也无须得到应答。整个基本交换过程只牵涉到一个帧,根据竞争式访问控制规则加以传递。传送结束后,所有工作站必须等待一段 DIFS时间,然后在竞争期间倒数随机产生的延迟时间。

    因为帧的交换过程只牵涉到一个帧,所以将 NAV(网络分配矢量)设定为 0。既然此后已无其他帧,也就不必使用虚拟载波监听锁住介质,来防止其他工作站的访问。传送该帧之后,所有工作站均会等候一段 DIFS时间,然后通过竞争期间开始为任何遭延迟的帧进行倒数。整个交换过程,详见图 1-14 。

     

              图 1-14:广播/组播数据以及广播管理的基本帧交换过程

    因环境而异,组播帧可能会遇到低劣的服务质量,因为这些帧没有得到任何应答。因此,有些工作站可能会遗漏广播或组播数据。不过MAC并未内建任何机制可用以重传广播或组播帧。

    3.5.2   单点传播帧

    在802.11标准中,针对个别工作站所传送的帧称为直接数据(direct data )。本书中使用较通俗的字眼,称之为单点传播(unicast)。单点传播帧必须得到应答以确保可靠性,亦即可借助各种机制来改善传输效率。本节所描述的交换过程适用于任何单点传播帧,因此也适用于管理帧与数据帧。实际上,这些过程通常只见于数据帧。

     3.5.2.1 单一帧(最后一个片段)及其正面应答

    两部工作站之间的传输可靠性建立在简单的正面应答上。单点传播数据帧必须得到正面应答,否则该帧即会被认定已经丢失。单一帧及其回应是最基本的例子,如图 1-15 所示。

     

                图 1-15:单一帧及其正面回应

    此帧会利用 NAV 为本身、应答及 SIFS 预定介质使用权。设定较长的 NAV,是为了替整个交换程序锁住虚拟载波,以保证接收端可以传送应答。因为此交换程序是以 ACK 做为结束,所以没有必要再锁住虚拟载波,因此该 ACK 中 NAV 会被设定为 0。

     3.5.2.2 帧分段

    包括IP 在内,一些较上层的网络协议或多或少都会用到帧分段。在网络层进行分段的缺点是,接收端必须加以重组;如果帧在传输过程中遗失,整个封包就必须重传。在链路层使用分段机制可以提升速度,亦即以较小的 MTU在转运点(hop )间传送数据。

     

              图 1-16:帧分段

    此外,802.11可以利用帧分段来避免干涉。无线点播干扰通常会以瞬间而高能量的尖波形式出现,而且经常与 AC电源线同步。将帧加以分段,可保护大部分帧不遭受损害。基本分段机制如图1-16 所示。

    最后两个帧和之前的交换过程没有两样,NAV的设定也完全相同。不过,倒数第二个帧之前所有帧均会使用 NAV,为下一个帧锁住介质。第一个数据帧会将 NAV的时间设定至足以涵盖ACK1, 下一个帧片段及其回应(ACK2)。为了表示其为帧片段,MAC会将帧标头控制位的 More Fragmentsbit 设定为1。最后一个回应(ACK3)除外,其余回应都会继续为下一个数据片段及其回应延长锁住介质的时间。后续的数据帧会继续延长 NAV以涵盖后续的回应,直到最后一个数据帧才会将 More Fragmentsbit设定为 0 ,而最后一个回应(ACK3)则会将 NAV设定为 0 。帧片段的数目并无限制,不过虚空总长度必须短于 PHY对交换过程所做的限制。

    帧分段是由 MAC的fragmentation threshold(切割门限) 参数所控制。大部分的网卡驱动程序都允许使用者设定此参数。任何超过分段门限的帧都会被加以分段,分段方式因实际情况而异。调高分段门限意味着帧的传输负担较小,不过帧丢掉和损害的成本较高,因为将会有较多的数据必须丢弃与重传。调低分段门限意味着传输负担较重,不过在面临较恶劣的环境时,这种做法可以提供较佳的稳定性。

     3.5.2.3 RTS/CTS

    为保证介质使用权以及数据传输不被中断,工作站可使用 RTS/CTS的交换方式。图 1-17说明了整个过程。RTS/CTS交换的做法和帧分段一开始没有什么两样,只是RTS 帧并未携带任何数据。RTS/CTS中的 NAV可让CTS完成工作,而 CTS 则可用来为数据帧保留使用权。

    RTS/CTS 可用在所有的帧交换、非帧交换或介于两者之间。和帧分段一样,RTS/CTS 是由启动程序中的门限值来控制的。超过该门限的帧由 RTS/CTS 先行清空介质,而较小的帧则直接传送。

     

                图 1-17:以 RTS/CTS 锁住介质

     3.5.2.4 RTS/CTS 与帧分段

    实际上,RTS/CTS交换过程通常与帧分段并行,如图1-18所示。虽然经过分段,帧片段还是有一定的长度,因此可受惠与 RTS/CTS过程所确保的介质独家使用权,免与隐藏节点的竞争。有些厂商将帧分段门限与 RTS/CTS门限的预设值设成一样。

     

                  图 1-18:RTS/CTS 与帧分段

     

  • 相关阅读:
    Failed to start mysqld.service: Unit not found
    Nginx转发前后端分离跨域引发的问题-转发请求header头中含有下划线,无法转发取值
    云上Centos7新硬盘挂载流程
    马哥教育第二阶段考试
    Linux集群准备-同步
    Lucene查询语法
    权限系统设计
    docker compose thinkphp5.1 lnmp环境搭建加项目部署全过程
    docker compose 的使用
    [转载]PHP-FPM
  • 原文地址:https://www.cnblogs.com/aixin0813/p/3255000.html
Copyright © 2011-2022 走看看