Network Working Group                                 A. Vainshtein, Ed.
Request for Comments: 4553                               Axerra Networks
Category: Standards Track                                 YJ. Stein, Ed.
                                                 RAD Data Communications
                                                               June 2006
        
Network Working Group                                 A. Vainshtein, Ed.
Request for Comments: 4553                               Axerra Networks
Category: Standards Track                                 YJ. Stein, Ed.
                                                 RAD Data Communications
                                                               June 2006
        

Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)

结构无关的分组时分复用(TDM)(SAToP)

Status of This Memo

关于下段备忘

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2006).

版权所有(C)互联网协会(2006年)。

Abstract

摘要

This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing.

本文档描述了用于时分复用(TDM)比特流(T1、E1、T3、E3)的伪线封装,其忽略了可能施加在这些流上的任何结构,尤其是由标准TDM帧施加的结构。

Table of Contents

目录

   1. Introduction ....................................................3
   2. Terminology and Reference Models ................................3
      2.1. Terminology ................................................3
      2.2. Reference Models ...........................................4
   3. Emulated Services ...............................................4
   4. SAToP Encapsulation Layer .......................................5
      4.1. SAToP Packet Format ........................................5
      4.2. PSN and PW Demultiplexing Layer Headers ....................5
      4.3. SAToP Header ...............................................6
           4.3.1. Usage and Structure of the Control Word .............8
           4.3.2. Usage of RTP Header .................................9
   5. SAToP Payload Layer ............................................10
      5.1. General Payloads ..........................................10
      5.2. Octet-Aligned T1 ..........................................11
   6. SAToP Operation ................................................12
      6.1. Common Considerations .....................................12
      6.2. IWF Operation .............................................12
           6.2.1. PSN-Bound Direction ................................12
           6.2.2. CE-Bound Direction .................................13
      6.3. SAToP Defects .............................................14
      6.4. SAToP PW Performance Monitoring ...........................15
   7. Quality of Service (QoS) Issues ................................16
   8. Congestion Control .............................................16
   9. Security Considerations ........................................18
   10. Applicability Statement .......................................18
   11. IANA Considerations ...........................................20
   12. Acknowledgements ..............................................20
   13. Co-Authors ....................................................20
   14. Normative References ..........................................21
   15. Informative References ........................................22
   Appendix A: Old Mode of SAToP Encapsulation over L2TPv3 ...........24
   Appendix B: Parameters That MUST Be Agreed upon during the PW
               Setup .................................................24
        
   1. Introduction ....................................................3
   2. Terminology and Reference Models ................................3
      2.1. Terminology ................................................3
      2.2. Reference Models ...........................................4
   3. Emulated Services ...............................................4
   4. SAToP Encapsulation Layer .......................................5
      4.1. SAToP Packet Format ........................................5
      4.2. PSN and PW Demultiplexing Layer Headers ....................5
      4.3. SAToP Header ...............................................6
           4.3.1. Usage and Structure of the Control Word .............8
           4.3.2. Usage of RTP Header .................................9
   5. SAToP Payload Layer ............................................10
      5.1. General Payloads ..........................................10
      5.2. Octet-Aligned T1 ..........................................11
   6. SAToP Operation ................................................12
      6.1. Common Considerations .....................................12
      6.2. IWF Operation .............................................12
           6.2.1. PSN-Bound Direction ................................12
           6.2.2. CE-Bound Direction .................................13
      6.3. SAToP Defects .............................................14
      6.4. SAToP PW Performance Monitoring ...........................15
   7. Quality of Service (QoS) Issues ................................16
   8. Congestion Control .............................................16
   9. Security Considerations ........................................18
   10. Applicability Statement .......................................18
   11. IANA Considerations ...........................................20
   12. Acknowledgements ..............................................20
   13. Co-Authors ....................................................20
   14. Normative References ..........................................21
   15. Informative References ........................................22
   Appendix A: Old Mode of SAToP Encapsulation over L2TPv3 ...........24
   Appendix B: Parameters That MUST Be Agreed upon during the PW
               Setup .................................................24
        
1. Introduction
1. 介绍

This document describes a method for encapsulating Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) as pseudowires over packet-switching networks (PSN). It addresses only structure-agnostic transport, i.e., the protocol completely disregards any structure that may possibly be imposed on these signals, in particular the structure imposed by standard TDM framing [G.704]. This emulation is referred to as "emulation of unstructured TDM circuits" in [RFC4197] and suits applications where the PEs have no need to interpret TDM data or to participate in the TDM signaling.

本文档描述了一种通过分组交换网络(PSN)将时分复用(TDM)比特流(T1、E1、T3、E3)封装为伪线的方法。它只处理结构不可知传输,即协议完全忽略可能施加在这些信号上的任何结构,特别是标准TDM帧施加的结构[G.704]。该仿真在[RFC4197]中称为“非结构化TDM电路仿真”,适用于PEs无需解释TDM数据或参与TDM信令的应用。

The SAToP solution presented in this document conforms to the PWE3 architecture described in [RFC3985] and satisfies both the relevant general requirements put forward in [RFC3916] and specific requirements for unstructured TDM signals presented in [RFC4197].

本文件中提出的SAToP解决方案符合[RFC3985]中描述的PWE3体系结构,并满足[RFC3916]中提出的相关一般要求和[RFC4197]中提出的非结构化TDM信号的具体要求。

As with all PWs, SAToP PWs may be manually configured or set up using the PWE3 control protocol [RFC4447]. Extensions to the PWE3 control protocol required for setup and maintenance of SAToP pseudowires and allocations of code points used for this purpose are described in separate documents ([TDM-CONTROL] and [RFC4446], respectively).

与所有PWs一样,可使用PWE3控制协议[RFC4447]手动配置或设置SAToP PWs。设置和维护SAToP伪线所需的PWE3控制协议扩展以及用于此目的的代码点分配在单独的文件中进行了描述([TDM-control]和[RFC4446])。

2. Terminology and Reference Models
2. 术语和参考模型

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。

2.1. Terminology
2.1. 术语

The following acronyms used in this document are defined in [RFC3985] and [RFC4197]:

[RFC3985]和[RFC4197]中定义了本文件中使用的以下首字母缩略词:

ATM Asynchronous Transfer Mode CE Customer Edge CES Circuit Emulation Service NSP Native Service Processing PE Provider Edge PDH Plesiochronous Digital Hierarchy PW Pseudowire SDH Synchronous Digital Hierarchy SONET Synchronous Optical Network TDM Time Division Multiplexing

ATM异步传输模式CE客户边缘CE电路仿真服务NSP本地服务处理PE提供商边缘PDH准同步数字体系PW伪线SDH同步数字体系SONET同步光网络TDM时分复用

In addition, the following TDM-specific terms are needed:

此外,还需要以下TDM专用条款:

o Loss of Signal (LOS) - a condition of the TDM attachment circuit wherein the incoming signal cannot be detected. Criteria for entering and leaving the LOS condition can be found in [G.775].

o 信号丢失(LOS)-TDM连接电路的一种状态,其中无法检测到输入信号。进入和离开服务水平条件的标准见[G.775]。

o Alarm Indication Signal (AIS) - a special bit pattern (e.g., as described in [G.775]) in the TDM bit stream that indicates presence of an upstream circuit outage. For E1, T1, and E3 circuits, the AIS pattern is a sequence of binary "1" values of appropriate duration (the "all ones" pattern), and hence it can be detected and generated by structure-agnostic means. The T3 AIS pattern requires T3 framing (see [G.704], Section 2.5.3.6.1) and hence can only be handled by a structure-aware NSP.

o 报警指示信号(AIS)-TDM比特流中的一种特殊比特模式(如[g.775]中所述),用于指示存在上游电路中断。对于E1、T1和E3电路,AIS模式是具有适当持续时间的二进制“1”值序列(“所有1”模式),因此可以通过结构不可知的方式检测和生成。T3 AIS模式需要T3帧(见[G.704],第2.5.3.6.1节),因此只能由结构感知NSP处理。

We also use the term Interworking Function (IWF) to describe the functional block that segments and encapsulates TDM into SAToP packets and that in the reverse direction decapsulates SAToP packets and reconstitutes TDM.

我们还使用术语互通功能(IWF)来描述将TDM分段并封装到SAToP数据包中的功能块,以及反向将SAToP数据包解封并重构TDM的功能块。

2.2. Reference Models
2.2. 参考模型

The generic models defined in Sections 4.1, 4.2, and 4.4 of [RFC3985] fully apply to SAToP.

[RFC3985]第4.1、4.2和4.4节中定义的通用模型完全适用于SAToP。

The native service addressed in this document is a special case of the bit stream payload type defined in Section 3.3.3 of [RFC3985].

本文档中介绍的本机服务是[RFC3985]第3.3.3节中定义的比特流有效负载类型的特例。

The Network Synchronization reference model and deployment scenarios for emulation of TDM services are described in [RFC4197], Section 4.3.

[RFC4197]第4.3节描述了TDM服务仿真的网络同步参考模型和部署场景。

3. Emulated Services
3. 模拟服务

This specification describes edge-to-edge emulation of the following TDM services described in [G.702]:

本规范描述了[G.702]中描述的以下TDM服务的边到边仿真:

1. E1 (2048 kbit/s) 2. T1 (1544 kbit/s); this service is also known as DS1 3. E3 (34368 kbit/s) 4. T3 (44736 kbit/s); this service is also known as DS3

1. E1(2048kbit/s)2。T1(1544kbit/s);此服务也称为DS1 3。E3(34368千比特/秒)4。T3(44736kbit/s);此服务也称为DS3

The protocol used for emulation of these services does not depend on the method in which attachment circuits are delivered to the PEs. For example, a T1 attachment circuit is treated in the same way

用于模拟这些服务的协议不依赖于将连接电路交付给PEs的方法。例如,T1连接电路的处理方式相同

regardless of whether it is delivered to the PE on copper [G.703], multiplexed in a T3 circuit [T1.107], mapped into a virtual tributary of a SONET/SDH circuit [G.707], or carried over an ATM network using unstructured ATM Circuit Emulation Service (CES) [ATM-CES]. Termination of any specific "carrier layers" used between the PE and CE is performed by an appropriate NSP.

无论它是在铜缆[G.703]上交付给PE,在T3电路[T1.107]中复用,映射到SONET/SDH电路[G.707]的虚拟支路,还是使用非结构化ATM电路仿真服务(CES)[ATM-CES]通过ATM网络传输。由适当的NSP终止PE和CE之间使用的任何特定“载体层”。

4. SAToP Encapsulation Layer
4. SAToP封装层
4.1. SAToP Packet Format
4.1. SAToP数据包格式

The basic format of SAToP packets is shown in Figure 1 below.

SAToP数据包的基本格式如下图1所示。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   |              PSN and PW demultiplexing layer headers          |
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                             ...                               |
   +--                                                           --+
   |                   SAToP Encapsulation Header                  |
   +--                                                           --+
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                             ...                               |
   |                        TDM data (Payload)                     |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   |              PSN and PW demultiplexing layer headers          |
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                             ...                               |
   +--                                                           --+
   |                   SAToP Encapsulation Header                  |
   +--                                                           --+
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                             ...                               |
   |                        TDM data (Payload)                     |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 1. Basic SAToP Packet Format

图1。基本SAToP数据包格式

4.2. PSN and PW Demultiplexing Layer Headers
4.2. PSN和PW解复用层报头

Both UDP and L2TPv3 [RFC3931] can provide the PW demultiplexing mechanisms for SAToP PWs over an IPv4/IPv6 PSN. The PW label provides the demultiplexing function for an MPLS PSN as described in Section 5.4.2 of [RFC3985].

UDP和L2TPv3[RFC3931]都可以通过IPv4/IPv6 PSN为SAToP PWs提供PW解复用机制。PW标签为MPLS PSN提供解复用功能,如[RFC3985]第5.4.2节所述。

The total size of a SAToP packet for a specific PW MUST NOT exceed path MTU between the pair of PEs terminating this PW. SAToP implementations using IPv4 PSN MUST mark the IPv4 datagrams they generate as "Don't Fragment" [RFC791] (see also [PWE3-FRAG]).

特定PW的SAToP数据包的总大小不得超过终止该PW的PEs对之间的路径MTU。使用IPv4 PSN的SAToP实现必须将它们生成的IPv4数据报标记为“不分段”[RFC791](另请参见[PWE3-FRAG])。

4.3. SAToP Header
4.3. 萨托普收割台

The SAToP header MUST contain the SAToP Control Word (4 bytes) and MAY also contain a fixed RTP header [RFC3550]. If the RTP header is included in the SAToP header, it MUST immediately follow the SAToP control word in all cases except UDP multiplexing, where it MUST precede it (see Figures 2a, 2b, and 2c below).

SAToP报头必须包含SAToP控制字(4字节),还可能包含固定RTP报头[RFC3550]。如果RTP报头包含在SAToP报头中,则在除UDP多路复用外的所有情况下,RTP报头必须紧跟在SAToP控制字之后,而UDP多路复用必须在RTP报头之前(参见下面的图2a、2b和2c)。

Note: Such an arrangement complies with the traditional usage of RTP for the IPv4/IPv6 PSN with UDP multiplexing while making SAToP PWs Equal Cost Multi-Path (ECMP)-safe for the MPLS PSN by providing for PW-IP packet discrimination (see [RFC3985], Section 5.4.3). Furthermore, it facilitates seamless stitching of L2TPv3-based and MPLS-based segments of SAToP PWs (see [PWE3-MS]).

注:这种安排符合IPv4/IPv6 PSN的RTP的传统用法,采用UDP多路复用,同时通过提供PW-IP数据包鉴别,使SAToP PWs对MPLS PSN具有同等成本的多路径(ECMP)-安全性(见[RFC3985],第5.4.3节)。此外,它有助于SAToP PWs基于L2TPv3和基于MPLS的段的无缝拼接(参见[PWE3-MS])。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   |       IPv4/IPv6 and UDP (PW demultiplexing layer) headers     |
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |
   +--                     OPTIONAL                              --+
   |                                                               |
   +--               Fixed RTP Header (see [RFC3550])            --+
   |                                                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                  SAToP Control Word                           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                            ...                                |
   |                      TDM data (Payload)                       |
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   |       IPv4/IPv6 and UDP (PW demultiplexing layer) headers     |
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |
   +--                     OPTIONAL                              --+
   |                                                               |
   +--               Fixed RTP Header (see [RFC3550])            --+
   |                                                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                  SAToP Control Word                           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                            ...                                |
   |                      TDM data (Payload)                       |
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 2a. SAToP Packet Format for an IPv4/IPv6 PSN with UDP PW Demultiplexing

图2a。具有UDP PW解复用的IPv4/IPv6 PSN的SAToP数据包格式

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   |     IPv4/IPv6 and L2TPv3 (PW demultiplexing layer) headers    |
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                  SAToP Control Word                           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |
   +--                     OPTIONAL                              --+
   |                                                               |
   +--               Fixed RTP Header (see [RFC3550])            --+
   |                                                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                             ...                               |
   |                       TDM data (Payload)                      |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   |     IPv4/IPv6 and L2TPv3 (PW demultiplexing layer) headers    |
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                  SAToP Control Word                           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |
   +--                     OPTIONAL                              --+
   |                                                               |
   +--               Fixed RTP Header (see [RFC3550])            --+
   |                                                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                             ...                               |
   |                       TDM data (Payload)                      |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 2b. SAToP Packet Format for an IPv4/IPv6 PSN with L2TPv3 PW Demultiplexing

图2b。具有L2TPv3 PW解复用的IPv4/IPv6 PSN的SAToP数据包格式

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   |                      MPLS Label Stack                         |
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                  SAToP Control Word                           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |
   +--                     OPTIONAL                              --+
   |                                                               |
   +--               Fixed RTP Header (see [RFC3550])            --+
   |                                                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                             ...                               |
   |                       TDM data (Payload)                      |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   |                      MPLS Label Stack                         |
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                  SAToP Control Word                           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |
   +--                     OPTIONAL                              --+
   |                                                               |
   +--               Fixed RTP Header (see [RFC3550])            --+
   |                                                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                             ...                               |
   |                       TDM data (Payload)                      |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 2c. SAToP Packet Format for an MPLS PSN

图2c。MPLS PSN的SAToP数据包格式

4.3.1. Usage and Structure of the Control Word
4.3.1. 控制字的用法和结构

Usage of the SAToP control word allows:

使用SAToP控制字允许:

1. Detection of packet loss or misordering 2. Differentiation between the PSN and attachment circuit problems as causes for the outage of the emulated service 3. PSN bandwidth conservation by not transferring invalid data (AIS) 4. Signaling of faults detected at the PW egress to the PW ingress.

1. 检测数据包丢失或错误排序2。PSN和连接电路问题之间的区别是模拟服务中断的原因3。通过不传输无效数据来节省PSN带宽(AIS)4。向PW入口发送PW出口检测到的故障信号。

The structure of the SAToP Control Word is shown in Figure 3 below.

SAToP控制字的结构如下图3所示。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0|L|R|RSV|FRG|   LEN     |       Sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0|L|R|RSV|FRG|   LEN     |       Sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 3. Structure of the SAToP Control Word

图3。SAToP控制字的结构

The use of Bits 0 to 3 is described in [RFC4385]. These bits MUST be set to zero unless they are being used to indicate the start of an Associated Channel Header (ACH). An ACH is needed if the state of the SAToP PW is being monitored using Virtual Circuit Connectivity Verification [PWE3-VCCV].

[RFC4385]中描述了位0到3的使用。这些位必须设置为零,除非它们用于指示相关信道头(ACH)的开始。如果使用虚拟电路连接验证[PWE3-VCCV]监控SAToP PW的状态,则需要ACH。

L - If set, indicates that TDM data carried in the payload is invalid due to an attachment circuit fault. When the L bit is set the payload MAY be omitted in order to conserve bandwidth. The CE-bound IWF MUST play out an appropriate amount of filler data regardless of the payload size. Once set, if the fault is rectified, the L bit MUST be cleared.

L-如果设置,则表示由于附件电路故障,有效负载中携带的TDM数据无效。当设置L位时,可省略有效载荷以节省带宽。绑定CE的IWF必须播放适当数量的填充数据,而不管有效负载大小。一旦设置,如果故障得到纠正,则必须清除L位。

Note: This document does not specify which TDM fault conditions are treated as invalidating the data carried in the SAToP packets. Possible examples include, but are not limited to LOS and AIS.

注:本文件未规定将哪些TDM故障条件视为使SAToP数据包中携带的数据无效。可能的例子包括但不限于服务水平和人工智能。

R - If set by the PSN-bound IWF, indicates that its local CE-bound IWF is in the packet loss state, i.e., has lost a preconfigured number of consecutive packets. The R bit MUST be cleared by the PSN-bound IWF once its local CE-bound IWF has exited the packet loss state, i.e., has received a preconfigured number of consecutive packets.

R-如果由PSN绑定的IWF设置,则表示其本地CE绑定的IWF处于丢包状态,即丢失了预配置数量的连续数据包。一旦绑定到PSN的IWF的本地CE的IWF退出丢包状态,即接收到预配置数量的连续数据包,则必须由绑定到PSN的IWF清除R位。

RSV and FRG (bits 6 to 9) - MUST be set to 0 by the PSN-bound IWF and MUST be ignored by the CE-bound IWF. RSV is reserved. FRG is fragmentation; see [PWE3-FRAG].

RSV和FRG(位6到9)-必须由PSN绑定的IWF设置为0,并且必须由CE绑定的IWF忽略。保留RSV。FRG是碎片;见[PWE3-FRAG]。

LEN (bits 10 to 15) - MAY be used to carry the length of the SAToP packet (defined as the size of the SAToP header + the payload size) if it is less than 64 bytes, and MUST be set to zero otherwise. When the LEN field is set to 0, the preconfigured size of the SAToP packet payload MUST be assumed to be as described in Section 5.1, and if the actual packet size is inconsistent with this length, the packet MUST be considered malformed.

LEN(位10至15)-如果小于64字节,则可用于承载SAToP数据包的长度(定义为SAToP头的大小+有效负载大小),否则必须设置为零。当LEN字段设置为0时,必须假设SAToP数据包有效载荷的预配置大小如第5.1节所述,并且如果实际数据包大小与该长度不一致,则必须认为数据包格式不正确。

Sequence number - used to provide the common PW sequencing function as well as detection of lost packets. It MUST be generated in accordance with the rules defined in Section 5.1 of [RFC3550] for the RTP sequence number:

序列号-用于提供公共PW序列功能以及检测丢失的数据包。必须根据[RFC3550]第5.1节规定的RTP序列号规则生成:

o Its space is a 16-bit unsigned circular space o Its initial value SHOULD be random (unpredictable).

o 它的空间是一个16位无符号循环空间,其初始值应该是随机的(不可预测的)。

It MUST be incremented with each SAToP data packet sent in the specific PW.

它必须随着在特定PW中发送的每个SAToP数据包而递增。

4.3.2. Usage of RTP Header
4.3.2. RTP报头的使用

When RTP is used, the following fields of the fixed RTP header (see [RFC3550], Section 5.1) MUST be set to zero: P (padding), X (header extension), CC (CSRC count), and M (marker).

使用RTP时,固定RTP报头的以下字段(见[RFC3550],第5.1节)必须设置为零:P(填充)、X(报头扩展)、CC(CSC计数)和M(标记)。

The PT (payload type) field is used as follows:

PT(有效负载类型)字段的使用方式如下:

1. One PT value MUST be allocated from the range of dynamic values (see [RTP-TYPES]) for each direction of the PW. The same PT value MAY be reused for both directions of the PW and also reused between different PWs.

1. 必须从PW每个方向的动态值范围(见[RTP-TYPES])中分配一个PT值。相同的PT值可在PW的两个方向重复使用,也可在不同PW之间重复使用。

2. The PSN-bound IWF MUST set the PT field in the RTP header to the allocated value.

2. 绑定PSN的IWF必须将RTP头中的PT字段设置为已分配的值。

3. The CE-bound IWF MAY use the received value to detect malformed packets.

3. 绑定到CE的IWF可以使用接收到的值来检测格式错误的分组。

The sequence number MUST be the same as the sequence number in the SAToP control word.

序列号必须与SAToP控制字中的序列号相同。

The RTP timestamps are used for carrying timing information over the network. Their values are generated in accordance with the rules established in [RFC3550].

RTP时间戳用于通过网络传输定时信息。根据[RFC3550]中建立的规则生成其值。

The frequency of the clock used for generating timestamps MUST be an integer multiple of 8 kHz. All implementations of SAToP MUST support the 8 kHz clock. Other multiples of 8 kHz MAY be used.

用于生成时间戳的时钟频率必须是8 kHz的整数倍。SAToP的所有实现必须支持8 kHz时钟。可使用8 kHz的其他倍数。

The SSRC (synchronization source) value in the RTP header MAY be used for detection of misconnections, i.e., incorrect interconnection of attachment circuits.

RTP报头中的SSRC(同步源)值可用于检测错误连接,即连接电路的不正确互连。

Timestamp generation MAY be used in the following modes:

时间戳生成可在以下模式下使用:

1. Absolute mode: The PSN-bound IWF sets timestamps using the clock recovered from the incoming TDM attachment circuit. As a consequence, the timestamps are closely correlated with the sequence numbers. All SAToP implementations that support usage of the RTP header MUST support this mode. 2. Differential mode: Both IWFs have access to a common high-quality timing source, and this source is used for timestamp generation. Support of this mode is OPTIONAL.

1. 绝对模式:PSN绑定IWF使用从传入TDM连接电路恢复的时钟设置时间戳。因此,时间戳与序列号密切相关。所有支持使用RTP报头的SAToP实现都必须支持此模式。2.差分模式:两个IWF都可以访问公共的高质量计时源,该源用于生成时间戳。此模式的支持是可选的。

Usage of the fixed RTP header in a SAToP PW and all the options associated with its usage (the timestamping clock frequency, the timestamping mode, selected PT and SSRC values) MUST be agreed upon between the two SAToP IWFs during PW setup as described in [TDM-CONTROL]. Other, RTP-specific methods (e.g., see [RFC3551]) MUST NOT be used.

如[TDM-CONTROL]所述,在PW设置期间,两个SAToP IWF之间必须就固定RTP报头在SAToP PW中的使用及其使用相关的所有选项(时间戳时钟频率、时间戳模式、选定PT和SSRC值)达成一致。不得使用其他RTP特定方法(如参见[RFC3551])。

5. SAToP Payload Layer
5. SAToP有效载荷层
5.1. General Payloads
5.1. 一般有效载荷

In order to facilitate handling of packet loss in the PSN, all packets belonging to a given SAToP PW are REQUIRED to carry a fixed number of bytes filled with TDM data received from the attachment circuit. The packet payload size MUST be defined during the PW setup, MUST be the same for both directions of the PW, and MUST remain unchanged for the lifetime of the PW.

为了便于处理PSN中的分组丢失,属于给定SAToP PW的所有分组都需要携带固定数量的字节,该字节填充了从连接电路接收的TDM数据。数据包有效负载大小必须在PW设置期间定义,在PW的两个方向上必须相同,并且在PW的生命周期内必须保持不变。

The CE-bound and PSN-bound IWFs MUST agree on SAToP packet payload size during PW setup (default payload size values defined below guarantee that such an agreement is always possible). The SAToP packet payload size can be exchanged over the PWE3 control protocol ([TDM-CONTROL]) by using the Circuit Emulation over Packet (CEP)/TDM Payload Bytes sub-TLV of the Interface Parameters TLV ([RFC4446]).

在PW设置期间,绑定CE和PSN的IWF必须就SAToP数据包有效负载大小达成一致(下面定义的默认有效负载大小值保证始终可以达成一致)。通过使用接口参数TLV([RFC4446])的包上电路仿真(CEP)/TDM有效负载字节子TLV,可通过PWE3控制协议([TDM-control])交换SAToP包有效负载大小。

SAToP uses the following ordering for packetization of the TDM data:

SAToP使用以下顺序对TDM数据进行打包:

o The order of the payload bytes corresponds to their order on the attachment circuit.

o 有效负载字节的顺序对应于它们在附件电路上的顺序。

o Consecutive bits coming from the attachment circuit fill each payload byte starting from most significant bit to least significant.

o 来自附件电路的连续位填充从最高有效位到最低有效位的每个有效负载字节。

All SAToP implementations MUST be capable of supporting the following payload sizes:

所有SAToP实施必须能够支持以下有效负载大小:

o E1 - 256 bytes o T1 - 192 bytes o E3 and T3 - 1024 bytes.

o E1-256字节Ot1-192字节Oe3和T3-1024字节。

Notes:

笔记:

1. Whatever the selected payload size, SAToP does not assume alignment to any underlying structure imposed by TDM framing (byte, frame, or multiframe alignment). 2. When the L bit in the SAToP control word is set, SAToP packets MAY omit invalid TDM data in order to conserve PSN bandwidth. 3. Payload sizes that are multiples of 47 bytes MAY be used in conjunction with unstructured ATM-CES [ATM-CES].

1. 无论选择的有效负载大小如何,SAToP都不会假定与TDM帧(字节、帧或多帧对齐)施加的任何底层结构对齐。2.当设置了SAToP控制字中的L位时,SAToP数据包可能会忽略无效的TDM数据,以节省PSN带宽。3.47字节倍数的有效负载大小可与非结构化ATM-CES[ATM-CES]结合使用。

5.2. Octet-Aligned T1
5.2. 八位组对齐T1

An unstructured T1 attachment circuit is sometimes provided already padded to an integer number of bytes, as described in Annex B of [G.802]. This occurs when the T1 is de-mapped from a SONET/SDH virtual tributary/container, or when it is de-framed by a dual-mode E1/T1 framer.

如[G.802]附录B所述,有时提供的非结构化T1连接电路已经填充到整数字节数。当T1从SONET/SDH虚拟支路/容器去映射时,或当T1由双模E1/T1成帧器去帧时,会发生这种情况。

In order to facilitate operation in such cases, SAToP defines a special "octet-aligned T1" transport mode. In this mode, the SAToP payload consists of a number of 25-byte subframes, each subframe carrying 193 bits of TDM data and 7 bits of padding. This mode is depicted in Figure 4 below.

为了便于在这种情况下操作,SAToP定义了一种特殊的“八位组对齐T1”传输模式。在此模式下,SAToP有效载荷由多个25字节的子帧组成,每个子帧承载193位TDM数据和7位填充。此模式如下图4所示。

      |     1         |        2      | ...   |      25       |
      |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| ...   |0 1 2 3 4 5 6 7|
      |=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |           TDM Data                      |  padding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            .................................          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           TDM Data                      |  padding    |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
        
      |     1         |        2      | ...   |      25       |
      |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| ...   |0 1 2 3 4 5 6 7|
      |=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |           TDM Data                      |  padding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            .................................          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           TDM Data                      |  padding    |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
        

Figure 4. SAToP Payload Format for Octet-Aligned T1 Transport

图4。八位组对齐T1传输的SAToP有效负载格式

Notes:

笔记:

1. No alignment with the framing structure that may be imposed on the T1 bit-stream is implied. 2. An additional advantage of the octet-aligned T1 transport mode is the ability to select the SAToP packetization latency as an arbitrary integer multiple of 125 microseconds.

1. 不暗示与可能施加在T1比特流上的帧结构对齐。2.八位组对齐T1传输模式的另一个优点是能够将SAToP打包延迟选择为125微秒的任意整数倍。

Support of the octet-aligned T1 transport mode is OPTIONAL. An octet-aligned T1 SAToP PW is not interoperable with a T1 SAToP PW that carries a non-aligned bit-stream, as described in the previous section.

支持八位组对齐T1传输模式是可选的。如前一节所述,八位组对齐的T1 SAToP PW不能与携带非对齐位流的T1 SAToP PW互操作。

Implementations supporting octet-aligned T1 transport mode MUST be capable of supporting a payload size of 200 bytes (i.e., a payload of eight 25-byte subframes) corresponding to precisely 1 millisecond of TDM data.

支持八位组对齐T1传输模式的实现必须能够支持200字节的有效负载大小(即,8个25字节子帧的有效负载),对应于正好1毫秒的TDM数据。

6. SAToP Operation
6. SAToP操作
6.1. Common Considerations
6.1. 共同考虑

Edge-to-edge emulation of a TDM service using SAToP is only possible when the two PW attachment circuits are of the same type (T1, E1, T3, E3). The service type is exchanged at PW setup as described in [RFC4447].

只有当两个PW连接电路属于同一类型(T1、E1、T3、E3)时,才可能使用SAToP对TDM服务进行边到边仿真。服务类型在PW设置时交换,如[RFC4447]所述。

6.2. IWF Operation
6.2. IWF操作
6.2.1. PSN-Bound Direction
6.2.1. PSN束缚方向

Once the PW is set up, the PSN-bound SAToP IWF operates as follows:

一旦设置了PW,绑定PSN的SAToP IWF将按如下方式运行:

TDM data is packetized using the configured number of payload bytes per packet.

TDM数据使用每个数据包配置的有效负载字节数进行打包。

Sequence numbers, flags, and timestamps (if the RTP header is used) are inserted in the SAToP headers.

序列号、标志和时间戳(如果使用RTP报头)插入到SAToP报头中。

SAToP, PW demultiplexing layer, and PSN headers are prepended to the packetized service data.

将SAToP、PW解复用层和PSN报头添加到打包服务数据中。

The resulting packets are transmitted over the PSN.

产生的数据包通过PSN传输。

6.2.2. CE-Bound Direction
6.2.2. CE界方向

The CE-bound SAToP IWF SHOULD include a jitter buffer where the payload of the received SAToP packets is stored prior to play-out to the local TDM attachment circuit. The size of this buffer SHOULD be locally configurable to allow accommodation to the PSN-specific packet delay variation.

绑定CE的SAToP-IWF应包括抖动缓冲器,其中在播放到本地TDM连接电路之前存储接收到的SAToP分组的有效载荷。该缓冲区的大小应该是本地可配置的,以允许适应特定于PSN的数据包延迟变化。

The CE-bound SAToP IWF SHOULD use the sequence number in the control word for detection of lost and misordered packets. If the RTP header is used, the RTP sequence numbers MAY be used for the same purposes.

绑定CE的SAToP IWF应使用控制字中的序列号来检测丢失和错误排序的数据包。如果使用RTP报头,则RTP序列号可用于相同目的。

Note: With SAToP, a valid sequence number can be always found in bits 16 - 31 of the first 32-bit word immediately following the PW demultiplexing header regardless of the specific PSN type, multiplexing method, usage or non-usage of the RTP header, etc. This approach simplifies implementations supporting multiple encapsulation types as well as implementation of multi-segment (MS) PWs using different encapsulation types in different segments.

注:使用SAToP时,无论特定PSN类型、复用方法、RTP报头的使用与否,总是可以在PW解复用报头后面的第一个32位字的位16-31中找到有效的序列号,此方法简化了支持多种封装类型的实现,以及在不同段中使用不同封装类型的多段(MS)PWs的实现。

The CE-bound SAToP IWF MAY reorder misordered packets. Misordered packets that cannot be reordered MUST be discarded and treated as lost.

受限于CE的SAToP-IWF可以对错误排序的分组进行重新排序。不能重新排序的错误数据包必须丢弃并视为丢失。

The payload of the received SAToP packets marked with the L bit set SHOULD be replaced by the equivalent amount of the "all ones" pattern even if it has not been omitted.

用L位集标记的接收到的SAToP数据包的有效载荷应替换为等量的“所有1”模式,即使它没有被省略。

The payload of each lost SAToP packet MUST be replaced with the equivalent amount of the replacement data. The contents of the replacement data are implementation-specific and MAY be locally configurable. By default, all SAToP implementations MUST support generation of the "all ones" pattern as the replacement data. Before a PW has been set up and after a PW has been torn down, the IWF MUST play out the "all ones" pattern to its TDM attachment circuit.

必须用等量的替换数据替换每个丢失的SAToP数据包的有效载荷。替换数据的内容是特定于实现的,可以在本地配置。默认情况下,所有SAToP实现都必须支持生成“all ONE”模式作为替换数据。在设置PW之前和拆除PW之后,IWF必须向其TDM连接电路播放“所有一个”模式。

Once the PW has been set up, the CE-bound IWF begins to receive SAToP packets and to store their payload in the jitter buffer but continues to play out the "all ones" pattern to its TDM attachment circuit. This intermediate state persists until a preconfigured amount of TDM

一旦PW被设置,绑定CE的IWF开始接收SAToP数据包并将其有效载荷存储在抖动缓冲器中,但继续向其TDM连接电路播放“所有一个”模式。此中间状态持续存在,直到达到预先配置的TDM量

data (usually half of the jitter buffer) has been received in consecutive SAToP packets or until a preconfigured intermediate state timer (started when the PW setup is completed) expires.

数据(通常是抖动缓冲区的一半)已在连续的SAToP数据包中接收,或直到预配置的中间状态计时器(在PW设置完成时启动)过期。

Once the preconfigured amount of the TDM data has been received, the CE-bound SAToP IWF enters its normal operation state where it continues to receive SAToP packets and to store their payload in the jitter buffer while playing out the contents of the jitter buffer in accordance with the required clock. In this state, the CE-bound IWF performs clock recovery, MAY monitor PW defects, and MAY collect PW performance monitoring data.

一旦接收到预先配置的TDM数据量,绑定CE的SAToP IWF进入其正常操作状态,其中它继续接收SAToP分组并将其有效载荷存储在抖动缓冲器中,同时根据所需时钟播放抖动缓冲器的内容。在这种状态下,受CE约束的IWF执行时钟恢复,可以监视PW缺陷,并且可以收集PW性能监视数据。

If the CE-bound SAToP IWF detects loss of a preconfigured number of consecutive packets or if the intermediate state timer expires before the required amount of TDM data has been received, it enters its packet loss state. While in this state, the local PSN-bound SAToP IWF SHOULD mark every packet it transmits with the R bit set. The CE-bound SAToP IWF leaves this state and transitions to the normal one once a preconfigured number of consecutive valid SAToP packets have been received. (Successfully reordered packets contribute to the count of consecutive packets.)

如果绑定CE的SAToP IWF检测到预配置数量的连续数据包丢失,或者如果中间状态计时器在接收到所需数量的TDM数据之前过期,则其进入数据包丢失状态。在这种状态下,本地PSN绑定的SAToP IWF应标记其使用R位集传输的每个数据包。一旦接收到预配置数量的连续有效SAToP数据包,绑定CE的SAToP IWF将离开此状态并转换为正常状态。(成功重新排序的数据包有助于连续数据包的计数。)

The CE-bound SAToP IWF MUST provide an indication of TDM data validity to the CE. This can be done by transporting or by generating the native AIS indication. As mentioned above, T3 AIS cannot be detected or generated by structure-agnostic means, and hence a structure-aware NSP MUST be used when generating a valid AIS pattern.

绑定CE的SAToP IWF必须向CE提供TDM数据有效性的指示。这可以通过传输或生成本机AIS指示来实现。如上所述,T3 AIS无法通过结构不可知的方式检测或生成,因此在生成有效AIS模式时必须使用结构感知NSP。

6.3. SAToP Defects
6.3. SAToP缺陷

In addition to the packet loss state of the CE-bound SAToP IWF defined above, it MAY detect the following defects:

除了上面定义的CE绑定SAToP IWF的丢包状态外,它还可以检测以下缺陷:

o Stray packets o Malformed packets o Excessive packet loss rate o Buffer overrun o Remote packet loss

o 杂散数据包o格式错误数据包o过度数据包丢失率o缓冲区溢出o远程数据包丢失

Corresponding to each defect is a defect state of the IWF, a detection criterion that triggers transition from the normal operation state to the appropriate defect state, and an alarm that MAY be reported to the management system and thereafter cleared. Alarms are only reported when the defect state persists for a preconfigured amount of time (typically 2.5 seconds) and MUST be

与每个缺陷相对应的是IWF的缺陷状态、触发从正常运行状态过渡到适当缺陷状态的检测标准,以及可向管理系统报告并随后清除的警报。只有当缺陷状态持续一段预先配置的时间(通常为2.5秒)时,才会报告报警,并且必须

cleared after the corresponding defect is undetected for a second preconfigured amount of time (typically 10 seconds). The trigger and release times for the various alarms may be independent.

在第二次预配置时间(通常为10秒)内未检测到相应缺陷后清除。各种警报的触发和释放时间可能是独立的。

Stray packets MAY be detected by the PSN and PW demultiplexing layers. When RTP is used, the SSRC field in the RTP header MAY be used for this purpose as well. Stray packets MUST be discarded by the CE-bound IWF, and their detection MUST NOT affect mechanisms for detection of packet loss.

PSN和PW解复用层可检测到杂散分组。使用RTP时,RTP头中的SSRC字段也可用于此目的。受CE约束的IWF必须丢弃杂散数据包,其检测不得影响数据包丢失检测机制。

Malformed packets are detected by mismatch between the expected packet size (taking the value of the L bit into account) and the actual packet size inferred from the PSN and PW demultiplexing layers. When RTP is used, lack of correspondence between the PT value and that allocated for this direction of the PW MAY also be used for this purpose. Malformed in-order packets MUST be discarded by the CE-bound IWF and replacement data generated as with lost packets.

通过预期数据包大小(考虑L位的值)与从PSN和PW解复用层推断的实际数据包大小之间的不匹配来检测格式错误的数据包。当使用RTP时,PT值和分配给PW方向的PT值之间缺乏对应关系也可用于此目的。绑定CE的IWF必须丢弃格式不正确的顺序数据包,并替换与丢失数据包一样生成的数据。

Excessive packet loss rate is detected by computing the average packet loss rate over a configurable amount of times and comparing it with a preconfigured threshold.

通过计算可配置时间内的平均丢包率并将其与预配置阈值进行比较,可以检测到过度丢包率。

Buffer overrun is detected in the normal operation state when the jitter buffer of the CE-bound IWF cannot accommodate newly arrived SAToP packets.

当绑定CE的IWF的抖动缓冲区不能容纳新到达的SAToP数据包时,在正常操作状态下检测到缓冲区溢出。

Remote packet loss is indicated by reception of packets with their R bit set.

远程数据包丢失通过接收设置了R位的数据包来表示。

6.4. SAToP PW Performance Monitoring
6.4. SAToP PW性能监控

Performance monitoring (PM) parameters are routinely collected for TDM services and provide an important maintenance mechanism in TDM networks. The ability to collect compatible PM parameters for SAToP PWs enhances their maintenance capabilities.

性能监控(PM)参数是为TDM服务定期收集的,并在TDM网络中提供重要的维护机制。为SAToP PWs收集兼容PM参数的能力增强了其维护能力。

Collection of the SAToP PW performance monitoring parameters is OPTIONAL and, if implemented, is only performed after the CE-bound IWF has exited its intermediate state.

SAToP PW性能监控参数的收集是可选的,如果实现,则仅在绑定CE的IWF退出其中间状态后执行。

SAToP defines error events, errored blocks, and defects as follows:

SAToP对错误事件、错误块和缺陷的定义如下:

o A SAToP error event is defined as insertion of a single replacement packet into the jitter buffer (replacement of payload of SAToP packets with the L bit set is not considered insertion of a replacement packet).

o SAToP错误事件定义为将单个替换数据包插入抖动缓冲器(用L位集替换SAToP数据包的有效载荷不视为插入替换数据包)。

o A SAToP errored data block is defined as a block of data played out to the TDM attachment circuit and of a size defined in accordance with the [G.826] rules for the corresponding TDM service that has experienced at least one SAToP error event.

o SAToP错误数据块定义为向TDM连接电路播放的数据块,其大小根据[G.826]规则定义,适用于经历至少一次SAToP错误事件的相应TDM服务。

o A SAToP defect is defined as the packet loss state of the CE-bound SAToP IWF.

o SAToP缺陷定义为绑定CE的SAToP IWF的丢包状态。

The SAToP PW PM parameters (Errored, Severely Errored, and Unavailable Seconds) are derived from these definitions in accordance with [G.826].

SAToP PW PM参数(错误、严重错误和不可用秒)根据[G.826]从这些定义中推导而来。

7. Quality of Service (QoS) Issues
7. 服务质量(QoS)问题

SAToP SHOULD employ existing QoS capabilities of the underlying PSN.

SAToP应利用基础PSN的现有QoS能力。

If the PSN providing connectivity between PE devices is Diffserv-enabled and provides a PDB [RFC3086] that guarantees low jitter and low loss, the SAToP PW SHOULD use this PDB in compliance with the admission and allocation rules the PSN has put in place for that PDB (e.g., marking packets as directed by the PSN).

如果在PE设备之间提供连接的PSN启用了Diffserv,并提供了保证低抖动和低损耗的PDB[RFC3086],则SAToP PW应按照PSN为该PDB制定的准入和分配规则使用该PDB(例如,按照PSN的指示标记数据包)。

If the PSN is Intserv-enabled, then GS (Guaranteed Service) [RFC2212] with the appropriate bandwidth reservation SHOULD be used in order to provide a bandwidth guarantee equal or greater than that of the aggregate TDM traffic.

如果PSN已启用Intserv,则应使用具有适当带宽预留的GS(保证服务)[RFC2212],以提供等于或大于总TDM流量的带宽保证。

8. Congestion Control
8. 拥塞控制

As explained in [RFC3985], the PSN carrying the PW may be subject to congestion. SAToP PWs represent inelastic constant bit-rate (CBR) flows and cannot respond to congestion in a TCP-friendly manner prescribed by [RFC2914], although the percentage of total bandwidth they consume remains constant.

如[RFC3985]所述,承载PW的PSN可能会出现拥塞。SAToP PW代表非弹性恒定比特率(CBR)流,不能以[RFC2914]规定的TCP友好方式响应拥塞,尽管它们消耗的总带宽百分比保持不变。

Unless appropriate precautions are taken, undiminished demand of bandwidth by SAToP PWs can contribute to network congestion that may impact network control protocols.

除非采取适当的预防措施,否则SAToP PWs对带宽的需求不减可能导致网络拥塞,从而影响网络控制协议。

Whenever possible, SAToP PWs SHOULD be carried across traffic-engineered PSNs that provide either bandwidth reservation and admission control or forwarding prioritization and boundary traffic conditioning mechanisms. IntServ-enabled domains supporting Guaranteed Service (GS) [RFC2212] and DiffServ-enabled domains [RFC2475] supporting Expedited Forwarding (EF) [RFC3246] provide examples of such PSNs. Such mechanisms will negate, to some degree, the effect of the SAToP PWs on the neighboring streams. In order to facilitate boundary traffic conditioning of SAToP traffic over IP

只要有可能,SAToP PW应跨提供带宽预留和准入控制或转发优先级和边界流量调节机制的流量工程PSN进行。支持保证服务(GS)[RFC2212]的支持IntServ的域[RFC2475]和支持快速转发(EF)[RFC3246]的支持区分服务的域[RFC2475]提供了此类PSN的示例。这种机制将在某种程度上抵消SAToP PWs对相邻流的影响。为了促进边界流量,通过IP调节SAToP流量

PSNs, the SAToP IP packets SHOULD NOT use the DiffServ Code Point (DSCP) value reserved for the Default Per-Hop Behavior (PHB) [RFC2474].

对于PSN,SAToP IP数据包不应使用为默认每跳行为(PHB)保留的区分服务码点(DSCP)值[RFC2474]。

If SAToP PWs run over a PSN providing best-effort service, they SHOULD monitor packet loss in order to detect "severe congestion". If such a condition is detected, a SAToP PW SHOULD shut down bi-directionally for some period of time as described in Section 6.5 of [RFC3985].

如果SAToP PW在提供尽力而为服务的PSN上运行,它们应该监控数据包丢失,以便检测“严重拥塞”。如果检测到这种情况,SAToP PW应双向关闭一段时间,如[RFC3985]第6.5节所述。

Note that:

请注意:

1. The SAToP IWF can inherently provide packet loss measurement since the expected rate of arrival of SAToP packets is fixed and known

1. 由于SAToP数据包的预期到达率是固定且已知的,因此SAToP IWF固有地可以提供数据包丢失测量

2. The results of the SAToP packet loss measurement may not be a reliable indication of presence or absence of severe congestion if the PSN provides enhanced delivery. For example:

2. 如果PSN提供增强的传送,则SAToP分组丢失测量的结果可能不是存在或不存在严重拥塞的可靠指示。例如:

a) If SAToP traffic takes precedence over non-SAToP traffic, severe congestion can develop without significant SAToP packet loss.

a) 如果SAToP流量优先于非SAToP流量,则可能会出现严重拥塞,而不会造成严重的SAToP数据包丢失。

b) If non-SAToP traffic takes precedence over SAToP traffic, SAToP may experience substantial packet loss due to a short-term burst of high-priority traffic.

b) 如果非SAToP流量优先于SAToP流量,则由于高优先级流量的短期突发,SAToP可能会经历大量数据包丢失。

3. The TDM services emulated by the SAToP PWs have high availability objectives (see [G.826]) that MUST be taken into account when deciding on temporary shutdown of SAToP PWs.

3. SAToP PWs模拟的TDM服务具有高可用性目标(见[G.826]),在决定临时关闭SAToP PWs时必须将其考虑在内。

This specification does not define the exact criteria for detecting "severe congestion" using the SAToP packet loss rate or the specific methods for bi-directional shutdown the SAToP PWs (when such severe congestion has been detected) and their subsequent re-start after a suitable delay. This is left for further study. However, the following considerations may be used as guidelines for implementing the SAToP severe congestion shutdown mechanism:

本规范未定义使用SAToP丢包率检测“严重拥塞”的确切标准,也未定义双向关闭SAToP PWs(当检测到严重拥塞时)及其在适当延迟后重新启动的具体方法。这有待进一步研究。但是,以下注意事项可用作实施SAToP严重拥塞停机机制的指南:

1. SAToP Performance Monitoring techniques (see Section 6.4) provide entry and exit criteria for the SAToP PW "Unavailable" state that make it closely correlated with the "Unavailable" state of the emulated TDM circuit as specified in [G.826]. Using the same criteria for "severe congestion" detection may decrease the risk of shutting down the SAToP PW while the emulated TDM circuit is still considered available by the CE.

1. SAToP性能监测技术(见第6.4节)为SAToP PW“不可用”状态提供了进入和退出标准,使其与[G.826]中规定的模拟TDM电路的“不可用”状态密切相关。在CE认为仿真TDM电路仍然可用时,使用相同的“严重拥塞”检测标准可降低关闭SAToP PW的风险。

2. If the SAToP PW has been set up using either PWE3 control protocol [RFC4447] or L2TPv3 [RFC3931], the regular PW teardown procedures of these protocols SHOULD be used.

2. 如果已使用PWE3控制协议[RFC4447]或L2TPv3[RFC3931]设置SAToP PW,则应使用这些协议的常规PW拆卸程序。

3. If one of the SAToP PW end points stops transmission of packets for a sufficiently long period, its peer (observing 100% packet loss) will necessarily detect "severe congestion" and also stop transmission, thus achieving bi-directional PW shutdown.

3. 如果其中一个SAToP PW端点在足够长的时间内停止数据包的传输,则其对等方(观察到100%的数据包丢失)将必然检测到“严重拥塞”并停止传输,从而实现双向PW关闭。

9. Security Considerations
9. 安全考虑

SAToP does not enhance or detract from the security performance of the underlying PSN; rather, it relies upon the PSN mechanisms for encryption, integrity, and authentication whenever required.

SAToP不会提高或降低基础PSN的安全性能;相反,它在需要时依赖PSN机制进行加密、完整性和身份验证。

SAToP PWs share susceptibility to a number of pseudowire-layer attacks and will use whatever mechanisms for confidentiality, integrity, and authentication are developed for general PWs. These methods are beyond the scope of this document.

SAToP PWs对许多伪线层攻击具有敏感性,并将使用为通用PWs开发的任何保密性、完整性和身份验证机制。这些方法超出了本文件的范围。

Although SAToP PWs MAY employ an RTP header when explicit transfer of timing information is required, SRTP (see [RFC3711]) mechanisms are NOT RECOMMENDED as a substitute for PW layer security.

尽管当需要显式传输定时信息时,SAToP PWs可采用RTP报头,但不建议使用SRTP(参见[RFC3711])机制替代PW层安全性。

Misconnection detection capabilities of SAToP increase its resilience to misconfiguration and some types of denial-of-service (DoS) attacks.

SAToP的错误连接检测功能增强了其对错误配置和某些类型的拒绝服务(DoS)攻击的恢复能力。

Random initialization of sequence numbers, in both the control word and the optional RTP header, makes known-plaintext attacks on encrypted SAToP PWs more difficult. Encryption of PWs is beyond the scope of this document.

控制字和可选RTP报头中序列号的随机初始化使得加密SAToP PW上的已知明文攻击更加困难。PWs的加密超出了本文件的范围。

10. Applicability Statement
10. 适用性声明

SAToP is an encapsulation layer intended for carrying TDM circuits (E1/T1/E3/T3) over PSN in a structure-agnostic fashion.

SAToP是一种封装层,用于以结构无关的方式在PSN上承载TDM电路(E1/T1/E3/T3)。

SAToP fully complies with the principle of minimal intervention, thus minimizing overhead and computational power required for encapsulation.

SAToP完全符合最小干预原则,从而最大限度地减少封装所需的开销和计算能力。

SAToP provides sequencing and synchronization functions needed for emulation of TDM bit-streams, including detection of lost or misordered packets and appropriate compensation.

SAToP提供模拟TDM比特流所需的排序和同步功能,包括检测丢失或错误排序的数据包和适当的补偿。

TDM bit-streams carried over SAToP PWs may experience delays exceeding those typical of native TDM networks. These delays include the SAToP packetization delay, edge-to-edge delay of the underlying PSN, and the delay added by the jitter buffer. It is recommended to estimate both delay and delay variation prior to setup of a SAToP PW.

通过SAToP PWs传输的TDM比特流可能会经历超过本机TDM网络典型延迟的延迟。这些延迟包括SAToP分组延迟、底层PSN的边到边延迟以及抖动缓冲器增加的延迟。建议在设置SAToP PW之前估算延迟和延迟变化。

SAToP carries TDM streams over PSN in their entirety, including any TDM signaling contained within the data. Consequently, the emulated TDM services are sensitive to the PSN packet loss. Appropriate generation of replacement data can be used to prevent shutting down the CE TDM interface due to occasional packet loss. Other effects of packet loss on this interface (e.g., errored blocks) cannot be prevented.

SAToP在整个PSN上承载TDM流,包括数据中包含的任何TDM信令。因此,仿真TDM服务对PSN分组丢失非常敏感。可以使用适当的替换数据生成来防止由于偶尔的数据包丢失而关闭CE-TDM接口。数据包丢失对该接口的其他影响(如错误块)无法避免。

Note: Structure-aware TDM emulation (see [CESoPSN] or [TDMoIP]) completely hides effects of the PSN packet loss on the CE TDM interface (because framing and Cyclic Redundancy Checks (CRCs) are generated locally) and allows usage of application-specific packet loss concealment methods to minimize effects on the applications using the emulated TDM service.

注:结构感知TDM仿真(参见[CESoPSN]或[TDMoIP])完全隐藏了PSN分组丢失对CE TDM接口的影响(因为帧和循环冗余校验(CRC)是在本地生成的)并且允许使用特定于应用程序的分组丢失隐藏方法,以最小化对使用模拟TDM服务的应用程序的影响。

SAToP can be used in conjunction with various network synchronization scenarios (see [RFC4197]) and clock recovery techniques. The quality of the TDM clock recovered by the SAToP IWF may be implementation-specific. The quality may be improved by using RTP if a common clock is available at both ends of the SAToP PW.

SAToP可与各种网络同步方案(参见[RFC4197])和时钟恢复技术结合使用。由SAToP IWF恢复的TDM时钟的质量可以是特定于实现的。如果在SAToP PW的两端都有一个公共时钟,则可以通过使用RTP来提高质量。

SAToP provides for effective fault isolation by carrying the local attachment circuit failure indications.

SAToP通过携带本地连接电路故障指示,提供有效的故障隔离。

The option not to carry invalid TDM data enables PSN bandwidth conservation.

不携带无效TDM数据的选项可以节省PSN带宽。

SAToP allows collection of TDM-like faults and performance monitoring parameters and hence emulates 'classic' carrier services of TDM.

SAToP允许收集TDM类故障和性能监控参数,因此模拟TDM的“经典”载波服务。

SAToP provides for a carrier-independent ability to detect misconnections and malformed packets. This feature increases resilience of the emulated service to misconfiguration and DoS attacks.

SAToP提供了独立于运营商的能力来检测错误连接和格式错误的数据包。此功能增强了模拟服务对错误配置和DoS攻击的恢复能力。

Being a constant bit rate (CBR) service, SAToP cannot provide TCP-friendly behavior under network congestion.

作为一种恒定比特率(CBR)服务,SAToP无法在网络拥塞情况下提供TCP友好行为。

Faithfulness of a SAToP PW may be increased by exploiting QoS features of the underlying PSN.

可以通过利用底层PSN的QoS特性来提高SAToP PW的忠实性。

SAToP does not provide any mechanisms for protection against PSN outages, and hence its resilience to such outages is limited. However, lost-packet replacement and packet reordering mechanisms increase resilience of the emulated service to fast PSN rerouting events.

SAToP不提供任何防止PSN停机的机制,因此其对此类停机的恢复能力有限。然而,丢失的数据包替换和数据包重排序机制提高了模拟服务对快速PSN重路由事件的恢复能力。

11. IANA Considerations
11. IANA考虑

Allocation of PW Types for the corresponding SAToP PWs is defined in [RFC4446].

[RFC4446]中定义了相应SAToP PW的PW类型分配。

12. Acknowledgements
12. 致谢

We acknowledge the work of Gil Biran and Hugo Silberman who implemented TDM transport over IP in 1998.

我们感谢Gil Biran和Hugo Silberman在1998年通过IP实施TDM传输的工作。

We would like to thank Alik Shimelmits for many productive discussions and Ron Insler for his assistance in deploying TDM over PSN.

我们要感谢Alik Shimelmits进行了许多富有成效的讨论,并感谢Ron Insler在通过PSN部署TDM方面提供的帮助。

We express deep gratitude to Stephen Casner who has reviewed in detail one of the predecessors of this document and provided valuable feedback regarding various aspects of RTP usage, and to Kathleen Nichols who has provided the current text of the QoS section considering Diffserv-enabled PSN.

我们深切感谢斯蒂芬·卡斯纳(Stephen Casner),他详细回顾了本文档的一个前辈,并就RTP使用的各个方面提供了宝贵的反馈,同时感谢凯瑟琳·尼科尔斯(Kathleen Nichols)提供了QoS部分的最新文本,其中考虑了支持区分服务的PSN。

We thank William Bartholomay, Robert Biksner, Stewart Bryant, Rao Cherukuri, Ron Cohen, Alex Conta, Shahram Davari, Tom Johnson, Sim Narasimha, Yaron Raz, and Maximilian Riegel for their valuable feedback.

我们感谢威廉·巴塞洛梅、罗伯特·比克斯纳、斯图尔特·布莱恩特、拉奥·切鲁库里、罗恩·科恩、亚历克斯·孔塔、沙拉姆·达瓦里、汤姆·约翰逊、西姆·纳拉西姆哈、亚龙·拉兹和马克西米利安·里格尔的宝贵反馈。

13. Co-Authors
13. 合著者

The following are co-authors of this document:

以下是本文件的共同作者:

Motty Anavi RAD Data Communications Tim Frost Zarlink Semiconductors Eduard Metz TNO Telecom Prayson Pate Overture Networks Akiva Sadovski Israel Sasson Axerra Networks Ronen Shashoua RAD Data Communications

Motty Anavi RAD数据通信Tim Frost Zarlink半导体Eduard Metz TNO电信Prayson Pate序曲网络Akiva Sadovski以色列Sasson Axera网络Ronen Shashoua RAD数据通信

14. Normative References
14. 规范性引用文件

[G.702] ITU-T Recommendation G.702 (11/88) - Digital Hierarchy Bit Rates.

[G.702]ITU-T建议G.702(11/88)-数字体系比特率。

[G.703] ITU-T Recommendation G.703 (10/98) - Physical/Electrical Characteristics of Hierarchical Digital Interfaces.

[G.703]ITU-T建议G.703(10/98)——分层数字接口的物理/电气特性。

[G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s hierarchical levels.

[G.704]ITU-T建议G.704(10/98)-在154463120488448和44736kbit/s分层级别使用的同步帧结构。

[G.707] ITU-T Recommendation G.707 (03/96) - Network Node Interface for the Synchronous Digital Hierarchy (SDH).

[G.707]ITU-T建议G.707(03/96)——同步数字体系(SDH)的网络节点接口。

[G.775] ITU-T Recommendation G.775 (10/98) - Loss of Signal (LOS), Alarm Indication Signal (AIS) and Remote Defect Indication (RDI) Defect Detection and Clearance Criteria for PDH Signals.

[G.775]ITU-T建议G.775(10/98)-PDH信号的信号丢失(LOS)、报警指示信号(AIS)和远程缺陷指示(RDI)缺陷检测和清除标准。

[G.802] ITU-T Recommendation G.802 (11/88) - Interworking between Networks Based on Different Digital Hierarchies and Speech Encoding Laws.

[G.802]ITU-T建议G.802(11/88)-基于不同数字层次结构和语音编码规则的网络间互通。

[G.826] ITU-T Recommendation G.826 (02/99) - Error performance parameters and objectives for international, constant bit rate digital paths at or above the primary rate.

[G.826]ITU-T建议G.826(02/99)——基本速率或以上国际恒定比特率数字路径的错误性能参数和目标。

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC791]Postel,J.,“互联网协议”,标准5,RFC7911981年9月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.

[RFC2474]Nichols,K.,Blake,S.,Baker,F.,和D.Black,“IPv4和IPv6头中区分服务字段(DS字段)的定义”,RFC 2474,1998年12月。

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.

[RFC2475]Blake,S.,Black,D.,Carlson,M.,Davies,E.,Wang,Z.,和W.Weiss,“差异化服务架构”,RFC 24751998年12月。

[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.

[RFC2914]Floyd,S.,“拥塞控制原则”,BCP 41,RFC 2914,2000年9月。

[RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.

[RFC3086]Nichols,K.和B.Carpenter,“每域区分服务行为的定义及其规范规则”,RFC 3086,2001年4月。

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[RFC3550]Schulzrinne,H.,Casner,S.,Frederick,R.,和V.Jacobson,“RTP:实时应用的传输协议”,STD 64,RFC 35502003年7月。

[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.

[RFC3931]Lau,J.,Townsley,M.,和I.Goyret,“第二层隧道协议-版本3(L2TPv3)”,RFC 39312005年3月。

[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.

[RFC4385]Bryant,S.,Swallow,G.,Martini,L.,和D.McPherson,“用于MPLS PSN的伪线仿真边到边(PWE3)控制字”,RFC 43852006年2月。

[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

[RFC4446]Martini,L.,“伪线边到边仿真(PWE3)的IANA分配”,BCP 116,RFC 4446,2006年4月。

[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.

[RFC4447]Martini,L.,Rosen,E.,El Aawar,N.,Smith,T.,和G.Heron,“使用标签分发协议(LDP)的伪线设置和维护”,RFC 4447,2006年4月。

[RTP-TYPES] RTP PARAMETERS, <http://www.iana.org/assignments/rtp-parameters>.

[RTP-TYPES]RTP参数<http://www.iana.org/assignments/rtp-parameters>.

[T1.107] American National Standard for Telecommunications - Digital Hierarchy - Format Specifications, ANSI T1.107-1988.

[T1.107]美国国家电信标准-数字体系-格式规范,ANSI T1.107-1988。

15. Informative References
15. 资料性引用

[ATM-CES] ATM forum specification af-vtoa-0078 (CES 2.0) Circuit Emulation Service Interoperability Specification Ver. 2.0.

[ATM-CES]ATM论坛规范af-vtoa-0078(CES 2.0)电路仿真服务互操作性规范。2.0.

[CESoPSN] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)", Work in Progress, November 2005.

[CESoPSN]Vainstein,A.,Ed.,Sasson,I.,Metz,E.,Frost,T.,和P.Pate,“分组交换网络上的TDM电路仿真服务(CESoPSN)”,正在进行的工作,2005年11月。

[PWE3-MS] Martini, L., Metz, C., Nadeau, T., Duckett, M., and F. Balus, "Segmented Pseudo Wire", Work in Progress, March 2006.

[PWE3-MS]Martini,L.,Metz,C.,Nadeau,T.,Duckett,M.,和F.Balus,“分段伪线”,正在进行的工作,2006年3月。

[PWE3-FRAG] Malis, A. and M. Townsley, "PWE3 Fragmentation and Reassembly", Work in Progress, November 2005.

[PWE3-FRAG]Malis,A.和M.Townsley,“PWE3碎片化和重组”,正在进行的工作,2005年11月。

[PWE3-VCCV] Nadeau, T. and R. Aggarwal, "Pseudo Wire Virtual Circuit Connectivity", Work in Progress, August 2005.

[PWE3-VCCV]Nadeau,T.和R.Aggarwal,“伪线虚拟电路连接”,正在进行的工作,2005年8月。

[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.

[RFC2212]Shenker,S.,Partridge,C.和R.Guerin,“保证服务质量规范”,RFC 2212,1997年9月。

[RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.

[RFC3246]Davie,B.,Charny,A.,Bennet,J.C.,Benson,K.,Le Boudec,J.,Courtney,W.,Davari,S.,Firoiu,V.,和D.Stiliadis,“快速转发PHB(每跳行为)”,RFC 32462002年3月。

[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.

[RFC3551]Schulzrinne,H.和S.Casner,“具有最小控制的音频和视频会议的RTP配置文件”,STD 65,RFC 3551,2003年7月。

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

[RFC3711]Baugher,M.,McGrew,D.,Naslund,M.,Carrara,E.,和K.Norrman,“安全实时传输协议(SRTP)”,RFC 37112004年3月。

[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.

[RFC3916]Xiao,X.,McPherson,D.,和P.Pate,“伪线仿真边到边(PWE3)的要求”,RFC 39162004年9月。

[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.

[RFC3985]Bryant,S.和P.Pate,“伪线仿真边到边(PWE3)架构”,RFC 39852005年3月。

[RFC4197] Riegel, M., "Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks", RFC 4197, October 2005.

[RFC4197]Riegel,M.,“分组交换网络上时分多路复用(TDM)电路的边到边仿真要求”,RFC 4197,2005年10月。

[TDM-CONTROL] Vainshtein, A. and Y. Stein, "Control Protocol Extensions for Setup of TDM Pseudowires", Work in Progress, July 2005.

[TDM-CONTROL]Vainstein,A.和Y.Stein,“TDM伪线设置的控制协议扩展”,正在进行的工作,2005年7月。

[TDMoIP] Stein, Y., "TDMoIP", Work in Progress, February 2005.

[TDMoIP]Stein,Y.,“TDMoIP”,正在进行的工作,2005年2月。

Appendix A: Old Mode of SAToP Encapsulation over L2TPv3

附录A:L2TPv3上的旧SAToP封装模式

Previous versions of this specification defined a SAToP PW encapsulation over L2TPv3, which differs from that described in Section 4.3 and Figure 2b. In these versions, the RTP header, if used, precedes the SAToP control word.

本规范以前的版本定义了L2TPv3上的SAToP PW封装,这与第4.3节和图2b中所述的不同。在这些版本中,RTP头(如果使用)位于SAToP控制字之前。

Existing implementations of the old encapsulation mode MUST be distinguished from the encapsulations conforming to this specification via the SAToP PW setup.

旧封装模式的现有实现必须通过SAToP PW设置与符合本规范的封装进行区分。

Appendix B: Parameters That MUST Be Agreed upon during the PW Setup

附录B:PW设置期间必须商定的参数

The following parameters of the SAToP IWF MUST be agreed upon between the peer IWFs during the PW setup. Such an agreement can be reached via manual configuration or via one of the PW setup protocols:

在PW设置期间,对等IWF之间必须就SAToP IWF的以下参数达成一致。可通过手动配置或PW设置协议之一达成此类协议:

1. Type of the Attachment Circuit (AC)

1. 附件电路的类型(AC)

      As mentioned in Section 3, SAToP supports the following AC types:
         i)   E1  (2048 kbit/s)
         ii)  T1  (1544 kbit/s); this service is also known as DS1
         iii) E3 (34368 kbit/s)
         iv)  T3 (44736 kbit/s); this service is also known as DS3
        
      As mentioned in Section 3, SAToP supports the following AC types:
         i)   E1  (2048 kbit/s)
         ii)  T1  (1544 kbit/s); this service is also known as DS1
         iii) E3 (34368 kbit/s)
         iv)  T3 (44736 kbit/s); this service is also known as DS3
        

SAToP PWs cannot be established between ACs of different types.

无法在不同类型的ACs之间建立SAToP PWs。

2. Usage of octet-aligned mode for T1

2. 八进制对齐模式在T1中的使用

a) This OPTIONAL mode of emulating T1 bit-streams with SAToP PWs is described in Section 5.2.

a) 第5.2节描述了用SAToP PWs模拟T1比特流的可选模式。

b) Both sides MUST agree on using this mode for a SAToP PW to be operational.

b) 双方必须同意使用该模式,SAToP PW才能运行。

3. Payload size, i.e., the amount of valid TDM data in a SAToP packet

3. 有效负载大小,即SAToP数据包中的有效TDM数据量

a) As mentioned in Section 5.1: i) The same payload size MUST be used in both directions of the SAToP PW. ii) The payload size cannot be changed once the PW has been set up.

a) 如第5.1节所述:i)在SAToP PW的两个方向上必须使用相同的有效载荷尺寸。ii)一旦设置了PW,有效负载大小就不能改变。

b) In most cases, any mutually agreed upon value can be used. However, if octet-aligned T1 encapsulation mode is used, the payload size MUST be an integral multiple of 25, and it expresses the amount of valid TDM data including padding.

b) 在大多数情况下,可以使用双方商定的任何价值。但是,如果使用八位字节对齐的T1封装模式,则有效负载大小必须是25的整数倍,并且它表示包括填充在内的有效TDM数据量。

4. Usage of the RTP header in the encapsulation

4. 在封装中使用RTP头

a) Both sides MUST agree on using RTP header in the SAToP PW.

a) 双方必须同意在SAToP PW中使用RTP头。

b) In the case of a SAToP PW over L2TPv3 using the RTP header, both sides MUST agree on usage of the "old mode" described in Appendix A.

b) 如果使用RTP报头对L2TPv3进行SAToP PW,双方必须就附录a中所述的“旧模式”的使用达成一致。

5. RTP-dependent parameters. The following parameters MUST be agreed upon if usage of the RTP header for the SAToP PW has been agreed upon.

5. RTP相关参数。如果已就SAToP PW的RTP头的使用达成一致,则必须就以下参数达成一致。

a) Timestamping mode (absolute or differential); this mode MAY be different for the two directions of the PW, but the receiver and transmitter MUST agree on the timestamping mode for each direction of the PW

a) 时间戳模式(绝对或差分);对于PW的两个方向,该模式可能不同,但接收器和发射器必须就PW的每个方向的时间戳模式达成一致

b) Timestamping clock frequency: i) The timestamping frequency MUST be a integral multiple of 8 kHz. ii) The timestamping frequency MAY be different for the two directions of the PW, but the receiver and transmitter MUST agree on the timestamping mode for each direction of the PW.

b) 时间戳时钟频率:i)时间戳频率必须是8 kHz的整数倍。ii)PW两个方向的时间戳频率可能不同,但接收器和发射器必须就PW每个方向的时间戳模式达成一致。

c) RTP Payload Type (PT) value; any dynamically assigned value can be used with SAToP PWs.

c) RTP有效载荷类型(PT)值;任何动态分配的值都可以与SAToP PWs一起使用。

d) Synchronization Source (SSRC) value; the transmitter MUST agree to send the SSRC value requested by the receiver.

d) 同步源(SSRC)值;发射机必须同意发送接收机要求的SSRC值。

Editors' Addresses

编辑地址

Alexander ("Sasha") Vainshtein Axerra Networks 24 Raoul Wallenberg St., Tel Aviv 69719, Israel

Alexander(“Sasha”)Vainstein Axerra Networks 24 Raoul Wallenberg St.,特拉维夫69719,以色列

   EMail: sasha@axerra.com
        
   EMail: sasha@axerra.com
        

Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719, Israel

雅科夫(乔纳森)斯坦无线电数据通信公司以色列特拉维夫市拉乌尔瓦伦堡街24号C栋69719

   EMail: yaakov_s@rad.com
        
   EMail: yaakov_s@rad.com
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2006).

版权所有(C)互联网协会(2006年)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

本文件及其包含的信息是按“原样”提供的,贡献者、他/她所代表或赞助的组织(如有)、互联网协会和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.

Acknowledgement

确认

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFC编辑器功能的资金由IETF行政支持活动(IASA)提供。