RFC874 日本語訳
0874 Critique of X.25. M.A. Padlipsky. September 1982. (Format: TXT=36386 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
---------
---------
< INC-PROJECT, MAP-CRITIQUE.NLS.10, >, 12-Aug-83 11:46 AMW ;;;;
< INC-PROJECT, MAP-CRITIQUE.NLS.10, >, 12-Aug-83 11:46 AMW ;;;;
RFC 874 September 1982 M82-50
RFC 874 September 1982 M82-50
A CRITIQUE OF X.25
A CRITIQUE OF X.25
M.A. PADLIPSKY THE MITRE CORPORATION Bedford, Massachusetts
M.A. PADLIPSKY THE MITRE CORPORATION Bedford, Massachusetts
ABSTRACT
ABSTRACT
The widely touted network interface protocol, "X.25", and its attendant conceptual framework, the International Standards Organization's Reference Model for Open System Interconnection (ISORM), are analyzed and found wanting. The paper is a companion piece to M82-48, and M82-51.
The widely touted network interface protocol, "X.25", and its attendant conceptual framework, the International Standards Organization's Reference Model for Open System Interconnection (ISORM), are analyzed and found wanting. The paper is a companion piece to M82-48, and M82-51.
i
i
A CRITIQUE OF X.25
A CRITIQUE OF X.25
M. A. Padlipsky
M. A. Padlipsky
Introduction
Introduction
According to some sources, the International Standards Organization's (ISO) "Open System Interconnection" (OSI) effort has adopted the International Consultative Committee on Telephony and Telegraphy (CCITT) developed X.25 protocol(s) as its Levels 1-3. ("Loose constructionists" of the ISORM would hold that X.25 is a mechanization of L1-L3 rather than the mechanization, and at least one British source holds that "we in the U.K. don't believe that ISO have adopted X.25.") In the U.S. Government arena, where the author spends much of his time, the Government Accounting Office (GAO) has suggested that the Department of Defense (DoD) ought to consider adopting "X.25 networks," apparently in preference to networks based on protocols developed by the DoD-sponsored intercomputer networking research community. That intercomputer networking research community in turn has, with a few recent exceptions, adhered to its commitment to the Oral Tradition and not taken up the cudgels against X.25 in the open literature, even though X.25 is an object of considerable scorn in personal communications.
According to some sources, the International Standards Organization's (ISO) "Open System Interconnection" (OSI) effort has adopted the International Consultative Committee on Telephony and Telegraphy (CCITT) developed X.25 protocol(s) as its Levels 1-3. ("Loose constructionists" of the ISORM would hold that X.25 is a mechanization of L1-L3 rather than the mechanization, and at least one British source holds that "we in the U.K. don't believe that ISO have adopted X.25.") In the U.S. Government arena, where the author spends much of his time, the Government Accounting Office (GAO) has suggested that the Department of Defense (DoD) ought to consider adopting "X.25 networks," apparently in preference to networks based on protocols developed by the DoD-sponsored intercomputer networking research community. That intercomputer networking research community in turn has, with a few recent exceptions, adhered to its commitment to the Oral Tradition and not taken up the cudgels against X.25 in the open literature, even though X.25 is an object of considerable scorn in personal communications.
Although the DoD Protocol Standards Technical Panel has begun to evolve a "Reference Model" different from ISO's for reasons which will be touched on below, there seems to be a need to address the deficiencies of X.25 on their own demerits as soon as possible. Without pretending to completeness*, this paper will attempt to do just that.
Although the DoD Protocol Standards Technical Panel has begun to evolve a "Reference Model" different from ISO's for reasons which will be touched on below, there seems to be a need to address the deficiencies of X.25 on their own demerits as soon as possible. Without pretending to completeness*, this paper will attempt to do just that.
The overall intent is to deal with X.25 in the abstract; because of who pays the bills, though, a necessary preliminary is to at least sketch the broad reasons why the DoD in particular should not
The overall intent is to deal with X.25 in the abstract; because of who pays the bills, though, a necessary preliminary is to at least sketch the broad reasons why the DoD in particular should not
________________ * Various versions of X.25 and ISO documentation were employed; one incompleteness of note, however, is that no attempt has been made to do proper bibliographic citation. Another incompleteness lies in the area of "tutoriality"; that is, appropriate prior knowledge is assumed on the part of the reader. (The author apologizes for the omissions but hasn't the time or the energy to be overly scholarly. Reference [3] might be of use to the reader who feels slighted.)
________________ * Various versions of X.25 and ISO documentation were employed; one incompleteness of note, however, is that no attempt has been made to do proper bibliographic citation. Another incompleteness lies in the area of "tutoriality"; that is, appropriate prior knowledge is assumed on the part of the reader. (The author apologizes for the omissions but hasn't the time or the energy to be overly scholarly. Reference [3] might be of use to the reader who feels slighted.)
1 RFC 874 September 1982
1 RFC 874 September 1982
employ intercomputer networks which base their protocol suites on the ISO Reference Model (ISORM) with X.25 as Levels 1-3. (Note that this is a different formulation from "use communications subnetworks which present an X.25 interface.") Very briefly, the DoD has concerns with "survivability," reliability, security, investment in prior art (i.e., its research community has a working protocol suite in place on many different operating systems), procurability (i.e., ISORM-related protocol suites do not as yet fully exist even on paper and the international standardization process is acknowledged even by its advocates to require several years to arrive at full suite specification, much less offer available interoperable implementation), and interoperability with a much wider range of systems than are ever likely to receive vendor-supplied implementations of ISORM protocol suites. Regardless of which particular concerns are considered to dominate, the DoD cannot be expected to await events in the ISO arena. (Particularly striking is the fact that DoD representatives are not even permitted under current doctrine to present their specific concerns in the area of security in the sort of unclassified environment the ISO arena constitutes.)
employ intercomputer networks which base their protocol suites on the ISO Reference Model (ISORM) with X.25 as Levels 1-3. (Note that this is a different formulation from "use communications subnetworks which present an X.25 interface.") Very briefly, the DoD has concerns with "survivability," reliability, security, investment in prior art (i.e., its research community has a working protocol suite in place on many different operating systems), procurability (i.e., ISORM-related protocol suites do not as yet fully exist even on paper and the international standardization process is acknowledged even by its advocates to require several years to arrive at full suite specification, much less offer available interoperable implementation), and interoperability with a much wider range of systems than are ever likely to receive vendor-supplied implementations of ISORM protocol suites. Regardless of which particular concerns are considered to dominate, the DoD cannot be expected to await events in the ISO arena. (Particularly striking is the fact that DoD representatives are not even permitted under current doctrine to present their specific concerns in the area of security in the sort of unclassified environment the ISO arena constitutes.)
Some zealous ISORM advocates have suggested that the DoD research community suffers from a "Not Invented Here" syndrome with respect to ISORM-related protocols, though, so even if the various reasons just cited were to prevail, there would still be an open issue at some level. At least one or two zealous members of the research community have asserted that the problem is not Not Invented Here, but Not Invented Right, so an assessment of the apparent keystone of the ISORM suite, X.25, from the perspective of whether it's "good art" ought to be appropriate. That's what we're up to here.
Some zealous ISORM advocates have suggested that the DoD research community suffers from a "Not Invented Here" syndrome with respect to ISORM-related protocols, though, so even if the various reasons just cited were to prevail, there would still be an open issue at some level. At least one or two zealous members of the research community have asserted that the problem is not Not Invented Here, but Not Invented Right, so an assessment of the apparent keystone of the ISORM suite, X.25, from the perspective of whether it's "good art" ought to be appropriate. That's what we're up to here.
2 RFC 874 September 1982
2 RFC 874 September 1982
Problems With the Conceptual Model*
Problems With the Conceptual Model*
There is confusion even amongst its advocates as to the real conceptual model of X.25-based ISO networking. Some draw their Reference Model as two "highrises," others draw "parking garages" beside each highrise. That is, some draw the seven ISORM layers in large rectangles (representing Hosts) next to one another, showing each layer in communication with its "peer" in the other Host/Open System; this implies an "end-to-end" view of X.25. Others draw smaller rectangles between the larger ones, with Levels 1-3 having peer relationships from the Host-OS ("Data Terminal Equipment") to the Comm Subnet Node ("Data Circuit Terminating Equipment"); this implies a "link-by-link" view of X.25. This ambiguity does not engender confidence in the architects, but perhaps the real problem is with the spectators. Yet it is indisputable that when internetting with X.75, the model becomes "hop-by-hop" (and it is likely it's meant to be link-by-link even on a single comm subnet).
There is confusion even amongst its advocates as to the real conceptual model of X.25-based ISO networking. Some draw their Reference Model as two "highrises," others draw "parking garages" beside each highrise. That is, some draw the seven ISORM layers in large rectangles (representing Hosts) next to one another, showing each layer in communication with its "peer" in the other Host/Open System; this implies an "end-to-end" view of X.25. Others draw smaller rectangles between the larger ones, with Levels 1-3 having peer relationships from the Host-OS ("Data Terminal Equipment") to the Comm Subnet Node ("Data Circuit Terminating Equipment"); this implies a "link-by-link" view of X.25. This ambiguity does not engender confidence in the architects, but perhaps the real problem is with the spectators. Yet it is indisputable that when internetting with X.75, the model becomes "hop-by-hop" (and it is likely it's meant to be link-by-link even on a single comm subnet).
A major problem with such a model is that the designers have chosen to construe it as requiring them to break the "virtual circuit" it is supposed to be supporting whenever there is difficulty with any one of the links. Thus, if internetting, and on some interpretations even on one's proximate net, rerouting of messages will not occur when needed, and all the upper levels of protocols will have to expend space-time resources on reconstituting their own connections with their counterparts. (Note that the success of the reconstitution under DCE failure appears to assume a certain flexibility in routing which is not guaranteed by the Model.) This can scarcely be deemed sound design practice for an intercomputer networking environment, although many have conjectured that it probably makes sense to telephonists.
A major problem with such a model is that the designers have chosen to construe it as requiring them to break the "virtual circuit" it is supposed to be supporting whenever there is difficulty with any one of the links. Thus, if internetting, and on some interpretations even on one's proximate net, rerouting of messages will not occur when needed, and all the upper levels of protocols will have to expend space-time resources on reconstituting their own connections with their counterparts. (Note that the success of the reconstitution under DCE failure appears to assume a certain flexibility in routing which is not guaranteed by the Model.) This can scarcely be deemed sound design practice for an intercomputer networking environment, although many have conjectured that it probably makes sense to telephonists.
________________ * Note that we are assuming an ISO-oriented model rather than a CCITT-oriented one (X.25/X.28/X.29) because the latter appears to offer only "remote access" functionality whereas the sort of intercomputer networking we are interested in is concerned with the full "resource-sharing" functionality the former is striving for. This might be somewhat unfair to X.25, in that it is taking the protocol(s) somewhat out of context; however, it is what ISO has done before us, and if what we're really accomplishing is a demonstration that ISO has erred in so doing, so be it. As a matter of fact, it can also be argued that X.25 is itself somewhat unfair--to its users, who are expecting real networking and getting only communication; cf. Padlipsky, M. A., "The Elements of Networking Style", M81-41, The MITRE Corporation, October 1981, for more on the extremely important topic of resource sharing vs. remote access.
________________ * Note that we are assuming an ISO-oriented model rather than a CCITT-oriented one (X.25/X.28/X.29) because the latter appears to offer only "remote access" functionality whereas the sort of intercomputer networking we are interested in is concerned with the full "resource-sharing" functionality the former is striving for. This might be somewhat unfair to X.25, in that it is taking the protocol(s) somewhat out of context; however, it is what ISO has done before us, and if what we're really accomplishing is a demonstration that ISO has erred in so doing, so be it. As a matter of fact, it can also be argued that X.25 is itself somewhat unfair--to its users, who are expecting real networking and getting only communication; cf. Padlipsky, M. A., "The Elements of Networking Style", M81-41, The MITRE Corporation, October 1981, for more on the extremely important topic of resource sharing vs. remote access.
3 RFC 874 September 1982
3 RFC 874 September 1982
Indeed, it appears the virtual circuit metaphor is in some sense being taken almost literally (with the emphasis on the "circuit" aspect), in that what should be an environment that confers the benefits of packet-switching is, at the X.25 level, reduced to one with the limitations of circuit-switching. On the other hand, the metaphor is not being taken literally enough in some other sense (with the emphasis on the "virtual" aspect), for many construe it to imply that the logical connection it represents is "only as strong as a wire." Whether the whole problem stems from the desire to "save bits" by not making addresses explicitly available on a per-transmission basis is conjectural, but if such be the case it is also unfortunate.
Indeed, it appears the virtual circuit metaphor is in some sense being taken almost literally (with the emphasis on the "circuit" aspect), in that what should be an environment that confers the benefits of packet-switching is, at the X.25 level, reduced to one with the limitations of circuit-switching. On the other hand, the metaphor is not being taken literally enough in some other sense (with the emphasis on the "virtual" aspect), for many construe it to imply that the logical connection it represents is "only as strong as a wire." Whether the whole problem stems from the desire to "save bits" by not making addresses explicitly available on a per-transmission basis is conjectural, but if such be the case it is also unfortunate.
(As an aside, it should be noted that there is some evidence that bit saving reaches fetish--if not pathological--proportions in X.25: For instance, there does not even appear to be a Packet Type field in data packets; rather--as best we can determine--for data packets the low order bit of the "P(R)" field, which overlaps/stands in the place of the Packet Type is always 0, whereas in "real" Packet Type fields it's always 1. [That may, by the way, not even be the way they do it--it's hard to tell ... or care.])
(As an aside, it should be noted that there is some evidence that bit saving reaches fetish--if not pathological--proportions in X.25: For instance, there does not even appear to be a Packet Type field in data packets; rather--as best we can determine--for data packets the low order bit of the "P(R)" field, which overlaps/stands in the place of the Packet Type is always 0, whereas in "real" Packet Type fields it's always 1. [That may, by the way, not even be the way they do it--it's hard to tell ... or care.])
There is also confusion even amongst its advocates as to what implications, if any, the protocol(s) has (have) for comm subnet node to comm subnet node (CSN) processing. Those who draw just two highrises seem to be implying that from their perspective the CSN (or "DCE") is invisible. This might make a certain amount of sense if they did not assert that each floor of a highrise has a "peer-relationship" with the corresponding floor of the other highrise--for to do so implies excessively long wires, well beyond the state of the wire-drawing art, when one notices that the first floor is the physical level. (It also appears to disallow the existence of concatenated comm subnets into an internet, or "catenet," unless the CSN's are all identically constituted. And those who hold that the ISORM dictates single protocols at each level will have a hard time making an HDLC interface into a Packet Radio Net, in all probability.)
There is also confusion even amongst its advocates as to what implications, if any, the protocol(s) has (have) for comm subnet node to comm subnet node (CSN) processing. Those who draw just two highrises seem to be implying that from their perspective the CSN (or "DCE") is invisible. This might make a certain amount of sense if they did not assert that each floor of a highrise has a "peer-relationship" with the corresponding floor of the other highrise--for to do so implies excessively long wires, well beyond the state of the wire-drawing art, when one notices that the first floor is the physical level. (It also appears to disallow the existence of concatenated comm subnets into an internet, or "catenet," unless the CSN's are all identically constituted. And those who hold that the ISORM dictates single protocols at each level will have a hard time making an HDLC interface into a Packet Radio Net, in all probability.)
Those who, on the other hand, "draw parking garages," seem to be dictating that the internal structure of the CSN also adhere to X.25 link and physical protocols. This implies that Packet Radio or satellite CSNs, for example, cannot "be X.25." Now that might be heartening news to the designers of such comm subnets, but it presumably wasn't intended by those who claim universality for X.25--or even for the ISO Reference Model.
Those who, on the other hand, "draw parking garages," seem to be dictating that the internal structure of the CSN also adhere to X.25 link and physical protocols. This implies that Packet Radio or satellite CSNs, for example, cannot "be X.25." Now that might be heartening news to the designers of such comm subnets, but it presumably wasn't intended by those who claim universality for X.25--or even for the ISO Reference Model.
4 RFC 874 September 1982
4 RFC 874 September 1982
Even granting that ambiguities in the conceptual model do not constitute prima facie grounds for rejecting the protocol(s), it is important to note that they almost assuredly will lead to vendor implementations based on differing interpretations that will not interoperate properly. And the unambiguous position that virtual circuits are broken whenever X.25 says so constitutes a flaw at least as grave as any of the ambiguities.
Even granting that ambiguities in the conceptual model do not constitute prima facie grounds for rejecting the protocol(s), it is important to note that they almost assuredly will lead to vendor implementations based on differing interpretations that will not interoperate properly. And the unambiguous position that virtual circuits are broken whenever X.25 says so constitutes a flaw at least as grave as any of the ambiguities.
Another, in our view extremely severe, shortcoming of the X.25 conceptual model is that it fails to address how programs that interpret its protocol(s) are to be integrated into their containing operating systems. (This goes beyond the shortcoming of the X.25 specifications in this area, for even the advocates of the ISORM--who, by hypothesis at least, have adopted X.25 for their Levels 1-3--are reticent on the topic in their literature.) Yet, if higher level protocols are to be based on X.25, there must be commonality of integration of X.25 modules with operating systems at least in certain aspects. The most important example that comes to mind is the necessity for "out-of-band signals" to take place. Yet if there is no awareness of that sort of use reflected in the X.25 protocol's specification, implementers need not insert X.25 modules into their operating systems in such a fashion as to let the higher level protocols function properly when/if an X.25 Interrupt packet arrives.
Another, in our view extremely severe, shortcoming of the X.25 conceptual model is that it fails to address how programs that interpret its protocol(s) are to be integrated into their containing operating systems. (This goes beyond the shortcoming of the X.25 specifications in this area, for even the advocates of the ISORM--who, by hypothesis at least, have adopted X.25 for their Levels 1-3--are reticent on the topic in their literature.) Yet, if higher level protocols are to be based on X.25, there must be commonality of integration of X.25 modules with operating systems at least in certain aspects. The most important example that comes to mind is the necessity for "out-of-band signals" to take place. Yet if there is no awareness of that sort of use reflected in the X.25 protocol's specification, implementers need not insert X.25 modules into their operating systems in such a fashion as to let the higher level protocols function properly when/if an X.25 Interrupt packet arrives.
Yet much of the problem with the conceptual model might turn out to stem from our own misunderstandings, or the misunderstandings of others. After all, it's not easy to infer a philosophy from a specification. (Nor, when it comes to recognizing data packets, is it easy even to infer the specification--but it might well say something somewhere on that particular point which we simply overlooked in our desire to get the spec back on the shelf rapidly.) What other aspects of X.25 appear to be "bad art"?
Yet much of the problem with the conceptual model might turn out to stem from our own misunderstandings, or the misunderstandings of others. After all, it's not easy to infer a philosophy from a specification. (Nor, when it comes to recognizing data packets, is it easy even to infer the specification--but it might well say something somewhere on that particular point which we simply overlooked in our desire to get the spec back on the shelf rapidly.) What other aspects of X.25 appear to be "bad art"?
"Personality Problems"
"Personality Problems"
When viewed from a functionality perspective, X.25 appears to be rather schizophrenic, in the sense that sometimes it presents a deceptively end-to-end "personality" (indeed, there are many who think it is usable as an integral Host-Host, or Transport, and network interface protocol, despite the fact that its specification itself--at least in the CCITT "Fascicle" version--points out several functional omissions where a higher-level protocol is expected--and we have even spoken to one or two people who say they actually do -- use it as an end-to-end protocol, regardless); sometimes it presents a comm subnet network interface personality (which all would agree it must); and sometimes (according to some observers) it presents a
機能性見解から見られると、Xです; 25 かなり精神分裂病患者であるように見えます; 時々、あてにならなく終わりから終わりへの「個性」を提示するという(本当に、それが不可欠のHost-ホスト、またはTransportとして使用可能であると思う多く、およびネットワーク・インターフェースプロトコルがあります、少なくともCCITT「分冊」バージョンの仕様自体が、上位レベル・プロトコルが予想されるところで(そして、私たちは彼らが実際にすると言う1か2人の人と話しさえしました)いくつかの機能的な省略が終わりから終わりへのプロトコルとしてそれを使用すると指摘するという事実にもかかわらず、不注意です)意味で。 時々、commサブネットネットワーク・インターフェース個性を提示する、(どれが、そうしなければならないのにすべて同意するだろうか、)、。 そして、時々(何人かの観察者によると)、それはaを提示します。
5 RFC 874 September 1982
5 RFC874 1982年9月
"Host-Front End Protocol" personality. Not to push the "bad art" methaphor too hard, but this sort of violation of "the Unities" is, if demonstrable, grounds for censure not only to literary critics but also to those who believe in Layering. Let's look at the evidence for the split-personality claim:
「ホスト前部Endプロトコル」個性。 この種類の「統一」の違反だけが、強く「悪い芸術」methaphorを押し過ぎるというわけではないために、あって、明白です、文芸批評家だけではなく、Layeringを信じる人に非難の根拠。 二重人格クレームに関する証拠を見ましょう:
X.25 is not (and should not be) an "end-to-end" protocol in the sense of a Transport or Host-to-Host protocol. Yet it has several end-to-end features. These add to the space-time expense of implementation (i.e., consume "core" and CPU cycles) and reflect badly on the skill of its designers if one believes in the design principles of Layering and Least Mechanism. (Examples of end-to-end mechanisms are cited below, as mechanisms superfluous to the network interface role.) The absence of a datagram mode which is both required and "proper" (e.g., not Flow Controlled, not Delivery Confirmed, not Non-delivery mechanized) may also be taken as evidence that the end-to-end view is very strong in X.25. That is, in ISO Reference Model (ISORM) terms, even though X.25 "is" L1-3, it has delusions of L4-ness; in ARPANET Reference Model (ARM) terms, even though X.25 could "be" L I, it has delusions of L II-ness.*
X.25はHostからTransportかホストへのプロトコルの意味で(そして、あるべきではありません)「終わりから終わり」プロトコルではありません。 しかし、それには、終わりから終わりへのいくつかの機能があります。 これらは、実現(すなわち、「コア」とCPUサイクルを費やす)の時空費用に加えて、人がLayeringとLeast Mechanismの設計原理を信じるなら、ひどくデザイナーの技能をよく考えます。 (終わりから終わりへのメカニズムに関する例はネットワーク・インターフェースの役割に余計なメカニズムとして以下で引用されます。) また、ともに必要で「適切な」データグラムモード(例えば、機械化されたNon-配送ではなく、Delivery Confirmedではなく、Flow Controlledでない)の欠如は終わりから端面図がX.25に非常に強いという証拠としてみなされるかもしれません。 L1-3、すなわち、ISO Reference Model(ISORM)用語で、それには、X.25が「あります」が、L4-岬の迷いがあります。 L I、アルパネットReference Model(ARM)用語で、X.25が「あることができました」が、それにはL II-岬*の迷いがあります。
X.25 is at least meant to specify an interface between a Host (or "DTE") and a comm subnet processor (or "DCE"), regardless of the ambiguity of the conceptual model about whether it constrains the CSNP "on the network side." (Aside: that ambiguity probably reflects even more badly on certain X.25 advocates than it does on the designers, for there is a strong sense in which "of course it can't" is the only appropriate answer to the question of whether it is meant to constrain generic CSN processors (CSNP's) in the general case. Note, though, that it might well be meant to constrain specific DCE's; that is, it started life as a protocol for PTT's--or Postal, Telephone, and Telegraph monopolies--and they are presumably entitled to constrain themselves all they want.) Yet the end-to-end features alluded to above are redundant to the interfacing role, and, as noted, extraneous features have space-time consequences. There are also several features which, though not end-to-end, seem superfluous to a "tight" interface protocol. Further, the reluctance of the designers to incorporate a proper "datagram" capability in the protocol (what they've got doesn't seem to be
X.25はHost(または、"DTE")とcommサブネットプロセッサ(または、"DCE")とのインタフェースを少なくとも指定することになっています、それが「ネットワーク側」のCSNPを抑制するかどうかに関する概念モデルのあいまいさにかかわらず。 (傍らに: そのあいまいさはたぶんデザイナーの上でそうするより確信しているX.25支持者でさらにひどく反射します、「そうすることができません」がそれが一般的な場合で一般的なCSNプロセッサ(CSNPのもの)を抑制することになっているかどうかに関する唯一の適切な質問の答である強い感覚があるので。 もっとも、たぶん特定のDCEのものを抑制することになっているだろうことに注意してください。 PTTのもの(Postal、Telephone、およびTelegraph独占)のためのプロトコルとして人生を始めました、そして、おそらく、それらは自分たちで彼らが欲しいすべてを抑制する権利を与えられます。) しかし、終わりから終わりへの上で暗示された機能は連結の役割に余分です、そして、注意されるように、時空結果が異質な特徴にあります。 また、終わりから終わりではありませんが、「きつい」インタフェースプロトコルに余計に見えるいくつかの特徴があります。 一層、デザイナーが適切な「データグラム」能力をプロトコルに取り入れるという不本意、(彼らが持っているものが見えない、
________________ * For more on the ARM, see Padlipsky, M. A., "A Perspective on the ARPANET Reference Model", M82-47, The MITRE Corporation, September 1982; also available in Proc. INFOCOM '83. (Some light may also be cast by the paper on the earlier-mentioned topic of Who Invented What.)
________________ * ARMの上の以上に関しては、Padlipsky、M.A.、「アルパネット規範モデルの上の見解」を見てください、M82-47、MITRE社、1982年9月。 また、Procでは、利用可能です。 INFOCOM83年。 (また、いくらかの光がWho Invented Whatの、より早く言及された話題に関する論文によって投げかけられるかもしれません。)
6 RFC 874 September 1982
6 RFC874 1982年9月
usable as a "pure"--i.e., uncontrolled at L3 but usable without superfluous overheard by L4--datagram, but instead entails delivery confirmation traffic like it or not; note that "seem" is used advisedly: as usual, it's not easy to interpret the Fascicle) suggests at least that they were confused about what higher-level protocols need from interfaces to CSNP's, and at worst that there is some merit to the suggestion that, to paraphrase Louis Pouzin, "the PTT's are just trying to drum up more business for themselves by forcing you to take more service than you need."
使用可能である、すなわち、L3で非制御の、しかし、余計であるのなしで使用可能な「純粋」をL4を立ち聞きしました--しかし、データグラム、代わりに配送確認が好むと好まざるとにかかわらず取引する限嗣相続 「見えること」が慎重に使用されることに注意してください: いつものように、解釈するのは簡単ではありません。Fascicle) 少なくとも、上位レベル・プロトコルがインタフェースからCSNPのものまで必要とするものに関して混乱して、最悪の場合は、ルイスPouzinについて言い換えるために、「あなたにより多くのサービスで取らせることによって、PTTのものは自分たちのためにあなたが必要とするよりさらに多くのビジネスをただ呼び集めようとしている」という提案への何らかの長所があることを提案します。
Examples of mechanisms superfluous to the interface role:
インタフェースの役割に余計なメカニズムに関する例:
1. The presence of a DTE-DTE Flow Control mechanism.
1. DTE-DTE Flow Controlメカニズムの存在。
2. The presence of an "interrupt procedure" involving the remote DTE.
2. リモートDTEにかかわる「中断手順」の存在。
3. The presence of "Call user data" as an end-to-end item (i.e., as "more" than IP's Protocol field).
3. 終わりから最終品目(すなわち、IPのプロトコル分野より「以上」としての)としての「呼び出し利用者データ」の存在。
4. The "D bit" (unless construed strictly as a "RFNM" from the remote DCE).
4. 「Dビット。」(リモートDCEから"RFNM"に厳密に理解されていない場合)
5. The "Q bit" (which we find nearly incomprehensible, but which is stated to have meaning of some sort to X.29--i.e., to at least violate Layering by having a higher-level protocol depend on a lower level machanism--and hence can't be strictly a network interface mechanism).
5. 「Qビット。」(私たちはほとんど不可解であることがわかりましたが、X.29(すなわち、上位レベル・プロトコルを持っていることによってLayeringに少なくとも違反するには、下側の平らなmachanismを当てにしてください、)にある種の意味を持つために述べられていて、したがって、厳密に、ネットワークがメカニズムを連結するということであることができません)
7 RFC 874 September 1982
7 RFC874 1982年9月
The final "personality problem" of X.25 is that some of its advocates claim it can and should be used as if it were a Host-Front End protocol.* Yet if such use were intended, surely its designers would have offered a means of differentiating between control information destined for the outboard implementation of the relevant protocols and data to be transmitted through X.25, but there is no evidence of such mechanisms in the protocol. "Borrowing" a Packet Type id for H-FP would be risky, as the spec is subject to arbitrary alteration. Using some fictitious DTE address to indicate the proximate DCE is also risky, for the same reason. Further, using "Call user data" to "talk to" the counterpart H-FP module allows only 15 octets (plus, presumably, the 6 spare bits in the 16th octet) for the conversation, whereas various TCP and IP options might require many more octets than that. Granted that with sufficient ingenuity--or even by the simple expedient of conveying the entire H-FP as data (i.e., using X.25 only to get channels to demultiplex on, and DTE-DCE flow control, with the "DCE" actually being an Outboard Processing Environment that gets its commands in the data fields of X.25 data packets)--X.25 might be used to "get at" outboard protocol interpreters, but its failure to address the issue explicitly again reflects badly on its designers' grasp of intercomputer networking issues. (Another possibility is that the whole H-FP notion stems from the use of X.25 as a Host-Host
X.25の最終的な「個性問題」は何人かの支持者が、それがHost-前部Endプロトコルであるかのように使用できて、使用されるべきであると主張するということです。*しかし、そのような使用が意図したなら、確実に、デザイナーは関連プロトコルとデータの船外の実現のために運命づけられた制御情報を区別するX.25を通して伝えられるべき手段を提供したでしょうが、プロトコルにはそのようなメカニズムに関する証拠が全くありません。 仕様は任意の変更を受けることがあるようにPacket TypeイドがH-FPのために「借用」であることは危険でしょう。 また、最も近いDCEを示すのに何らかの架空のDTEアドレスを使用するのも同じ理由で危険です。 「話す」「呼び出し利用者データ」を使用して、さらに、対応者H-FPモジュールが会話のために15の八重奏だけを許容しますが(おそらく、6は16番目の八重奏でビットを割きます)、様々なTCPとIPオプションはそれよりずっと多くの八重奏を必要とするかもしれません。 十分な巧みさ(または、データ(すなわち、実際にX.25データ・パケットのデータ・フィールドでコマンドを得る船外の処理環境である"DCE"と共に「反-マルチプレックス」のチャンネルを乗せるためには唯一のX.25、およびDTE-DCEフロー制御を使用する)として全体のH-FPを運ぶ簡単な方法でさえ)と共に、X.25が船外のプロトコルインタプリタに「達すること」に使用されるかもしれないのを与えました; しかし、そのが再び明らかに問題を記述しない場合、ひどくデザイナーのintercomputerネットワーク問題の把握をよく考えます。 (別の可能性は全体のH-FP概念がHost-ホストとしてX.25の使用によるということです。
________________ * That is, as a distributed processing mechanism which allows Host operating systems to be relieved of the burden of interpreting higher level protocols "inboard" of themselves by virtue of allowing Host processes to manipulate "outboard" interpreters of the protocols on their behalf. Note that the outboarding may be to a separate Front-End processor or to the CSNP itself. (The latter is likely to be found in microprocessor-based LAN "BIU's.") Note also that when dealing with "process-level" protocols (ARM L III; approximately ISORM L5-7), only part of the functionality is outboarded (e.g., there must be some Host-resident code to interface with the native File System for a File Transfer Protocol) and even when outboarding Host-Host protocols (ARM L II; approximately ISORM L4 plus some of 5) the association of logical connections (or "sockets") with processes must be performed inboard--which is why, by the way, it's annoying to find ISO L5 below ISO L6: because, that is, you'd like to outboard "Presentation" functionality but its protocol expects to interact with the "Session" protocol, the functionality of which can't be outboarded. (Although this approach, not the proper context for a full treatment of the H-FP approach, it is also of interest that the approach can effectively insulate the Host from changes in the protocol suite, which can be a major advantage in some environments.)
________________ * すなわち、分散処理として、Hostオペレーティングシステムは「内側に」より高い平らなプロトコルを解釈する負担を取り除かれるのを許容するHostを許容することによる自分たちのメカニズムが、それらに代わってプロトコルの「船外」のインタプリタを操るために処理されます。 別々のFront-エンドプロセッサ、または、CSNP自身に外到達があるかもしれないことに注意してください。 (後者はマイクロプロセッサベースのLAN「BIUのもの」で見つけられそうです。) また、「過程レベル」プロトコル(ARM L III; およそISORM L5-7)に対処するときにはそれに注意してください; 機能性の一部だけが外到達されます、そして、(例えば、File TransferプロトコルのためにネイティブのFile Systemに連結する何らかのHost-居住者コードがあるに違いありません)outboarding Host-ホストプロトコル(ARM L II; およそISORM L4と5のいくつか)でさえあるときに、内側に過程との論理的な関係(または、「ソケット」)の協会を実行しなければなりません(ところで、ISO L6の下のISO L5を見つけるのが煩わしい理由です): すなわち、あなたは機能性にもかかわらず、プロトコルがそれの機能性に外到達できない「セッション」プロトコルと対話すると予想する船外の「プレゼンテーション」がそうしたいです。 (H-FPアプローチの完全な処理のための適切な関係ではなく、このアプローチですが、関心ではも、事実上、アプローチはプロトコル群で変化からHostを隔離できます。)(プロトコル群はいくつかの環境で主要な利点であるかもしれません)。
8 RFC 874 September 1982
8 RFC874 1982年9月
protocol so that some might think of it in its Host aspect as "simply" a way of getting at the H-HP. This interpretation does give rise to the interesting observation that DCE's seem to need a protocol as strong as TCP amongst themselves, but doesn't strike the author as particularly convincing evidence for viewing X.25 as anything like a proper H-FP--if for no other reason than that a central premise of Outboard Processing is that the Host-side H-FP module must be compact relative to an inboard generic Network Control Program.)
或るものが「単に」というa道としてHost局面でH-HPに達するのについてそれを考えることができるように、議定書を作ってください。 この解釈は、DCEのものが自分たちの中でTCPと同じくらい強いプロトコルを必要とするように思えるおもしろい観測をもたらしますが、Outboard Processingの中央の前提がそれいいえ以外の理由で適切なH-FPのようにX.25を何かであるとみなすための、それであると証拠に特に納得させて、Host-サイドH-FPモジュールが機内の一般的なNetwork Control Programに比例してコンパクトであるに違いないので、作者の心を打ちません。)
X.25, then, is rather schizophrenic: It exceeds its brief as an interface protocol by pretending to be end-to-end (Host-Host) in some respects; it is by no means a full end-to-end protocol (its spec very properly insists on that point on several occasions); it's at once too full and too shallow to be a good interface; and it's poorly structured to be treated as if it were "just" an H-FP. (Some would phrase the foregoing as "It's extremely ill layered"; we wouldn't argue.)
次に、X.25はかなり精神分裂病患者です: ある点で終わりから終わり(ホスト兼ホスト)であるふりをすることによって、それはインタフェースプロトコルとして要約を超えています。 それは終わりから終わりへの決して完全なプロトコル(仕様は時折、非常に適切にそのポイントを強要する)ではありません。 すぐに、それは完全でであることができない浅過ぎる良いインタフェースです。 そして、扱われるのはまるでそれが「まさしく」H-FPであるかのように不十分に構造化されています。 (「非常にほとんど層にしていない」とき、或るものは上記を言葉で表すでしょう; 私たちは論争しないでしょう。)
A Note on "Gateways"*
「ゲートウェイ」*に関する注
Although it was at least implied in the discussion of conceptual model problems, one aspect of X.25/X.75 internetting is sufficiently significant to deserve a section of its own: Not only does the link-by-link approach taken by CCITT make it unlikely that alternate routing can take place, but it is also the case that ARPANET Internet Protocol (IP) based internetting not only permits alternate routing but also could alt-route over an "X.25 Subnet." That is, in IP's conceptual model, Gateways attach to two or more comm subnets "as if they (the Gateways) were Hosts." This means that they interpret the appropriate Host-comm subnet processor protocol of whatever comm subnets they're attached to, giving as the "proximate net address" of a given transmission either the ultimate (internet addressed) destination or the address of another Gateway "in the right direction." And an implementation of IP can certainly employ an implementation of ("DTE") X.25 to get a proximate net, so ... at least "in an emergency" X.25 interface presenting Public Data Networks can indeed carry IP traffic. (Note also that only the proximate net's header has to be readable by the nodal processor of/on the proximate net, so if some appropriate steps were taken to render the data portion of such transmissions unintelligible to the nodal processors, so much the better.)
それは概念モデル問題の議論で少なくとも含意されましたが、X.25/X.75 internettingの1つの局面がそれ自身のセクションに値することができるくらい重要です: また、リンクごとのCCITTによって取られたアプローチで迂回中継が行われることができるのがありそうもなくなるだけではなく、それは迂回中継を可能にしますが、アルパネットのインターネットのプロトコルの(IP)ベースのinternettingが「X.25サブネット」の上でaltまた発送できるだけではなかったケースです。 すなわち、IPの概念モデルでは、Gatewaysは「それら(Gateways)はHostsです」のように2以上commにサブネットを付けます。 これは、彼らがそれらが付けられているいかなるcommサブネットの適切なHost-commサブネットプロセッサプロトコルも解釈することを意味します、与えられたトランスミッションの「最も近いネットのアドレス」として「正しい方向に」究極(記述されたインターネット)の目的地か別のゲートウェイのアドレスのどちらかを与えて。 … そして、IPの実現が最も近いネットを得るのに確かに("DTE")X.25の実現を使うことができるので、本当に、公衆データネットワークを提示する少なくとも「非常時」X.25インタフェースはIP交通を運ぶことができます。 (また、いくつかならそのようなトランスミッションのデータ部をこぶのようなプロセッサに難解にするために適切な方法を取ったために最も近いネットのヘッダーだけが最も近いネットで/のこぶのようなプロセッサで読み込み可能でなければならないことに注意してください、尚更良いです。)
________________ * This section was added to address the ill-founded concerns of several ISORMites that "TCP/IP won't let you use Public Data Nets in emergencies."
________________ * このセクションは、「TCP/IPで、あなたは非常時にPublic Dataネットを使用できない」という数個のISORMitesの正当な理由のない関心を記述するために加えられました。
9 RFC 874 September 1982
9 RFC874 1982年9月
(Further evidence that X.75 internetting is undesirable is found in the fact that the U.S. National Bureau of Standards has, despite its nominal adoption of the ISORM, inserted IP at approximately L3.5 in its version of the Reference Model.)
(X.75 internettingが望ましくないというさらなる証拠はISORMの名目上の採用にもかかわらず、米国規格基準局がReference ModelのバージョンでIPをおよそL3.5に挿入したという事実で見つけられます。)
The Off-Blue Blanket
オフ青の毛布
Although touched on earlier, and not treatable at much length in the present context, the topic of security deserves separate mention. We are familiar with one reference in the open literature [1] which appears to make a rather striking point about the utility of X.25 in a secure network. Dr. Kent's point that the very field sizes of X.25 are not acceptable from the point of view of encryption devices would, if correct (and we are neither competent to assess that, nor in a position to even if we were), almost disqualify X.25 a priori for use in many arenas. Clearly, uncertified "DCE's" cannot be permitted to read classified (or even "private") data and so must be "encrypted around," after all.
より早くて、現在の文脈で多くの長さで処理できなく触れられますが、セキュリティの話題は別々の言及に値します。 私たちは安全なネットワークでX.25のユーティリティに関するかなり衝撃的なポイントを指摘するように見える開いている文学[1]における1つの参照箇所に詳しいです。 X.25のまさしくその分野サイズが暗号化装置の観点から許容できないというケント博士のポイントはそうするでしょう、正しいなら(私たち、私たちがいたとしてもどちらもそれを評価して、位置で有能でない、)、多くのアリーナでの使用のためにほとんど先験的にX.25の資格を取り上げてください。 明確に、分類されて(「個人的」さえ)のデータとそうが「コード化されなければならない」読書に非公認された「DCEのもの」を受入れることができません、結局。
It would probably be the case, if we understand Dr. Kent's point, that X.25 could be changed appropriately--if its specifiers were willing to go along. But this is only one problem out of a potentially large number of problems, and, returning briefly to our concern with the interplay of X.25 and the DoD, those persons in the DoD who know best what the problems are and/or could be are debarred from discussing them with the specifiers of X.25. Perhaps a sufficiently zealous ISORM advocate would be willing to suggest that Professor Kuo's publisher be subsidized to come out with a new edition whenever a problem arises so that if Dr. Kent happens to spot it advantage can continue to be taken of his ability to write for the open literature--but we certainly hope and trust that no ISORMite would be so tone-deaf as to fail to recognize the facetiousness of that suggestion.
それはたぶんケースでしょう、私たちが特許説明書の作成書が、進んでも構わないと思っているなら適切にX.25を変えることができるというケント博士の点を理解しているなら。 しかし、これは潜在的に多くの問題からの1つの問題であるにすぎなく、簡潔に交錯がある私たちの関心に戻って、DoDのX.25とDoD、それらの人々では、だれが問題が何であるかを特に知っている、そして/または、いるかもしれないかは、X.25の特許説明書の作成書とそれらについて議論しながら、妨げられます。 恐らく、十分熱心なISORM支持者は、ケント博士がたまたまそれに利点を見つけるならそれが、開いている文学のために書く彼の能力について取られ続けることができるように問題が起こりますが、確かに、私たちが望んでいるときはいつも、クウ教授の出版社が新版と共に出て来るために助成金を支給されるのを示し、どんなISORMiteもその提案のひょうきんを認識しないくらいには音痴でないと信じても構わないと思っているでしょう。
In short, it appears to be difficult to dispute the assertion that whatever sort of security blanket X.25 could represent would at best be an off shade of blue.
要するに、X.25が種類の何でもお守り毛布を表すことができたかが、せいぜい青のオフ色合いであるだろうという主張について議論するのが難しいように見えます。
Space-Time Considerations
時空問題
Another topic touched on earlier which deserves separate mention, if only to collect the scattered data in a single section, is that of what have been called space-time considerations. That is, we are concerned about how well X.25 in particular and the ISORM-derived protocols in general will implement, both in terms of size of protocol interpreters (PI's) and in terms of execution and delay times.
別々の言及に値するより早く触れられた別の話題、1つのセクションの点在しているデータを集めるために、時空問題と呼ばれたものがそれがいさえする場合、よかったでしょう。 すなわち、私たちは特にX.25と一般に、ISORMによって派生させられたプロトコルはプロトコルインタプリタ(PIのもの)のサイズと実行による道具と遅れ回がそうすることをおよそどれくらいよく心配しているか。
10 RFC 874 September 1982
10 RFC874 1982年9月
On the space heading, certainly the fact that X.25 offers more functionality in its end-to-end guise than is required to fulfill its network interface role suggests that X.25 PI's will be bigger than they need be. As an aside--but a striking one--it should be noted that X.25's end-to-end functions are at variance with the ISORM itself, for the "peer entity" of a DTE X.25 entity must surely be the local DCE X.25. Perhaps a later version of the ISORM will introduce the polypeer and give rise to a whole new round of Layering-Theologic controversy.* Speaking of the ISORM itself, those who hold that each layer must be traversed on each transmission are implicitly requiring that space (and time) be expended in the Session and Presentation Levels even for applications that have no need of their services. The Well-Known Socket concept of the ARM's primary Host-Host protocol, the Transmission Control Protocol (TCP), lets Session functionality be avoided for many applications, on the other hand--unless ISORM L5 is to usurp the Host's user identification/authentication role at some point. (Yes, we've heard the rumors that "null layers" might be introduced into the ISORM; no, we don't want to get into the theology of that either.)
確かに、スペース見出しでは、X.25が終わりから終わりへの外観におけるネットワーク・インターフェースの役割を実現させるのが必要であるより多くの機能性を提供するという事実は、X.25 PIがそれらでなければならないよりさらに大きくなると示唆します。 余談(衝撃的なもの)として、終わりから終わりへのX.25の機能がISORM自身と共に変化にあることに注意されるべきです、DTE X.25実体の「同輩実体」が確実に地方のDCE X.25であるに違いないので。 恐らく、ISORMの後のバージョンは、polypeerを導入して、Layering-Theologic論争の真新しいラウンドをもたらすでしょう。*ISORM自身について話して、各トランスミッションのときに各層を横断しなければならないと主張する人は、スペース(そして、時間)が彼らのサービスの必要性を全く持っていないアプリケーションのためにさえSessionとPresentation Levelsで費やされるのをそれとなく必要としています。 ARMの第一のHost-ホストプロトコルのWellによって知られているSocket概念(通信制御プロトコル(TCP))で、ISORM L5が何らかのポイントでHostのユーザ登録名/認証の役割を僣称することになっていないなら、他方では、多くのアプリケーションのためにSessionの機能性を避けます。 (はい、私たちは「ヌル層」がISORMに紹介されるかもしれないという噂を聞きました; いいえ、その神学に入りたいと思いません。)
On the time heading, X.25's virtual circuit view can be debilitating--or even crippling--to applications such as Packetized Speech where prompt delivery is preferred over ordered or even reliable delivery. (Some hold that the X.25 datagram option will remedy that; others hold that it's not "really datagrams"; we note the concern, agree with the others, and pass on.) Speaking of reliable delivery, as noted earlier some observers hold that in order to present an acceptable virtual circuit X.25 must have a protocol as strong as TCP "beneath" itself; again, we're in sympathy with them. Shifting focus again to the ISORM itself, it must be noted that the principle that "N-entities" must communicate with one another even in the same Host via "N-1 entities" even in the same Host is an over-zealous application of the Principle of Layering that must consume more time in the interpreting of the N-1 protocol than would a direct interface between N-level PI's or such process-level protocols as FTP and Telnet, as is done in the ARPANET-derived model.
時間見出しでは、X.25の仮想のサーキット眺望は迅速な配送が命令されたか信頼できる配送よりさえ好まれるPacketized Speechなどのアプリケーションに弱らせることであることができます(無力にすることさえ)。 (或るものは、X.25データグラムオプションがそれを治すと主張します; 他のものは、それが「本当にデータグラム」でないと保持します; 私たちは、関心に注意して、他のものに同意して、亡くなります。) 信頼できる配信について話して、何人かの観察者がX.25が持たなければならない許容できる仮想のサーキットにTCP “beneath"自身と同じくらい強いプロトコルを提示するために、より早く注意されるようにそれを保持します。 一方、私たちはそれらへの共感でいます。 再び焦点をISORM自身に移行させて、「N-実体」が同じHostさえの「N-1実体」を通して同じHostでさえお互いにコミュニケートしなければならないという原則がN-1プロトコルの解釈で、より多くの時間を費やさなければならないLayeringのPrincipleの熱心過ぎたアプリケーションであることに注意しなければならない、間のダイレクトインタフェースはPIかFTPのような過程レベルプロトコルとTelnet(されたコネのようなアルパネット派生模型)をNで平らにするでしょう。
Other space-time deficiencies could be adduced, but perhaps a shortcut will suffice. There is a Law of Programming (attributed to Sutherland) to the effect that "Programs are like waffles: you should always throw the first one out." Its relevance should become
他の時空欠乏を提出できましたが、恐らく、近道は十分でしょう。 「プログラムはワッフルに似ています」という効果にはProgrammingの法があります(サザーランドの結果と考えられます)。 「あなたはいつも最初のものを放り出すべきです。」 関連性はなるべきです。
________________ * And perhaps we now know why some just draw the highrises.
________________ * そして、恐らく、私たちが、今或るものがなぜただ描かれるかを知っている、highrisesします。
11 RFC 874 September 1982
11 RFC874 1982年9月
clear when it is realized that (with the possible exception of X.25) ISORM PI's are in general either first implementations or not even implemented yet (thus, the batter, as it were, is still being mixed). Contrast this with the iterations the ARPANET-derived PI's--and, for that matter, protocols--have gone through over the years and the grounds for our concern over X.25/ISORM space-time inefficiency become clear irrespective of corroborative detail. Factor in the consideration that space-time efficiency may be viewed as contrary to the corporate interests of the progenitors of X.25 ("the PTT's") and at least the current favorite for ISORM Level 4 (ECMA--the European Computer Manufacturers' Association), and it should become clear why we insist that space-time considerations be given separate mention even though touched upon elsewhere.*
まだ実行されてさえいて、一般に、(X.25の可能な例外がある)ISORM PIのものが最初に、実現か否かに関係なく、そうであると実感される(その結果、打者はまるでまだ混ぜられています)ときには、クリアしてください。 アルパネットで派生しているPI(さらに言えば、プロトコル)がX.25/ISORM時空非能率に関する私たちの心配の数年と根拠の上で直面していた確証的な詳細の如何にかかわらず明確になった繰り返しに対してこれを対照してください。 時空効率があるかもしれない考慮の要素は法人とは逆にISORM Level4(ECMA--ヨーロッパのコンピュータManufacturersのAssociation)、およびそれに、好きな(「PTTのもの」)と少なくとも電流がほかの場所で私たちが、なぜ触れられますが、別々の言及が時空問題に与えられていると主張するかが明確になるべきであるX.25の先祖の関心を. *とみなしました。
Getting Physical
物理的になります。
Still another area of concern over X.25 is that it dictates only one means of attaching a "DTE" to a "DCE." That is, earlier references to "the X.25 protocol(s)" were not typographical errors. Most of the time, "X.25" refers to ISORM Level 3; actually, though, the term subsumes L2 and L1 as well. Indeed, the lowest levels constitute particular bit serial interfaces. This is all very well for interfacing to "Public Data Nets" (again, it must be recalled that X.25's roots are in CCITT), but is scarcely appropriate to environments where the communications subnetwork may consist of geosynchronous communications satellite channels, "Packet Radios," or whatever. Indeed, even for conventional Local Area Networks it is often the case that a Direct Memory Access arrangement is desired so as to avoid bottlenecking--but DMA isn't HDLC, and the "vendor supported X.25 interface" so prized by some won't be DMA either, one imagines. (Speaking of LAN's, at least the evolving standard in that arena--"IEEE 802"--apparently will offer multiple physical interfaces depending on comm subnet style [although there is some disagreement on this point amongst readers of their draft specs]; we understand, however, that their Level 2 shares X.25's end-end aspirations--and we haven't checked up on DMA capability.) X.25, then, imposes constraints upon its users with regard to interface technology that are inappropriate.
X.25の上で重要なまだ、別の領域は"DTE"を"DCE"に付ける1つの手段だけを書き取るということです。 すなわち、「X.25プロトコル」の以前の参照は誤字ではありませんでした。 たいてい、「X.25"はISORMレベル3について言及します」。 もっとも、実際に、用語はまた、L2とL1を包括します。 本当に、最も低いレベルは特定の噛み付いているシリアルインタフェースを構成します。 これは、非常によくすべて「公衆データネット」に連結するもの(一方、CCITTにはX.25のルーツがあったと思い出さなければならない)です; 人は、しかし、環境へのどこのコミュニケーションサブネットワークが静止の通信衛星チャンネル、「パケットラジオ」、または何でもから成る、本当ににもかかわらずの、従来のローカル・エリア・ネットワークにおいてさえ、しばしば、Direct Memory Accessアレンジメントが隘路となるのを避けるために望まれているのにもかかわらずの、DMAがHDLCでないか、そして、何かがそうにならないようにとても大事な「業者の支持されたX.25インタフェース」ほとんど適切でないDMAがどちらかであると想像します。 (LANのものについて話して、アリーナ(「IEEE802」)が明らかにcommサブネットスタイルに依存する複数の物理インターフェースを提供して[彼らの草稿仕様の読者の中にこのポイントの上に何らかの不一致がありますが]; しかしながら、私たちは、それらのLevel2がX.25の終わり-終わりの切望を共有するのを理解しています--、私たちが持っていないので、少なくとも発展規格はDMA能力を調べました。) そして、X.25はインタフェース技術に関する不適当なユーザに規制を押しつけます。
________________ * The broad issue of design team composition is amplified in Padlipsky, M. A., "The Illusion of Vendor Support", M82-49, The MITRE Corporation, September 1982.
________________ * Padlipsky、M.A.、「業者サポートの幻想」でデザインチーム構成の広い問題は増幅されます、M82-49、MITRE社、1982年9月。
12 RFC 874 September 1982
12 RFC874 1982年9月
Other Observers' Concerns
他の観察者の関心
This paper owes much to conversations with a number of people, although the interpretations of their concerns are the author's responsibility. Mention should be made, however, of a few recent documents in the area: The Defense Communications Agency (DCA Code J110) has sent a coordinated DoD position [2] to NBS holding that X.25 cannot be the DoD's sole network interface standard; Dr. Vinton Cerf of the ARPA Information Processing Technology Office made a contribution to the former which contains a particularly lucid exposition of the desirability of proper "datagram" capability in DoD comm subnets [3]; Mr. Ray McFarland of the DoD Computer Security Evaluation Center has also explored the limitations of X.25 [4]. Whether because these authors are inherently more tactful than the present author, or whether their positions are more constraining, or even whether they have been more insulated from and hence less provoked by uninformed ISORMite zealots, none has seen fit to address the "quality" of X.25. That this paper chooses to do so may be attributed to any one of a number of reasons, but the author believes the key reason is contained in the following:
この紙は多くの人々との会話から多くを借りています、彼らの関心の解釈が作者の責任ですが。 しかしながら、その領域でいくつかの最近のドキュメントで言及をするべきです: Defense Communications Agency(DCA Code J110)はNBSの連携DoD位置[2]にX.25がDoDの唯一のネットワークインターフェース規格であるはずがないことを保持させました。 ARPA情報Processing Technologyオフィスのビントン・サーフ博士は前者へのDoD commの適切な「データグラム」能力の願わしさの特に明快な博覧会を含む貢献をサブネット[3]にしました。 また、DoDコンピュータSecurity Evaluationセンターのレイ・マクファーランドさんはX.25[4]の限界を探検しました。 したがって、それらが知らないISORMite熱狂者によってこれらの作者が本来現在の作者かそれとも彼らの位置がさらに抑制されているかどうかより如才ないか、さらに絶縁されていてまたはそれほど引き起こされないことにかかわらずさえX.25の「品質」についてアドレスになにも適していると決めていないのであるかどうか この紙が、そうするのを選ぶのが多くの理由のどれかの結果と考えられるかもしれませんが、作者は、主要な理由が以下に含まれていると信じています:
Conclusion
結論
X.25 is not a good thing.
X.25は良いものではありません。
References
参照
[1] Kent, S. T., "Security in Computer Networks," in Kuo, F., Ed., Protocols and Techniques for Data Communications Networks, Prentice-Hall, 1981, pp. 369-432.
[1] ケント、S.T.、クウ、F.(エド)とプロトコルとData Communications NetworksのためのTechniques、Prentice-ホール1981、ページにおける「コンピュータネットワークにおけるセキュリティ」 369-432.
[2] Letter to NBS from P. S. Selvaggi, Chief, Interoperability and Standards Office, 7 April 1982.
[2] P.S.SelvaggiからのNBSへの手紙とチーフと相互運用性と規格オフィス、1982年4月7日。
[3] Cerf, V. G., "Draft DoD Position Regarding X.25" in undated letter to P. S. Selvaggi.
[3] サーフ、V.G.は「P.S.Selvaggiへの日付のない手紙でX.25"に関してDoD位置を作成します」。
[4] Personal communications.
[4] 個人的なコミュニケーション。
13
13
一覧
スポンサーリンク