ImageVerifierCode 换一换
格式:PDF , 页数:8 ,大小:435.75KB ,
资源ID:738731      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-738731.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(ETSI TS 102 144-2003 Services and Protocols for Advanced Networks (SPAN) MTP SCCP SSCOP and SIGTRAN (Transport of SS7 over IP) Stream Control Transmission Protocol (SCTP) (Endorsem.pdf)为本站会员(visitstep340)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

ETSI TS 102 144-2003 Services and Protocols for Advanced Networks (SPAN) MTP SCCP SSCOP and SIGTRAN (Transport of SS7 over IP) Stream Control Transmission Protocol (SCTP) (Endorsem.pdf

1、ETSI TS 102 144 1.1.1 (2003-05) Technical Specificafion Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP and SIGTRAN (Transport of SS7 over IP); Stream Control Transmission Protocol (SCTP) Endorsement of RFC 2960 and RFC 3309, modified 2 ETSI TS 102 144 VI .I .I (2003-05) Referenc

2、e DTSISPAN-I30265 Keywords MTP, SCCP, SCTP, SIGTRAN, SS7, ETSI 650 Route des Lucioles F-O6921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 O0 Fax: +33 4 93 65 47 16 Siret No 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-prfecture de Grasse (06) No 7803/88 Impo

3、rtant notice Individual copies of the present document can be downloaded from: http:lwmv.etsi .arq The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is t

4、he Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Inf

5、ormation on the current status of this and other ETSI documents is available at ha p:/pa rta I. etsi I a rgltbistat uslstatus .as p If you find errors in the present document, send your comment to: Cori vriaht Notifica tion No part may be reproduced except as authorized by written permission. The co

6、pyright and the foregoing restriction extend to reproduction in all media. O European Telecommunications Standards Institute 2003. All rights reserved. DECTTM, PLUGTESTSTMand UMTSTMare Trade Marks of ETSI registered for the benefit of its Members. TIPHONTM and the TIPHON logo are Trade Marks current

7、ly being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI 3 ETSI TS 102 144 VI .I .I (2003-05) Contents Intellectual Property Rights . .4 Foreword . 4 Endorsement notice . .4 Intr

8、oduction . .4 1 2 3 3.1 3.2 4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 5 Scope 5 References . .5 Definitions and abbreviations. . .5 Definitions . . 5 Abbreviations . 5 . . 6 . . 6 . . 6 . . 6 . . 6 . . 6 . . 7 . . 7 hunks . . 7 . . 7 . 7 SCTP protocol considerations . .6 Addressing method

9、s . . 6 Explicit Congestion Notification (ECN) . SCTP parameter considerations .7 History . .8 ETSI 4 ETSI TS 102 144 VI .I .I (2003-05) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these es

10、sential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR O00 314: “Intellectual Property Rights (7PRs); Essential, orpotentially Essential, IPRs notlJied to ETSI in respect ofETSI standards“, which is available from the ETSI Secretariat. Latest update

11、s are available on the ETSI Web server (5). All published ETSI deliverables shall include information which directs the reader to the above source of information. Foreword This Technical Specification (TS) has been produced by ETSI Technical Committee Services and Protocols for Advanced Networks (SP

12、AN). Endorsement notice The Elements of the Internet Engineering Task Force Request For Comments RFC 2960 i and RFC 3309 2 apply with the following modifications. I n t rod uct ion The present document records the changes to the Internet Engineering Task Force (IETF) RFC 2960 i and RFC 3309 2. These

13、 RFCs speciSl the Stream Control Transmission Protocol, which is the common transport protocol used by all SIGTRAN adaptation layers. ETSI 5 ETSI TS 102 144 VI .I .I (2003-05) 1 Scope The present document specifies the requirements for the Stream Control Transmission Protocol (SCTP) when used in con

14、junction with the SIGTRAN adaptation layers for the transport of Signalling Systems N0.7 (SS7) messages over the Internet Protocol (IP). The document endorses and constrains where relevant the SCTP defined in RFC 2960 i and RFC 3309 2. 2 Re fe re nces The following documents contain provisions which

15、, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication andor edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the l

16、atest version applies. Referenced documents which are not found to be publicly available in the expected location might be found at p. il IETF RFC 2960 (2000): “Stream Control Transmission Protocol“, R. Stewart., Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zha

17、ng, V. Paxson. IETF RFC 3309 (2002): “Stream Control Transmission Protocol (SCTP) Checksum Change“, J. Stone, R. Stewart, D. Otis. IETF RFC 3436 (2002): “Transport Layer Security over Stream Control Transmission Protocol“, A. Jungmaier, E. Rescorla, M. Txen. ETSI TS 102 141: “Services and Protocols

18、for Advanced Networks (SPAN); MTP/SCCP/SSCOP and SIGTRAN; M2UA Endorsement of RFC 333 1 (2002), modified“. ETSI TS 102 142: “Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP and SIGTRAN; M3UA Endorsement of RFC 3332 (2002), modified“. ETSI TS 102 143: “Services and Protocols for A

19、dvanced Networks (SPAN); MTP/SCCP/SSCOP and SIGTRAN; SUA Endorsement of SIGTRAN-SUA-14 (Dec. 2002), modified“. 21 31 41 51 61 3 3.1 Definitions and abbreviations De fi nit ions For the purposes of the present document, the following terms and definitions apply: example 1: text used to clarisl abstra

20、ct rules by applying them literally 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: ECN Explicit Congestion Notification IP Internet Protocol IPv4 Internet Protocol Version 4 IPv6 Internet Protocol Version 6 ETSI 6 ETSI TS 102 144 VI .I .I (2003-05) MTU

21、 Maximum Transmission Unit RFC Request Ffor Comment SCTP Stream Control Transmission Protocol 4 SCTP protocol considerat ions 4.1 SCTP checksum The CRC32C algorithm given in RFC 3309 2 shall be used instead of the Adler32 algorithm given in RFC 2960 i. 4.2 SCTP streams A minimum of two incoming and

22、two outgoing streams shall be supported. 4.3 Path MTU discovery Path MTU discovery is not required. This value shall be configurable. 4.4 Multihoming An SCTP end-point shall support two or more paths towards its peer. If association initialization to an IP destination address is unsuccessful, and al

23、ternative destination IP addresses are known, the sending node shall reattempt initialization by the sending the INIT chunk to the alternative IP address. 4.5 SCTP chunk size IP-packets containing SCTP packets shall not be larger than the Path MTU. An SCTP end-point shall use INIT and INIT-ACK chunk

24、s such that the resulting IP-packet is not larger than the Path MTU. This limits the number of paths used by SCTP associations. DATA chunks shall not exceed a size that would result in IP-packets larger than the path MTU. The size of HEARTBEAT chunks shall be equivalent to the size of DATA chunks. 4

25、.6 Addressing methods An SCTP end-point shall support IPv4 address parameters, may support IPv6 address parameters and shall not support the hostname address parameter. The sender of an INIT-chunk shall include the Supported Address parameter indicating the support of IPv4 and optionally IPv6. Suppo

26、rt for Hostname addresses shall not be indicated. If a hostname address parameter is included in an INIT or INIT-ACK chunk, the receiver shall reply with an ABORT chunk using the error cause Unresolvable Address. Singlehomed SCTP end-points shall not include an address parameter in INIT and INIT-ACK

27、 chunks. 4.7 Path supervision SCTP end-points shall support the heartbeat mechanism and the sending of HEARTBEAT chunks on idle paths shall be enabled by default. ETSI 7 SACK frequency I 1 ETSI TS 102 144 VI .I .I (2003-05) 5 2 1 4.8 User data size MTU size An SCTP end-point shall support the sendin

28、g and reception of user data with the maximum size defined by the upper layer. An SCTP end-point is not required to support the handling of larger user data sizes. If transport layer security is used the user data size which has to be supported is 18 437, see RFC 3436 3 for more information. 508 byt

29、es I 65535 bytes 1 500 bytes 1 byte 4.9 User data fragmentation If the supported user data size (see clause 4.8) would result in DATA chunks larger than allowed by clause 4.5, the sending SCTP end-point shall support fragmentation of user data. However, if this is not the case the support of user da

30、ta fragmentation on the sending side is not required. This is the case for TS 102 141 4 and TS 102 142 5 when not used in combination with RFC 3436 3. The reception of fragmented user data shall be supported. 4.1 O Unordered delivery of DATA chunks Support for unordered delivery at the sending SCTP-

31、end-point is not required. The receiving SCTP end-point shall support the reception of DATA chunks marked for unordered delivery. Please note, that TS 102 141 4, TS 102 142 5 and TS 102 143 6 do not make use of unordered delivery and RFC 3436 3 does not support it. 4.1 1 Bundling of DATA chunks An S

32、CTP end-point shall allow disabling of that DATA-chunk bundling which introduces additional delay. This does not affect bundling which introduces no additional delays. 4.12 Explicit Congestion Notification (ECN) The support of ECN is not required. 5 SCTP pa rameter considerations Table 1 gives a lis

33、t of relevant SCTP parameters which shall be configurable. The parameters shall be tuneable within the given interval and with the given granularity. The choice of the parameter values applicable for signalling transport is out of scope of the present document. The default values are given for infor

34、mation only. Table 1 : SCTP parameter values The SACKyeriod defies the maximum delay for generating an acknowledgement after receipt of a packet containing a DATA chunk. The SACK frequency defines how often a SACK is generated for every n packets received containing one or more DATA chunks within the SACKyeriod. ETSI 8 ETSI TS 102 144 VI .I .I (2003-05) vl.l.l History May 2003 Publication ETSI

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1