⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc2615.txt

📁 著名的RFC文档,其中有一些文档是已经翻译成中文的的.
💻 TXT
📖 第 1 页 / 共 2 页
字号:
RFC 2615                  PPP over SONET/SDH                   June 19995.  Configuration Details   Other than the FCS length (see below), the standard LCP sync   configuration defaults apply to SONET/SDH links.   The following Configuration Options are RECOMMENDED for STS-3c-   SPE/VC-4:      Magic Number      No Address and Control Field Compression      No Protocol Field Compression   For operation at STS-12c-SPE/VC-4-4c and above, Address and Control   Field Compression and Protocol Field Compression are NOT RECOMMENDED.   The Magic Number option remains RECOMMENDED.   Regarding the FCS length, with one exception, the 32-bit FCS MUST be   used for all SONET/SDH rates. For STS-3c-SPE/VC-4 only, the 16-bit   FCS MAY be used, although the 32-bit FCS is RECOMMENDED.  The FCS   length is set by provisioning and is not negotiated.6.  Security Considerations   The major change from RFC 1619 is the addition of payload scrambling   when inserting the HDLC-like framed PPP packets into the SONET STS-   SPE/SDH Higher Order VC.  RFC 1619 was operationally found to permit   malicious users to generate packets with bit patterns that could   create SONET/SDH-layer low-transition-density synchronization   problems, emulation of the SDH set-reset scrambler pattern, and   replication of the STM-N frame alignment word.   The use of the x^43 + 1 self-synchronous scrambler was introduced to   alleviate these potential security problems.  Predicting the output   of the scrambler requires knowledge of the 43-bit state of the   transmitter as the scrambling of a known input is begun.  This   requires knowledge of both the initial 43-bit state of the scrambler   when it started and every byte of data scrambled by the device since   it was started.  The odds of guessing correctly are 1/2**43, with the   additional probability of 1/127 that a correct guess will leave the   frame properly aligned in the SONET/SDH payload, which results in a   probability of 9e-16 against being able to deliberately cause   SONET/SDH-layer problems.  This seems reasonably secure for this   application.   This scrambler is also used when transmitting ATM over SONET/SDH, and   public network carriers have considerable experience with its use.Malis & Simpson             Standards Track                     [Page 6]RFC 2615                  PPP over SONET/SDH                   June 1999   A known security issue is bandwidth reduction by intentional   transmission of characters or sequences requiring transparency   processing by including flag and/or escape characters in user data. A   user may cause up to a 100% increase in the bandwidth required for   transmitting his or her packets by filling the packet with flag   and/or escape characters.7.  Changes from RFC 1619   As mentioned in the previous section, the major change from RFC 1619   was the addition of payload scrambling when inserting the HDLC-like   framed PPP packets into the SONET STS-SPE/SDH Higher Order VC.  Other   changes were:   The terminology was updated to better match that used by ANSI and   ITU-T.   The specification's applicability is now specifically restricted to:       SONET                   SDH   ----------------------------------------   STS-3c-SPE                  VC-4   STS-12c-SPE                 VC-4-4c   STS-48c-SPE                 VC-4-16c   STS-192c-SPE                VC-4-64c   The Path Signal Label (C2) is set to 22 (16 hex) when using X^43 + 1   scrambling.   The 32-bit FCS is required except for operation with STS-3c-SPE/VC-4,   in which case the 16-bit FCS is allowed (but the 32-bit FCS is still   recommended).   The Security Considerations section was added.8.  Intellectual Property   The IETF takes no position regarding the validity or scope of any   intellectual property 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; neither does it represent that it   has made any effort to identify any such rights.  Information on the   IETF's procedures with respect to rights in standards-track and   standards-related documentation can be found in BCP-11.  Copies of   claims of rights made available for publication 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 suchMalis & Simpson             Standards Track                     [Page 7]RFC 2615                  PPP over SONET/SDH                   June 1999   proprietary rights by implementors or users of this specification can   be obtained from the IETF Secretariat.   The IETF invites any interested party to bring to its attention any   copyrights, patents or patent applications, or other proprietary   rights which may cover technology that may be required to practice   this standard.  Please address the information to the IETF Executive   Director.9.  Acknowledgments   The scrambler description was provided by J. Manchester, S. Davida,   B. Doshi, and J. Anderson of Lucent Technologies, R. Broberg of Cisco   Systems, and Peter Lothberg of Sprint Corporation.  The security   analysis was provided by Iain Verigin of PMC-Sierra and Larry McAdams   of Cisco Systems.  The authors would also like to thank the members   of the IETF's Point-to-Point Protocol Extensions Working Group for   their many suggestions and improvements to the text.10.  References   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD         51, RFC 1661, Daydreamer, July 1994.   [2]   Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC         1662, Daydreamer, July 1994.   [3]   American National Standards Institute, "Synchronous Optical         Network (SONET) - Basic Description including Multiplex         Structure, Rates and Formats," ANSI T1.105-1995.   [4]   American National Standards Institute, "Synchronous Optical         Network (SONET)--Payload Mappings," T1.105.02-1998.   [5]   ITU Recommendation G.707, "Network Node Interface For The         Synchronous Digital Hierarchy", 1996.   [6]   Bradner, S., "Key words for use in RFCs to indicate Requirement         Levels", BCP 14, RFC 2119, March 1997.Malis & Simpson             Standards Track                     [Page 8]RFC 2615                  PPP over SONET/SDH                   June 199911.  Authors' Addresses   Andrew G. Malis   Ascend Communications, Inc.   1 Robbins Road   Westford, MA 01810 USA   Phone: +1 978 952 7414   EMail: malis@ascend.com   William Allen Simpson   DayDreamer   Computer Systems Consulting Services   1384 Fontaine   Madison Heights, Michigan  48071   EMail: wsimpson@GreenDragon.comMalis & Simpson             Standards Track                     [Page 9]RFC 2615                  PPP over SONET/SDH                   June 199912.  Full Copyright Statement   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.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Malis & Simpson             Standards Track                    [Page 10]

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -