RFC2684(中文)-AAL5上的多协议封装(废止了RFC1483)

本文翻译者：weicq2000 RFC2684 AAL5 上的多协议封装 (1999 年 9) 本协议废止了 RFC1483。 摘要 本备忘录取代了 RFC1483。本备忘录描述了两种在 ATM AAL5 上承载网络互连流量的 封装方法。第一种方法可在单一 ATM 虚连接上复用多个协议，第二种方法由独立的 ATM 虚连接承载每个协议。 应用 本标准适用于这样的 ATM 网络，该 ATM 网络在作为 ATM 端系统的主机、路由器和网 桥间携带多协议流量。 第 1 章 介绍 在校园网和局域网中，广泛使用 ATM 技术，实现 IP 数据报和其他无连接流量在主机、 路由器、网桥和其他网络设备间传送。本备忘录给出两种在 ATM 网络上携带无连接路由和 桥接协议数据单元(PDU)的方法。“LLC 封装”方法允许在单一 ATM 虚连接(VC)上多路复用 多种协议。通过给每个 PDU 添加 IEEE 802.2 逻辑链路控制(Logical Link Control, LLC)首部 来标识 PDU 的协议类型。在“VC 多路复用”方法中，每个 ATM VC 仅携带一种协议类型 的 PDU。当需要传送多个协议时，每个协议使用独立的 VC。 ATM 的传输单元是称作信元的 53 字节固定长度 PDU。信元由 5 字节的首部加上 48 字 节的净荷组成。可变长度 PDU，包括本备忘录中处理的 PDU，必须在发送端拆分成 48 字节 的 ATM 信元净荷，在接收端再重组到一起。本备忘录规定使用 AAL5(ATM Adaptation Layer type 5)实现这一拆分和重组，这与 ITU-T 建议 I.363.5[2]定义的一致。AAL5 公共部分汇聚子 层(Common Part Convergence Sublayer, CPCS)PDU 的净荷字段承载可变长度 PDU。本备忘录 仅描述如何在 AAL5 CPCS 上直接承载路由 PDU 和桥接的 PDU，即没有 AAL5 SSCS(Service Specific Convergence Sublayer)。如果 FR-SSCS(Frame Relay Service Specific Convergence Sublayer)在 CPCS 之上使用，如 ITU-T 建议 I.365.1[3]定义的，那么路由 PDU 和桥接 PDU 采用 NLPID 多路复用方法携带，正如 RFC2427[4]所述。在使用帧中继网络互连或透明模式 服务互连[9]的特殊情况，必须使用 RFC2427 封装，但不推荐在其他应用中这样使用。附录 A(仅仅提供信息)给出了 FR-SSCS-PDU 的 格式 pdf格式笔记格式下载页码格式下载公文格式下载简报格式下载 ，以及按照 RFC2427，如何在 FR-SSCS 上封 装 IP 和 CLNP PDU。 本备忘录也包括一种可选的封装形式，它用于 ATM 子网上的 VPN(Virtual Private Networks)。 如果希望在 PPP(Point-to-Point Protocol)场景下使用，并且对端系统间有点对点关系，那 么应该使用 RFC2364，而不是本备忘录。 第 2 章 约定 关键词MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、 SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、MAY 和 OPTIONAL 在本备 忘录中的含义遵循 RFC2119[10]中的规定。 第 3 章 多路复用方法选择 对 LLC 封装或 VC 多路复用的选择取决于实现和系统要求。一般讲，LLC 封装在多协 议环境下需要较少的 VC。VC 多路复用可减少分段开销(例如，包含一个 TCP 控制分组(它 既没有 IP 选项也没有 TCP 选项)的 IPv4 数据报正好装入单个信元)。 当两个 ATM 端系统希望跨越 ATM 永久虚连接(Permanent Virtual Connection, PVC)交换 无连接 PDU 时，由配置来选择多路复用方法。在 ATM 交换虚连接(Switched Virtual Connections, SVCs)情况，使用 ATM 连接控制信令程序协商封装方法。[5]和[8]说明了协商 如何进行。 第 4 章 AAL5 PDU 格式 在两种多路复用方法中，都必须将路由 PDU 和桥接 PUD 封装在 AAL5 CPCS-PDU 的 净荷字段内。 ITU-T 建议 I.363.5[2]提供了 AAL5 PDU 格式，以及在发送端和接收端如何处理的完整 定义。在非保证操作模式中应当使用 AAL5 消息模式服务。必须不使用不可靠交付选项。 必须启用重组计时器。参见下述说明。 AAL5 CPCS-PDU 格式如图 1 所示。 CPCS-PDU净荷 最大216-1字节 PAD(0-47字节) CPCS-UU(1字节) CPI(1字节) 长度(2字节) CRC(4字节) CPCS- PDU 尾部 ··· ··· 图 1 AAL5 CPCS-PDU 格式 净荷字段最多包括 216-1 字节用户信息。 PAD 字段是填充字段，通过填充，CPCS-PDU 精确装入 ATM 信元，结果由分拆和重组 (SAR)子层生成的最后 48 字节信元净荷在信元内有刚好对齐的 CPCS-PDU 尾部。 CPCS-UU(User-to-User indication)字段用于透明传送 CPCS 用户到用户信息。此字段不 用于本备忘录描述的多协议 ATM 封装，可设置为任何值。 CPI(Common Part Indicator)字段调整 CPCS-PDU 尾部到 64 比特。此字段必须编码为 0x00。 长度字段指出净荷字段的长度，以字节为单位。长度字段的最大值是 65535 字节。编码 为 0x00 的长度字段用于中断功能。 CRC 字段用于检测 CPCS-PDU 中的比特错误。使用 CRC-32。 第 5 章 LLC 封装 当在同一条 VC 上承载不止一个协议时需要使用 LLC 封装。为方便接收端处理输入的 AAL5 CPCS-PDU，净荷字段包含识别路由 PDU 协议或桥接 PDU 协议的必要信息。对于 LLC 封装，应当在所携带 PDU 前面的 LLC 首部内对此信息编码。 虽然本备忘录仅处理在 LLC 类型 1(非确认无连接模式)上运行的协议，相同的封装原则 也适用于在 LLC 类型 2(连接模式)上运行的协议。在后者情况，LLC 首部的格式和内容在 IEEE 802.1 和 IEEE 802.2 中描述。 5-1 路由协议的 LLC 封装 在 LLC 封装中，必须通过添加 IEEE 802.2 LLC 首部到每个 PDU 来标识路由 PDU 的协 议类型。在某些情况，LLC 首部后跟着一个 IEEE802.1a SNAP(SubNetwork Attachment Point) 首部。在 LLC 类型 1 上运行时，LLC 首部由三个 1 字节字段构成，如图 2 所示。 DSAP SSAP Ctrl 1字节 1字节 1字节 图 2 DSAP、SSAP 和 Ctrl 三个字段格式 在路由协议 LLC 封装中，控制字段应当设置为 0x03，规定未编码信息指令(Unnumbered Information Command, UI)PDU。 在 ISO NLPID 格式中，值为 0xFE-FE-03 的 LLC 首部用于标识路由 PDU(参阅[6]和附录 B)。对于 NLPID 格式的路由 PDUs，AAL5 CPCS-PDU 净荷字段的内容如图 3 所示。 LLC 0xFE-FE-03 NLPID(1字节) PDU(最大216-4字节) ··· ··· 图 3 路由 NLPID 格式 PDU 净荷格式 路由协议必须由 1 个字节的 NLPID 字段(作为协议数据的一部分)标识。NLPID 值由 ISO 和 ITU-T管理。NLPID在 ISO/IEC TR9577[6]中定义，附录C列出了目前已定义的一些NLPID。 在 ISO/IEC TR9577 中定义值为 0x00 的 NLPID 为空网络层(Null Network Layer)或不活动集 (Inactive Set)。由于此封装 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 的内容中 0x00 没有意义，应当不使用值为 0x00 的 NLPID。 虽然有标识 IP 的 NLPID 值(0xCC)，必须不把 NLPID 格式用于 IP。相反，必须由 SNAP 首 部标识 IP 数据报，参阅下面定义。 LLC 首部值 0xAA-AA-03 指出 IEEE802.1a SNAP 首部的存在。SNAP 首部格式如图 4 所示。 OUI PID 3字节 2字节 图 4 SNAP 首部格式 SNAP 首部由 3 字节的组织唯一标识符(Organizationally Unique Identifier, OUI)和 2 字节 的协议标识符(Protocol Identifier, PID)组成。OUI 由 IEEE 管理，用于标识一个组织，该组织 管理可能分配给 PID 的值。于是，SNAP 首部唯一标识路由协议或桥接协议。OUI 值 0x00-00-00 指出 PID 是 EtherType。 路由非-NLPID 格式 PDUs 的 AAL5 CPCS-PDU 净荷字段格式如图 5 所示。 LLC 0xAA-AA-03 OUI 0x00-00-00 EtherType (2字节) 非-NLPID 格式 PDU (最大 216 - 9字节) ··· ··· 图 5 路由非-NLPID 格式 PDU 净荷格式 在 IPv4 PDU 情况，以太网类型值是 0x08-00，净荷字段格式如图 6 所示。 LLC 0xAA-AA-03 OUI 0x00-00-00 EtherType 0x08-00 Ipv4 PDU (最大 216 - 9字节) ··· ··· 图 6 路由 IPv4 PDU 净荷格式 此格式与 RFC1042[7]中定义的格式一致。 5-2 桥接协议的 LLC 封装 在 LLC 封装中，通过标记 SNAP 首部中桥接介质类型，实现对桥接 PDU 的封装。必须 由 LLC 首部值 0xAA-AA-03 指出 SNAP 首部的存在。在 SNAP 首部中 OUI 值应当是 802.1 组织代码 0x00-80-C2。桥接介质的类型由 2 字节的 PID 规定。PID 也指出是否原始帧校验 序列(Frame Check Sequence, FCS)保存在此桥接 PDU 中。附录 B 提供了介质类型(PID)值列 表，这些类型值可用在 ATM 封装中。 携带桥接 PDU 的 AAL5 CPCS-PDU 净荷字段应当是下述格式之一。在 PID 字段之后应 当添加一定数目的填充字节，以便(分别)调整此桥接 PDU 的以太网/302.3 LLC 数据字段， 802.4 数据单元字段，802.5 信息字段，FDDI 信息字段或 802.6 信息字段到 4 字节边界的开 始。MAC 地址的比特顺序应当与该地址在 LAN 或 MAN 中的相同(例如，典型的桥接以太 网/IEEE802.3 PDU 格式，但是桥接 802.5PDUs 采用 802.5/FDDI 格式)。 桥接以太网/802.3 PDU 净荷格式如图 7 所示。 LLC 0xAA-AA-03 OUI 0x00-80-C2 PID 0x00-01 或 0x00-07 PAD 0x00-00 MAC 目的地地址 (MAC帧其余部分) LAN FCS(如果PID是0x00-01) 图 7 桥接以太网/802.3 PDU 净荷格式 以太网/802.3 物理层需要对帧的大小进行填充，以维持最小长度。使用带有保留 LAN FCS 的桥接以太网/802.3 封装格式的网桥应当包括填充。使用不带保留 LAN FCS 的桥接以 太网/802.3 封装格式的网桥可以包括填充，或者省略填充。收到无 LAN FCS 格式的帧后， 在转发此帧到以太网/802.3 子网前，网桥必须能够插入必要的填充(如果没有)。 桥接 802.4 PDU 的净荷格式如图 8 所示。 LLC 0xAA-AA-03 OUI 0x00-80-C2 PID 0x00-02 或 0x00-08 PAD 0x00-00-00 MAC 目的地地址 (MAC帧其余部分) LAN FCS(如果PID是0x00-02) 帧控制(1字节) 图 8 桥接 802.4 PDU 净荷格式 桥接 802.5 PDU 净荷格式如图 9 所示。 LLC 0xAA-AA-03 OUI 0x00-80-C2 PID 0x00-03 或 0x00-09 PAD 0x00-00-XX MAC 目的地地址 (MAC帧其余部分) LAN FCS(如果PID是0x00-03) 帧控制(1字节) 图 9 桥接 802.5 PDU 净荷格式 因为 802.5 存取控制(Access Control, AC)字段在本地 802.5 子网以外没有意义，在此封 装中它被当作是 3 字节 PAD 字段的最后字节。发送网桥可以将它设置为任何值，接收网桥 应当忽略它。 桥接 FDDI PDU 净荷格式如图 10 所示。 LLC 0xAA-AA-03 OUI 0x00-80-C2 PID 0x00-04 或 0x00-0A PAD 0x00-00-00 MAC 目的地地址 (MAC帧其余部分) LAN FCS(如果PID是0x00-04) 帧控制(1字节) 图 10 桥接 FDDI PDU 净荷格式 桥接 802.6 PDU 净荷格式如图 11 所示。 LLC 0xAA-AA-03 OUI 0x00-80-C2 PID 0x00-0B BAsize MAC 目的地地址 (MAC帧其余部分) Common PDU Trailer 保留 BEtag 公共 PDU 首部 图 11 桥接 802.6 PDU 净荷格式 在桥接 802.6 PDU 中，MAC 帧首部内 CIB 位指出 CRC-32 的存在。因此，无论 PDU 中 是否存在 CRC-32，使用同样的 PID 值。 允许出口网桥以管道方式传送公共协议数据单元(C-PDU)首部和尾部(Trailer)到 802.6 子网。更准确地说，C-PDU 首部包括 BAsize 字段，该字段包括 PDU 的长度。如果出口 802.6 网桥不能得到此字段，那么，直到网桥收到整个 PDU，求出长度，将长度插入进 BAsize 字 段以前，网桥不能开始传送被拆分的 PDU。如果可得到该字段，出口 802.6 网桥能够从 C-PDU 首部的 BAsize 字段提取该长度，并将其插入第一分段的相应字段，然后立即传送该分段到 802.6 子网。于是，网桥能够在它收到完整的 PDU 之前发送 802.6 PDU。 注意，被封装帧的 C-PDU 首部和尾部不能简单复制到出口 802.6 子网，因为被封装的 BEtag 值可能与该网桥以前发送的 BEtag 值冲突。通过设置 AAL5 CPCS-PDU 的长度字段为 0，入口 802.6 网桥能够取消该 PDU。如果出口网桥已经开始传送 PDU 分段到 802.6 子网， 接着注意到 AAL5 CPCS-PDU 已经被取消，它可以立即产生 EOM 信元，该信元让接收网桥 抛弃 802.6 PDU。例如，这样的 EOM 信元可以在 C-PDU 尾部长度字段内包括一个非法值。 BPDU 净荷格式如图 12 所示。 如802.1d或802.1g定义的BPDU PID 0x00-0E OUI 0x00-80-C2 LLC 0xAA-AA-03 图 12 BPDU 净荷格式 第 6 章 VC 多路复用 VC 多路复用在 ATM VC 和该 VC 上携带的网络协议类型之间产生一个绑定。于是，不 需要在每个 AAL5 CPCS-PDU 净荷中携带协议标识信息。这减少了净荷开销，减轻了对每 个分组的处理量。由于减少了需要携带一定长度 PDU 的信元数量，VC 多路复用提高了效 率。对于 ATM PVC，在每个 PVC 上携带的协议类型必须由配置确定。对于 ATM SVC，必 须使用 RFC1755[5]中规定的协商机制。 6-1 路由协议 VC 多路复用 路由协议 PDU 必须是 AAL5 CPCS-PDU 净荷携带的唯一内容。于是，AAL5 CPCS-PDU 净荷字段格式变为如图 13 所示。 承载的PDU (最大216-1字节) ··· ··· 图 13 路由 PDU 净荷格式 6-2 桥接协议 VC 多路复用 桥接协议 PDU 必须由 AAL5 CPCS-PDU 净荷携带，除了必须只包括 PID 字段后的字段 以外，和第 5-2 节描述相同。因此，携带桥接 PDU 的 AAL5 CPCS-PDU 净荷字段应该取下 述格式中的一种。 桥接以太网/802.3 PDU 净荷格式如图 14 所示。 PAD 0x00-00 MAC 目的地地址 (MAC帧其余部分) LAN FCS (VC相关 选项) 图 14 桥接以太网/802.3 PDU 净荷格式 桥接 802.4/802.5/FDDI PDU 净荷格式如图 15 所示。 PAD 0x00-00-00或0x00-00-XX MAC 目的地地址 (MAC帧其余部分) LAN FCS (VC相关 选项) 帧控制(1字节) 图 15 桥接 802.4/802.5/FDDI PDU 净荷格式 注意，在本地 802.5 子网以外 802.5 接入控制(Access Control, AC)字段没有意义。于是 AC 字段可被当作是 3 字节 PAD 字段的最后一个字节，在 802.5 情况可赋予任何值(XX)。 桥接 802.6 PDU 净荷格式如图 16 所示。 MAC 目的地地址 (MAC帧其余部分) 公共PDU尾部 保留 BAsize BEtag 公共 PDU 首部 图 16 桥接 802.6 PDU 净荷格式 BPDU 净荷格式如图 17 所示。 如802.1d或802.1g定义的BPDU 图 17 BPDU 净荷格式 在以太网、802.3、802.4、802.5 和 FDDI PDU 情况，尾部 LAN FCS 的存在或不存在由 VC 隐含指出，因为不包括 PID 字段。于是，带有 LAN FCS 的 PDU 和不带有 LAN FCS 的 PDU 被认为属于不同协议，即使桥接媒介类型是相同的。 第 7 章 ATM 网络中的桥接 带有 ATM 接口的网桥，它用作连接一个或多个其他网桥的链路，必须能够泛洪、转发 和过滤桥接 PDU。 泛洪指发送 PDU 到所有可能的适当目的地。在 ATM 环境这意味着经每个相关 VC 发送 PDU。可通过显示复制 PDU 到每个 VC 或使用点对多点 VC 实现。 为了转发 PDU，网桥必须能够用一条 VC 关联一个目的地 MAC 地址。要求网桥静态配 置每个可能目的地 MAC 地址与一条 VC 的关联是不现实或不可能的。因此，ATM 网桥必须 提供足够的信息，以便允许 ATM 接口动态了解 ATM 站点集合以外的外部目的地。 为实现动态学习，桥接 PDU 应当按第 5 章所述进行封装。用此封装方法，接收端 ATM 接口将知道去浏览桥接 PDU，学习外部目的地和 ATM 站点间的关联。 第 8 章 虚拟专用网(Virtual Private Network, VPN)标识 本章定义的封装仅适用于运行在 ATM 子网上的 VPN。 虚拟专用多协议网络全球唯一标识机制在[11]中定义。7 字节 VPN-ID 构成如下：3 字节 VPN-related OUI(IEEE 802-1990 Organizationally Unique Identifier)，加上其后的 4 字节 VPN 索引，该索引由 VPN-related OUI 的所有者分配。典型情况，VPN-related OUI 的值分配给 VPN 服务提供者，VPN 服务提供者接着分配 VPN 索引值给他的用户。 8-1 VPN 封装首部 VPN 封装首部格式如图 18 所示。 LLC 0xAA-AA-03 OUI 0x00-00-5E PID 0x00-08 PAD 0x00 VPN related OUI(3字节) VPN索引(4字节) PDU其余部分 图 18 VPN 封装首部格式 使用此封装首部时，必须按照第 5 章或第 6 章描述的相应格式构建 PDU 的其余部分(即， 在 AAL5 CPCS SDU 内，VPN 封装首部是预先加到 PDU 上的)。 8-2 VPN 内 LLC 封装路由 PDUs 或桥接 PDU 当使用 AAL5，在 VPN 内发送 LLC 封装路由 PDU 或桥接 PDU 时，VPN 封装首部应当 被分别预先加到适当的路由 PDU 或桥接 PDU 格式上，正如第 5-1 节和第 5-2 节所定义的。 8-3 VPN 内路由 PDU 或桥接 PDU VC 多路复用 当使用 VC 多路复用，在 VPN 内发送路由 PDU 或桥接 PDU 时，可以规定 VPN 标识符 为一个先验值，然后由 ATM 连接控制信令或通过管理分配该先验值给 ATM 接口；VPN 标 识符也可以由封装首部表示。 如果VPN由ATM连接控制信令标识，所有由ATM VC携带的PDU关联到同一个VPN。 在此情况，路由 PDU 和桥接 PDU 的净荷格式必须分别如第 6-1 节和第 6-2 节定义的。如果 使用 ATM 信令标识 VPN 时，收到包含 VPN 封装首部的 PDU，接收端可以抛弃它，同时采 取其他规定的行动，或者直接采取其他规定的行动。采用 ATM 连接控制信令携带 VPN 标 识符的机制涉及的标准超出本备忘录范围。 如果 VPN 标识符经管理上分配给 ATM 接口，那么在那个接口中任何 ATM VC 携带的 所有 PDU 与那个 VPN 关联。在此情况，路由 PDU 和桥接 PDU 净荷格式必须分别如第 6-1 节和第 6-2 节定义的。当 VPN 标识符已经由管理上分配，如果收到包含 VPN 封装首部的 PDU，接收端可以抛弃它，同时采取其他规定的行动，或者直接采取其他规定的行动。分配 VPN 标识符到 ATM 接口的机制涉及的标准(例如 MIB)超出本备忘录范围。 如果使用封装首部指示 VPN 标识符，那么，必须预先加 VPN 封装首部到适当的路由 PDU 或桥接 PDU 格式上，正如分别在第 6-1 节和第 6-2 节定义的。 第 9 章 安全考虑 本备忘录定义了 ATM 上多协议封装机制。在任何封装协议中都有一个信任问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 ：接 收者应当相信发送者已经正确标识了封装的协议。没有办法查明发送者使用了适当的协议标 识(这不是希望有的功能)。可以相信，本备忘录描述的封装机制没有任何可能暴露给攻击者 的其他特性。然而，运行在封装层之上的架构和协议可能受到各种攻击。尤其是，在第 7 章讨论的桥接架构有和其他桥接架构相同的弱点。 系统安全受到在下面的 ATM 网络性质的影响。ATM 论坛已经印发了安全框架[12]和关 联的安全规范[13]。 致谢 This memo replaces RFC 1483, which was developed by the IP over ATM working group, and edited by Juha Heinanen (then at Telecom Finland, now at Telia). The update was developed in the IP-over-NBMA (ION) working group, and Dan Grossman (Motorola) was editor and also contributed to the work on RFC 1483. This material evolved from RFCs [1] and [4] from which much of the material has been adopted. Thanks to their authors Terry Bradley, Caralyn Brown, Andy Malis, Dave Piscitello, and C. Lawrence. Other key contributors to the work included Brian Carpenter (CERN), Rao Cherukuri (IBM), Joel Halpern (then at Network Systems), Bob Hinden (Sun Microsystems, presently at Nokia), and Gary Kessler (MAN Technology). The material concerning VPNs was developed by Barbara Fox (Lucent) and Bernhard Petri (Siemens). 参考文献 [1] Piscitello, D. and C. Lawrence, "The Transmission of IP Datagrams over the SMDS Service", RFC 1209, March 1991. [2] ITU-T Recommendation I.363.5, "B-ISDN ATM Adaptation Layer (AAL) Type 5 Specification", August 1996. [3] ITU-T Recommendation I.365.1, "Frame Relaying Service Specific Convergence Sublayer (SSCS), November 1993. [4] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 2427, September 1998. [5] Perez M., Liaw, F., Mankin, E., Grossman, D. and A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755, February 1995. [6] Information technology - Telecommunications and Information Exchange Between Systems, "Protocol Identification in the Network Layer". ISO/IEC TR 9577, October 1990. [7] Postel, J. and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042, February 1988. [8] Maher, M., "IP over ATM Signalling - SIG 4.0 Update", RFC 2331, April 1998. [9] ITU-T Recommendation I.555, "Frame Relay Bearer Service Interworking", September 1997. [10] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [11] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999. [12] The ATM Forum, "ATM Security Framework Version 1.0", af-sec-0096.000, February 1998. [13] The ATM Forum, "ATM Security Specification v1.0", af-sec-0100.001, February 1999. 附录 A RF-SSCS 上的多协议封装 ITU-T 建议 I.365.1 定义了帧中继特定汇聚子层(Frame Relaying Specific Convergence Sublayer, FR- SSCS)，该子层位于帧中继/ATM 互连中 AAL5 的公共部分汇聚子层(Common Part Convergence Sublayer, CPCS)的上面。由 FR-SSCS 提供的服务对应 I.233 中描述的帧中 继核心服务。 FR-SSCS-PDU 由 Q.922 地址字段及紧跟其后的 Q.922 信息字段构成。忽略 Q.922 标记 和 FCS，因为对应功能可由 AAL 提供。嵌入 AAL5 CPCS-PDU 净荷内的 FR-SSCS-PDU 如 图 19 所示。 Q.922地址字段 (2-4字节) Q.922信息字段 AAL5 CPCS-PDU尾部 ··· ··· FR-SSCS- PDU首部 FR-SSCS- PDU净荷 图 19 AAL5 CPCS-PDU 的净荷内的 FR-SSCS-PDU 格式 路由 PDU 和桥接 PDU 被封装在 FR-SSCS-PDU 内，正如 RFC2427 所定义的。 Q.922 信息字段以 Q.922 控制字段开始，跟着是可选的填充字节，填充字节用于将帧的 其余部分对齐到发送者方便的边界。接着，把 ISO/IEC TR9577 网络层协议 ID(NLPID)加到 PDU 前，标识携带 PDU 的协议。 在 IP PDU 情况，NLPID 为 0xCC，FR-SSCS-PDU 格式如图 20 所示。 Q.922地址字段 (2或4字节) IP PDU (最大216-5字节) ··· ··· 0x03 (Q.922控制) NLPID 0xCC 图 20 路由 IP PDU 的 FR-SSCS-PDU 格式 注意，按照 RFC2427，Q.922 地址字段应当是 2 或 4 字节，即，必须不使用 3 字节地址 字段。 在 CLNP PDU 情况，NLPID 是 0x81，FR-SSCS-PDU 格式如图 21 所示。 Q.922地址字段 (2或4字节) CLNP PDU其余部分 (最大216-5字节) ··· ··· 0x03 (Q.922控制) NLPID 0x81 图 21 路由 CLNP PDU 的 FR-SSCS-PDU 格式 注意，在 ISO 协议情况，NLPID 字段构成 PDU 自身的第一个字节，并且必须不能重复。 上述封装仅适用于有唯一分配的 NLPID 的路由协议。其他路由协议(以及桥接协议)，必须 提供另一种容易协议识别的机制。为实现此，可用值为 0x80 的 NLPID 指出 IEEE 802.1a 子 网附着点(SubNetwork Attachment Point, SNAP)首部跟随其后。 FRCS 上多协议封装的更多内容参阅 RFC2427。 附录 B OUI 00-80-C2 的本地分配值列表 保留 FCS 保留 FCS 的 w/o 媒介 0x00-01 0x00-07 802.3/以太网 0x00-02 0x00-08 802.4 0x00-03 0x00-09 802.5 0x00-04 0x00-0A FDDI 0x00-05 0x00-0B 802.6 0x00-0D 分段 0x00-0E BPDUs 附录 C 部分 NLPID 列表 0x00 空网络层或未激活集合(ATM不使用) 0x80 SNAP 0x81 ISO CLNP 0x82 ISO ESIS 0x83 ISO ISIS 0xCC 互联网 IP 附录 D 多协议封装应用 对于 ATM 网络上的路由和桥接来讲，多协议封装是必须的，但通常是不够的。自从 RFC1483(本备忘录的前身)发布以来，IETF 和 ATM 论坛开发了多种系统标准，以便处理各 个方面(各类场景)的桥接和路由协议。本附录归纳这些应用。 1）路由器和网桥间点对点连接 ATM PVCs 上多协议封装已经用于提供跨 ATM 网络，网桥和路由器间简单的点对点链 路。在这些场景，一定数量的人工配置(例如，代替 INARP)是必须的。 2）经典 IPoA RFC2225(RFC1577 的演进协议)提供一种环境，那里 ATM 网络用作逻辑 IP 子网(LIS)。 支持 ATM PVC，由 INARP 提供地址解析。对于 ATM SVC，提供新形式的 ARP、ATMARP， 以及在 ATM 网络上主机(或路由器)和 ATMARP 服务器间的操作。在那里，使用 RFC2335 定义的服务器同步缓存协议(Server Synchronization Cache Protocol, SCSP)，服务器被复制， 以便提供高可用性和高性能。经典 IPoA 默认采用 LLC/SNAP 封装。 3）LAN 仿真(LANE) ATM 论坛 LAN 仿真标准提供了一种环境，那里 ATM 网络由 LAN 仿真服务器增强， 于是，ATM 网络行为好像桥接 LAN。经过注册，站点从 LAN 仿真配置服务器获得配置信 息；借助 LAN 仿真服务器的支持站点将 MAC 地址解析为 ATM 地址；站点能够发送广播和 多播帧，当站点没有直接 VC 连接到广播和单播服务器时，站点也发送单播帧。对于数据直 传、LE 多播发送和多播转发 VCCS，在桥接以太网/802.3(无 LAN FCS)或桥接 802.5(无 LAN FCS)情况，LANE 均使用 VC 多路复用封装格式。然而，本备忘录描述的起始 PAD 字段用 作 LE 首部，或许不能设置为全 0。 4）下一跳解析协议(NHRP) 在某些情况，经典 IPoA 服务仅能是单个 LIS 的局限性限制了系统性能。NHRP，正如 RFC2332 定义的，扩展了经典 IPoA，允许数据经由一条“捷径”，在支持多个 LIS 的 ATM 网络上传送。 5）ATM 上的多协议(MPoA) ATM 论坛的 ATM 上多协议标准集成了 LANE 和 NHRP，提供通用桥接/路由环境。 6）IP 多播 RFC2022 扩展了经典 IPoA 到支持 IP 多播。多播地址解析服务器(MARS)与多播服务器 合作，在 ATM 点对多点、以及点对点虚连接上共同工作，提供 IP 多播传送。 7）PPPoATM RFC2364 扩展了 ATM 上多播协议到这样的情况，那里，封装协议是点对点协议。不仅 使用 VC 多路复用封装，而且使用 LLC/SNAP 封装。当 ATM 网络用于点对点链路并且需要 PPP 功能时使用此方法。 附录 E 与 RFC1483 的不同 本备忘录代替了 RFC1483。目的是与时俱进，对实现者发现的或由于基础标准发生改 变造成的模糊点做一个澄清。这项工作由 IETF 标准跟踪过程完成。许多编辑上的改进已经 做出， RFC2119[10]惯例开始应用，以及添加对目前 RFC 的介绍。对 RFC1483 做出下述改 变，它们中没有一项废弃了 RFC1483 的实际执行。 · 用 RFC2119 习惯术语说明 NLPID 封装应用。 · 指出加入 RFC2364 来覆盖 ATM 上 PPP 情况。 · 用 RFC1755 和 RFC2331 作为参考，来描述封装如何协商，而不是使用长期废弃的 CCITT(现在的 ITU-T)工作文献，参考工作在进行中。 · AAL5 的应用现在参考 ITU-T I.363.5。选项在 AAL5 中生成，因为选择发布 RFC1483。 · 澄清了路由 NLPID 格式 PDUs 的形成(称作 RFC1483 内的“路由 ISO PDU”)。 · 说明了在桥接 PDU，以及 MAC 地址比特顺序中，PID 和 MAC 目的地地址间填充的应用。 · 说明了以太网/802.3 帧填充的应用。 · 添加了一种新的 VPNs 封装。 · 添加了现实的安全考虑。 · 添加附录 D 来归纳 ATM 上多协议应用。 撰写者通讯录 Dan Grossman Motorola, Inc. 20 Cabot Blvd. Mansfield, MA 02048 EMail: dan@dma.isg.mot.com Juha Heinanen Telia Finland Myyrmaentie 2 01600 Vantaa, Finland EMail: jh@telia.fi 完整的版权声明 Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 致谢 Funding for the RFC Editor function is currently provided by the Internet Society.