📄 rfc2126.txt
字号:
Pouffary & Young Standards Track [Page 19]RFC 2126 ISO Transport on top of TCP March 1997 Class 2 Options Profile +--------------------------------------------------------------------+ | Bits Service selected | | 1 4 6 7 | +--------------------------------------------------------------------+ | 0 x x x Non-use of Transport Expedited Data Service | | ---------------------------------------------------------| | Bits 4 6 7 are not applicable (*) | +--------------------------------------------------------------------+ | 1 x x x Use of Transport Expedited Data Service | | ---------------------------------------------------------| | 1 0 x x Use of Expedited Data Service with Forward Connection| | -----------------------------------------------------| | 1 0 1 0 Forward Connection with Expedited Data | | Acknowledgement | | 1 0 1 1 Forward Connection with Expedited Data | | Acknowledgement and use of Non-blocking | | Expedited Data (**) | | --------------------------------------------| | 1 0 0 0 Forward Connection with non-use of Expedited| | Data Acknowledgement (***) | | 1 0 0 1 Forward Connection with non-use of Expedited| | Data Acknowledgement and use of Non-blocking| | Expedited Data | | -----------------------------------------------------| | 1 1 x x Use of Expedited Data Service with Reverse Connection| | -----------------------------------------------------| | 1 1 1 0 Reverse Connection with Expedited Data | | Acknowledgement | | 1 1 1 1 Reverse Connection with Expedited Data | | Acknowledgement and use of Non-blocking | | Expedited Data (**) | | --------------------------------------------| | 1 1 0 0 Reverse Connection with non-use of Expedited| | Data Acknowledgement (***) | | 1 1 0 1 Reverse Connection with non-use of Expedited| | Data Acknowledgement and use of Non-blocking| | Expedited Data | +--------------------------------------------------------------------+ (*) Note the default (0000) provides an RFC1006-like service with Explicit Transport Disconnection. (**) Note in this case use of Expedited Data Acknowledgement with use of Non-blocking Expedited Data is a wasted effort (See section 6.5)Pouffary & Young Standards Track [Page 20]RFC 2126 ISO Transport on top of TCP March 1997 (***) Note in this case Normal and Expedited Data TPDU are not synchronised. (See section 6.6)6.7 Class 2 Expedited Data Acknowledgement The Protocol specified in this document does not define any relationship between use of "Expedited Data Acknowledgement" option and use of "Non-blocking Expedited Data" service. However please note that when using "Non-blocking Expedited Data" service it is a wasted effort to use "Expedited Data Acknowledgement", since ED TPDUs are duplicated and sent on both the Normal Data and Expedited Data TCP connections.6.8 Class 2 Normal Data and Expedited Data handling There exist two separate application requirements for using Expedited Data: 1- Synchronisation of the order of delivery between Normal and Expedited Data TPDU. 2- Independence of Normal and Expedited data channels. A busy Normal Data channel should not block an Expedited Data channel. The protocol described in this document can accommodate both requirements, separately or in combination. Synchronisation: If synchronised order of delivery between Normal and Expedited Data TPDU is required then use of either "Expedited Data Acknowledgement" TPDU or use of the "Non-blocking Expedited Data" service must be negotiated during connection establishment. If synchronised order of delivery between Normal and Expedited Data TPDU is not required then non-use of "Expedited Data Acknowledgement" need not be negotiated during connection establishment. Independence: If Independence of Normal and Expedited data channels is required then Forward or Reverse connection must be negotiated during connection establishment. Expedited data TPDU must be sent on the Expedited data channel.Pouffary & Young Standards Track [Page 21]RFC 2126 ISO Transport on top of TCP March 1997 If Independence of Normal and Expedited data channels is not required then Forward connection should be negotiated during connection establishment and the Expedited data channels should never be established. Expedited data TPDU is then sent inband on the Normal data channel. Finally please note that independence of Normal and Expedited data channels without synchronisation relaxes the Transport Service definition of Expedited data and is not consistent with ISO 8072.6.9 Class 2 Forward Connection procedure As defined in ISO 8073, when "Forward Connection" (Splitting and Recombining) procedure is used for Expedited Data transmission, ED TPDU must only be sent over an outgoing NS-provider TCP connection. As defined in ISO 8073, this document does not mandates use of the Splitting procedure for Expedited Data transmission. The Recombination procedure, which associates Data (normal and expedited) TPDUs arriving for a transport connection over two TCP connections must be handled. It is legal to send Expedited Data TPDU inband on the Normal Data TCP connection. Please note that the protocol specified in this document does not define when an Expedited Data TCP connection should be established. This is an implementation choice. When using "Non-blocking Expedited Data" service it is recommended to not delay establishing Expedited Data TCP connection.6.10 TPKT This document specifies the value of the TPKT reserved field. Implementation should not interpret and act upon any value in a reserved field. To avoid Interoperability issues with RFC1006, this field should be ignored on input.7. Rationale - Interoperability with RFC1006 We have chosen to maintain the same TPKT protocol version in ITOT as in RFC1006 (version 3). The reason for this decision is that the changes in this document do not conflict with RFC1006. If we were to change the protocol version we would prevent existing RFC1006 implementations which mandate version 3 from interoperating with the protocol defined in this document.Pouffary & Young Standards Track [Page 22]RFC 2126 ISO Transport on top of TCP March 1997 One consequence of this decision relates to class negotiation. The protocol described in this document introduces Class 2 over TCP, and it therefore introduces the need to be able to perform class negotiation between Class 2 and Class 0. While all Transport implementations should be able to handle Class negotiation, we recognise that some RFC1006 implementations cannot. Therefore Implementors should be aware that Class 2 Connect Request (with no Alternative class) could be accepted with a Class 0 Connect Confirm, at which point the Connect Confirm should be rejected as specified in ISO 8073.8. Security Considerations Security issues are not specifically addressed in this document. Operation of this protocol is no more and no less secure than operation of TCP and ISO 8073 protocols. The reader is directed there for further reading.Acknowledgements The authors are pleased to acknowledge the suggestions and comments of Harald T. Alvestrand, Jim Bound, John Day, Mike Dyer, Peter Furniss, Dan Harrington, Steve Kille, Keith G. Knightson, Keith Sklower, Matt Thomas, Robert Watson and many other members of the IETF TOSI mailing list. The support of Allison Mankin of the IESG was essential.References [ISO8072] ISO. "International Standard 8072. Information Processing Systems - Open Systems Interconnection: Transport Service Definition." [ISO8073] ISO. "International Standard 8073. Information Processing Systems - Open Systems Interconnection: Transport Protocol Specification." ISO 8073:1992 and 8073:1992/Amd.5:1995. [ISO8348] ISO. "International Standard 8348. Information Processing Systems - Open Systems Interconnection: Network Service Definition." [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.Pouffary & Young Standards Track [Page 23]RFC 2126 ISO Transport on top of TCP March 1997 [RFC896] Nagle, J., "Congestion Control in IP/TCP Inertnetworks", RFC 896, January 1984. [RFC1006] Rose, M., and D. Cass, "ISO Transport Services on Top of the TCP Version 3", STD 35, RFC 1006, May 1987. [RFC1277] Hardcastle-Kille, S., "Encoding Network Addresses to support operation over non-OSI lower layers", RFC 1277, November 1991. [RFC1278] Hardcastle-Kille, S., "String encoding of Presentation Address", RFC 1278, November 1991. A string encoding of Presentation Address update to RFC1278, Work in Progress. [RFC1859] Pouffary, Y., "ISO Transport Class 2 Non-use of Explicit Flow Control over TCP - RFC1006 extension", RFC 1859, October 1995. [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995. Hinden,, R., and S. Deeing, "IP Version 6 Addressing Architecture", RFC 1884, December 1995. Bound, J., Carpenter, B., Harrington, D., Houldsworth, J., and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.Pouffary & Young Standards Track [Page 24]RFC 2126 ISO Transport on top of TCP March 1997Authors' Addresses Yanick Pouffary End Systems Networking Digital Equipment Corporation Centre Technique (Europe) B.P. 027 950 Routes des colles 06901 Sophia antipolis, France Phone: +33 92-95-62-85 Fax: +33 92-95-62-35 EMail: pouffary@taec.enet.dec.com Alan Young ISODE Consortium The Dome The Square Richmond, UK Phone: +44 181 332 9091 Fax: +44 181 332 9019 EMail: A.Young@isode.comPouffary & Young Standards Track [Page 25]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -