通信人家园

标题: 当用X.25上网时，也是用IP协议码？  [查看完整版帖子] [打印本页]

---

时间:  2010-4-11 23:07

作者: hppyhjh     标题: 当用X.25上网时，也是用IP协议码？

如题
我的理解，不是
因为X.25全部是走电话网的传输媒介，通过packet switching exchange (PSE)来建立虚电路，也就是说，
不像IP那样通过IP地址找到信息交换双方的路由
那么就有很多疑问：
两台电脑通过X.25连接后，通过什么软件交换信息？如何编写通信软件（现在是用套接口）？
一台电脑是如何连接到另一台电脑的？通过电话号码？
IP协议最开始，是在什么类型的广域网中开始使用的？

---

时间:  2010-4-12 11:20

作者: hppyhjh

顶起，没有人解释？

---

时间:  2010-4-12 13:15

作者: super__m

一台电脑是如何连接到另一台电脑的？通过电话号码？
你上面已经说的很清楚了，是建立虚电路，一条虚电路在两个地点之间建立一条临时性或永久性的“逻辑”通信信道。
TCP/IP(Transmission Control Protocol/Internet Protocol)：传输控制协议/网际协议。 它是由美国国防部在20世纪70年代开发的、用来支持全球网络互连建设的协议集的常用名称，TCP和IP是该协议集中最著名的两个。

---

时间:  2010-4-12 13:41

作者: xhy133

用X.25上网时，也是用IP协议,X.25是报文的封装协议

---

时间:  2010-4-12 13:57

作者: zzzcar

要看你的应用是怎么写的。如果是基于IP的，就要用。

---

时间:  2010-4-12 16:22

作者: hppyhjh

回三楼的
IP协议的主要用处是在网络中寻址，即给定一个IP，如何在网络中找到一条路由至达目的IP代表的地址
而X。25是使用虚电路建立连接，虚电路使用IP吗？如何不使用，那么X。25要用IP做什么呢？

---

时间:  2010-4-13 00:13

作者: leewj31

原帖由 hppyhjh 于 2010-4-12 16:22 发表
回三楼的
IP协议的主要用处是在网络中寻址，即给定一个IP，如何在网络中找到一条路由至达目的IP代表的地址
而X。25是使用虚电路建立连接，虚电路使用IP吗？如何不使用，那么X。25要用IP做什么呢？

上面的兄弟已经讲的很清楚了，X,25是报文的封装协议，X.25只是完成IP报文的传输，跟路由完全搭不上关系
X.25只是给出传输IP报文的通道，地位同IPoverSDH、IPoverATM甚至同IPoverWDM，至于IP报文转发那就是路由协议的事

---

时间:  2010-4-13 16:29

作者: jackhasun

x.25说白了就是一个第二层的协议！

---

时间:  2010-4-14 14:08

作者: 泰麒

原帖由 hppyhjh 于 2010-4-12 16:22 发表
回三楼的
IP协议的主要用处是在网络中寻址，即给定一个IP，如何在网络中找到一条路由至达目的IP代表的地址
而X。25是使用虚电路建立连接，虚电路使用IP吗？如何不使用，那么X。25要用IP做什么呢？

你真的大错特错了，如果IP协议的主要用处仅仅是为了寻址的话，那就太简单的，还有很多很多功能呢，真的建议你好好看看IP协议，特别是IP协议的7层是怎么划分的，及每层是干什么的，为什么要这么划分的。好好看看……

---

时间:  2010-4-15 23:02

作者: microcloud

X.25:以前用modem拨来拨去的那个就是,两台电脑就是通过电话号码连起来的,这时封装成PPP/SLIP帧,承载的ip分组
交换和路由:既要交换也要路由,以前用电,今后用光,现在用光电

X.25网络是第一个面向连接的网络,也是第一个公共数据网络.其数据分组包含3字节头部和128字节数据部分.它运行10年后,20世纪80年代被无错误控制,无流控制,面向连接的新的叫做帧中继的网络所取代.90年代以后,出现了面向连接的ATM网络.

[ 本帖最后由 microcloud 于 2010-4-16 00:44 编辑 ]

---

时间:  2010-4-16 00:06

作者: microcloud

X．25是在开放式系统互联（OSI）协议模型之前提出的，所以一些用来解释x．25的专用术语是不同的。这种标准在三个层定义协议，它和OSI协议栈的底下三层是紧密相关的：

物理层　　它称为X．21接口，定义从计算机／终端（数据终端设备，DTE）到X．25分组交换网络中的附件结点的物理／电气接口。RS－232－C通常用于X．21接口。

　　链路访问层定义象帧序列那样的数据传输。使用的协议是平衡式链路访问规程（LAP－B），它是高级数据链路控制（HDLC）协议的一部分。LAP－B的设计是为了点对点连接。它为异步平衡模式会话提供帧结构、错误检查和流控机制。LAP－B为确信一个分组已经抵达网络的每个链路提供了一条途径。

　　分组层 定义通过分组交换网络的可靠虚电路。这样，X．25就提供了点对点数据发送，而不是一点对多点发送。

　　在X．25中，虚电路的概念是非常重要的。一条虚电路在穿越分组交换网络的两个地点之间建立一条临时性或永久性的“逻辑”通信信道。使用一条电路使用可以保证分组是按照顺序抵达的，这是因为它们都按照同一条路径进行传输。它为数据在网络上进行传输提供了可靠的方式。在X．25中有两种类型的虚电路：

　　临时性虚电路 将建立基于呼叫的虚电路，然后在数据传输会话结束时拆除。

　　永久性虚电路　是网络指定的固定虚电路，像专线一样，无需建立和清除连接，可直接传送数据．

　　无论是交换虚电路或是永久虚电路，都是由几条＂虚拟＂连接共享一条物理信道．一对分组交换机之间至少有一条物理链路，几条虚电路可以共享该物理链路．每一条虚电路有相邻结点之间的一对缓冲区实现，这些缓冲区被分配给不同的虚电路代号以示区别．建立虚电路的过程就是在沿线各结点上分配缓冲区和虚电路代号的过程．

　　分组中的虚电路代号用12位十进制数字表示（４位组号和８位信道号）．除代号０为诊断分组保留之外，建立虚电路时可以使用其余的4095个代号，因而理论上说，一个DTE最多建立4095条虚电路。这些虚电路多路复用DTE-DCE之间的物理链路，进行全双工通信。

永久虚电路　　在两个端点结点之间保持一种固定连接。

　　X．25使用呼叫建立分组，从而在两个端点站点之间建立一条通信信道。一旦这个呼叫建立了，在这两个站点之间数据分组就可以传输信息了。注意，由于X．25是一种面向连接的服务，因而分组不需要源地址和目的地址。虚电路为传输分组通过网络到达目的地提供了一条通信路径。然而，对分组授予了一个号码，这个号码可以被连接源地和目的地的信道鉴别。

　　X．25网络易于安装和维护。它是根据发送的分组数据来收费的，在一些情况下，还会考虑连通的时间。牢记，其它一些服务更适合于高速局域网传输（例如帧中继）或专用连接。

　　X.25网络只是一个以虚电路服务为基础的 对公用分组交换网接口的规格说明。它动态的对用户传输的信息流分配带宽，能够有效的解决突发性和大信息流传输的问题，可以对传输的信息进行加密和有效的差错控制。

　　该分组交换网一般只用于要求传输费用比较少，而远程传输速率要求又不高的广域网使用环境

[ 本帖最后由 microcloud 于 2010-4-16 00:31 编辑 ]

---

时间:  2010-4-16 00:12

作者: microcloud

Linux内核支持X.25,开发驱动程序有专门的包

Microsoft对X.25地址(非ip地址 )的说明:

Within the X.25 network protocol specification, the X.121 specification defines the format of the X.25 address. The structure of X.25 addresses resembles phone numbers. The following text explains the structure of the X.25 address. Data Network Iden...

The following text explains the structure of the X.25 address.

Data Network Identification Code (DNIC)The DNIC makes up the first four digits in an X.121 or X.25 address.

Country CodeThe first three digits in the DNIC are the country code. For example, the country code for Canada is 302, so every X.25 network address in Canada begins with 302. The U.S. has several country codes. U.S. DNICs can start with 310, 311, 312, or 313.

Network ID
The fourth digit is the Network ID, identifying which network it is. For example, DataPac of Canada has a network ID of 0, so the DNIC for DataPac is 3020. Infoswitch of Canada has a network ID of 9, so Infoswitch has a DNIC of 3029. In the U.S. MCI has a DNIC of 3106, Sprinet has a DNIC of 3110, and Infonet has a DNIC of 3137.

The National Number
The National Number is the 5th through 12th digits of the X.25 address. This number is used to identify a unique DCE node (X.25 node) within a network. Network vendors lease DCE or X.25 nodes. Each of these nodes must have a unique X.121 address. Within a given vendor's X.25 network, the first four digits of the DCE addresses will all be the same--they will be the DNIC for the vendor. Digits 5 through 12 (the National Number) are assigned by the network vendor to create a unique X.25 address for each X.25 node, or Circuit Terminating Equipment (DCE).

Subaddress
Most networks support a two-digit subaddress, which can be added to the end of the National Number. The two digits are not used by the network, but are passed through for use by the user's Data Terminating Equipment (DTE). The DTE is primarily the X.25 card (Eicon or Atlantis) that the X.25 application uses to communicate with the network DCE node, where each physical port on an X.25 card is connected to a DCE node.

The two subaddress digits are usually used when X.25 applications are located on LAN workstations. Eicon and Atlantis cards require a two-digit subaddress when they will be managing X.25 sessions (or virtual circuits) for X.25 applications (such as an MTA or X.400 Gateway) when the application is running on a LAN workstation that does not contain the Eicon or Atlantis card.

Note that the .INI entry "X25SubAddress=" for MTA in PC Mail version 3.2x is somewhat misleading because when the .INI also has the entry "CommType=X25Eicon", the "X25SubAddress" will always be the X.25 address of the network DCE the Eicon port is attached to (usually a 12-digit number composed of DNIC and a National Number), with the actual two-digit subaddress appended to the end of the long X.25 (X.121) address if it is needed. For MTAs launched with the INI entry "CommType=X25Atlan", the .INI entry "X25SubAddress=" is only two digits. The difference is due to design differences between the Ecion and Atlantis cards.

Inter-Network
Sometimes to make a connection between two networks in two different countries, an extra digit is added before the DNIC, usually a one. This varies by vendor.

The current maximum length for an X.121 address is 15 digits. The typical address length is 12 or 14 digits.

Null-Modem Operation
When two X.25 cards are connected with an X.25 null-modem cable, there is no network present and the long X.121 address is not needed. The optional two-digit subaddress will be needed if the X.25 cards are also connected to a LAN and will be establishing X.25 sessions for PC Mail version 3.2x MTAs, Gateways or MS Exchange processes running on LAN PCs, PCs without the X.25 card installed in them.

[ 本帖最后由 microcloud 于 2010-4-16 00:39 编辑 ]

---

时间:  2010-4-16 10:51

作者: shenhqi

1.IP协议只有4层，不是7层的。
2.X.25是一个极古老的协议了，目前很少使用。
3.如果一定要用X.25传输IP也是可以的，就是所谓的封装。
4.用IP进行传输时，如果必须经过一段X.25的网络，就只能使用封装技术，而不是将IP转换成X.25，过后再转换回来，没有这种做法。虽然一定要这样做也可以做到，但这是一种愚蠢的做法。

---

时间:  2010-4-17 17:19

作者: hppyhjh

嗯我来做一个总结吧．
如同microcloud所说，而不是像super_m所说，x.25的目标地址确是由类似电话号码的格式来标识的，叫做X.121地址格式，它是１４位十进制数字．头４位代表区域＼国家＼网络，具体细节可查资料．这个地址，仅在建立连接时寻找路径时使用，连接建立后，各个网络结点只需要根据逻辑信道号对照表即知道如何转发数据包．
linux在x.25环境中的网络程序编写，也是采用ＢＳＤ套接口，与现在的套接口编程类似，唯一不同的地方在于地址结构．而Ｘ．２５流行于上世纪８０年代，linux源于1991年，在linux之前的情况，我就不知道了．

---

时间:  2010-4-17 20:26

作者: microcloud     标题: RFC1356

Network Working Group A. Malis
Request for Comments: 1356 BBN Communications
Obsoletes: RFC877 D. Robinson
Computervision Systems Integration
R. Ullmann
Process Software Corporation
August 1992

Multiprotocol Interconnect
on X.25 and ISDN in the Packet Mode

Status of this Memo

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

Abstract

This document specifies the encapsulation of IP and other network
layer protocols over X.25 networks, in accordance and alignment with
ISO/IEC and CCITT standards. It is a replacement for RFC877, "A
Standard for the Transmission of IP Datagrams Over Public Data
Networks" [1].

It was written to correct several ambiguities in the Internet
Standard for IP/X.25 (RFC877), to align it with ISO/IEC standards
that have been written following RFC877, to allow interoperable
multiprotocol operation between routers and bridges over X.25, and to
add some additional remarks based upon practical experience with the
specification over the 8 years since that RFC.

The substantive change to the IP encapsulation is an increase in the
allowed IP datagram Maximum Transmission Unit from 576 to 1600, to
reflect existing practice.

This document also specifies the Internet encapsulation for
protocols, including IP, on the packet mode of the ISDN. It applies
to the use of Internet protocols on the ISDN in the circuit mode only
when the circuit is established as an end-to-end X.25 connection.

Acknowledgements

RFC877 was written by J. T. Korb of Purdue University, and this
document follows that RFC's format and builds upon its text as
appropriate. This document was produced under the auspices of the IP
over Large Public Data Networks Working Group of the IETF.

1. Conventions

The following language conventions are used in the items of
specification in this document:

o MUST -- the item is an absolute requirement of the specification.
MUST is only used where it is actually required for interoperation,
not to try to impose a particular method on implementors where not
required for interoperability.

o SHOULD -- the item should be followed for all but exceptional
circumstances.

o MAY or optional -- the item is truly optional and may be followed
or ignored according to the needs of the implementor.

The words "should" and "may" are also used, in lower case, in their
more ordinary senses.

2. Introduction

RFC877 was written to document the method CSNET and the VAN Gateway
had adopted to transmit IP datagrams over X.25 networks. Its success
is evident in its current wide use and the inclusion of its IP
protocol identifier in ISO/IEC TR 9577, "Protocol Identification in
the Network Layer" [2], which is administered by ISO/IEC and CCITT.

However, due to changes in the scope of X.25 and the protocols that
it can carry, several inadequacies have become evident in the RFC,
especially in the areas of IP datagram Maximum Transmission Unit
(MTU) size, X.25 maximum data packet size, virtual circuit
management, and the interoperable encapsulation, over X.25, of
protocols other than IP between multiprotocol routers and bridges.

As with RFC877, one or more X.25 virtual circuits are opened on
demand when datagrams arrive at the network interface for
transmission. A virtual circuit is closed after some period of
inactivity (the length of the period depends on the cost associated
with an open virtual circuit). A virtual circuit may also be closed
if the interface runs out of virtual circuits.

3. Standards

3.1 Protocol Data Units (PDUs) are sent as X.25 "complete packet
sequences". That is, PDUs begin on X.25 data packet boundaries and
the M bit ("more data") is used to fragment PDUs that are larger
than one X.25 data packet in length.

In the IP encapsulation the PDU is the IP datagram.

3.2 The first octet in the Call User Data (CUD) Field (the first data
octet in the Call Request packet) is used for protocol
demultiplexing, in accordance with the Subsequent Protocol
Identifier (SPI) in ISO/IEC TR 9577. This field contains a one-
octet Network Layer Protocol Identifier (NLPID), which identifies
the network layer protocol encapsulated over the X.25 virtual
circuit. The CUD field MAY contain more than one octet of
information, and receivers MUST ignore all extraneous octets in the
field.

In the following discussion, the most significant digit of the
binary numbers is left-most.

For the Internet community, the NLPID has four relevant values:

The value hex CC (binary 11001100, decimal 204) is IP [6].
Conformance with this specification requires that IP be supported.
See section 5.1 for a diagram of the packet formats.

The value hex 81 (binary 10000001, decimal 129) identifies ISO/IEC
8473 (CLNP) [4]. ISO/IEC TR 9577 specifically allows other ISO/IEC
connectionless-protocol packets, such as ES-IS and IS-IS, to also be
carried on the same virtual circuit as CLNP. Conformance with this
specification does not require that CLNP be supported. See section
5.2 for a diagram of the packet formats.

The value hex 82 (binary 10000010, decimal 130) is used specifically
for ISO/IEC 9542 (ES-IS) [5]. If there is already a circuit open to
carry CLNP, then it is not necessary to open a second circuit to
carry ES-IS. Conformance with this specification does not require
that ES-IS be supported.

The value hex 80 (binary 10000000, decimal 128) identifies the use
of IEEE Subnetwork Access Protocol (SNAP) [3] to further encapsulate
and identify a single network-layer protocol. The SNAP-encapsulated
protocol is identified by including a five-octet SNAP header in the
Call Request CUD field immediately following the hex 80 octet. SNAP
headers are not included in the subsequent X.25 data packets. Only
one SNAP-encapsulated protocol may be carried over a virtual circuit

opened using this encoding. The receiver SHOULD accept the incoming
call only if it can support the particular SNAP-identified protocol.
Conformance with this specification does not require that this SNAP
encoding be supported. See section 5.3 for a diagram of the packet
formats.

The value hex 00 (binary 00000000, decimal 0) identifies the Null
encapsulation, used to multiplex multiple network layer protocols
over the same circuit. This encoding is further discussed in
section 3.3 below.

The "Assigned Numbers" RFC[7] contains one other non-CCITT and
non-ISO/IEC value that has been in active use for Internet X.25
encapsulation identification, namely hex C5 (binary 11000101,
decimal 197) for Blacker X.25. This value MAY continue to be used,
but only by prior preconfiguration of the sending and receiving X.25
interfaces to support this value. The value hex CD (binary
11001101, decimal 205), listed in "Assigned Numbers" for "ISO-IP",
is also used by Blacker and also can only be used by prior
preconfiguration of the sending and receiving X.25 interfaces.

Each system MUST only accept calls for protocols it can process;
every Internet system MUST be able to accept the CC encapsulation
for IP datagrams. A system MUST NOT accept calls, and then
immediately clear them. Accepting the call indicates to the calling
system that the protocol encapsulation is supported; on some
networks, a call accepted and cleared is charged, while a call
cleared in the request state is not charged.

Systems that support NLPIDs other than hex CC (for IP) SHOULD allow
their use to be configured on a per-peer address basis. The use of
hex CC (for IP) MUST always be allowed between peers and cannot be
configured.

3.3 The NLPID encodings discussed in section 3.2 only allow a single
network layer protocol to be sent over a circuit. The Null
encapsulation, identified by a NLPID encoding of hex 00, is used in
order to multiplex multiple network layer protocols over one
circuit.

When the Null encapsulation is used, each X.25 complete packet
sequence sent on the circuit begins with a one-octet NLPID, which
identifies the network layer protocol data unit contained only in
that particular complete packet sequence. Further, if the SNAP
NLPID (hex 80) is used, then the NLPID octet is immediately followed
by the five-octet SNAP header, which is then immediately followed by
the encapsulated PDU. The encapsulated network layer protocol MAY
differ from one complete packet sequence to the next over the same

circuit.

When a receiver is presented with an Incoming Call identifying the
Null encapsulation, the receiver MUST accept the call if it supports
the Null encapsulation for any network layer protocol. The receiver
MAY then silently discard a multiplexed PDU if it cannot support
that particular encapsulated protocol. See section 5.4 for a
diagram of the packet formats.

Use of the single network layer protocol circuits described in
section 3.2 is more efficient in terms of bandwidth if only a
limited number of protocols are supported by a system. It also
allows each system to determine exactly which protocols are
supported by its communicating partner. Other advantages include
being able to use X.25 accounting to detail each protocol and
different quality of service or flow control windows for different
protocols.

The Null encapsulation, for multiplexing, is useful when a system,
for any reason (such as implementation restrictions or network cost
considerations), may only open a limited number of virtual circuits
simultaneously. This is the method most likely to be used by a
multiprotocol router, to avoid using an unreasonable number of
virtual circuits.

If performing IEEE 802.1d bridging across X.25 is desired, then the
Null encapsulation MUST be used. See section 4.2 for a further
discussion.

Conformance with this specification does not require that the Null
encapsulation be supported.

Systems that support the Null encapsulation SHOULD allow its use to
be configured on a per-peer address basis.

3.4 For compatibility with existing practice, and RFC877 systems, IP
datagrams MUST, by default, be encapsulated on a virtual circuit
opened with the CC CUD.

Implementations MAY also support up to three other possible
encapsulations of IP:

o IP may be contained in multiplexed data packets on a circuit using
the Null (multiplexed) encapsulation. Such data packets are
identified by a NLPID of hex CC.

o IP may be encapsulated within the SNAP encapsulation on a circuit.
This encapsulation is identified by containing, in the 5-octet SNAP

header, an Organizationally Unique Identifier (OUI) of hex 00-00-00
and Protocol Identifier (PID) of hex 08-00.

o On a circuit using the Null encapsulation, IP may be contained
within the SNAP encapsulation of IP in multiplexed data packets.

If an implementation supports the SNAP, multiplexed, and/or
multiplexed SNAP encapsulations, then it MUST accept the encoding of
IP within the supported encapsulation(s), MAY send IP using those
encapsulation(s), and MUST allow the IP encapsulation to send to be
configured on a per-peer address basis.

3.5 The negotiable facilities of X.25 MAY be used (e.g., packet and
window size negotiation). Since PDUs are sent as complete packet
sequences, any maximum X.25 data packet size MAY be configured or
negotiated between systems and their network service providers. See
section 4.5 for a discussion of maximum X.25 data packet size and
network performance.

There is no implied relationship between PDU size and X.25 packet
size (i.e., the method of setting IP MTU based on X.25 packet size
in RFC877 is not used).

3.6 Every system MUST be able to receive and transmit PDUs up to at
least 1600 octets in length.

For compatibility with existing practice, as well as
interoperability with RFC877 systems, the default transmit MTU for
IP datagrams SHOULD default to 1500, and MUST be configurable in at
least the range 576 to 1600.

This is done with a view toward a standard default IP MTU of 1500,
used on both local and wide area networks with no fragmentation at
routers. Actually redefining the IP default MTU is, of course,
outside the scope of this specification.

The PDU size (e.g., IP MTU) MUST be configurable, on at least a
per-interface basis. The maximum transmitted PDU length SHOULD be
configurable on a per-peer basis, and MAY be configurable on a per-
encapsulation basis as well. Note that the ability to configure to
send IP datagrams with an MTU of 576 octets and to receive IP
datagrams of 1600 octets is essential to interoperate with existing
implementations of RFC877 and implementations of this
specification.

Note that on circuits using the Null (multiplexed) encapsulation,
when IP packets are encapsulated using the NLPID of hex CC, then the
default IP MTU of 1500 implies a PDU size of 1501; a PDU size of

1600 implies an IP MTU of 1599. When IP packets are encapsulated
using the NLPID of hex 80 followed by the SNAP header for IP, then
the default IP MTU of 1500 implies a PDU size of 1506; a PDU size of
1600 implies an IP MTU of 1594.

Of course, an implementation MAY support a maximum PDU size larger
than 1600 octets. In particular, there is no limit to the size that
may be used when explicitly configured by communicating peers.

3.7 Each ISO/IEC TR 9577 encapsulation (e.g., IP, CLNP, and SNAP)
requires a separate virtual circuit between systems. In addition,
multiple virtual circuits for a single encapsulation MAY be used
between systems, to, for example, increase throughput (see notes in
section 4.5).

Receivers SHOULD accept multiple incoming calls with the same
encapsulation from a single system. Having done so, receivers MUST
then accept incoming PDUs on the additional circuit(s), and SHOULD
transmit on the additional circuits.

Shedding load by refusing additional calls for the same
encapsulation with a X.25 diagnostic of 0 (DTE clearing) is correct
practice, as is shortening inactivity timers to try to clear
circuits.

Receivers MUST NOT accept the incoming call, only to close the
circuit or ignore PDUs from the circuit.

Because opening multiple virtual circuits specifying the same
encapsulation is specifically allowed, algorithms to prevent virtual
circuit call collision, such as the one found in section 8.4.3.5 of
ISO/IEC 8473 [4], MUST NOT be implemented.

While allowing multiple virtual circuits for a single protocol is
specifically desired and allowed, implementations MAY choose (by
configuration) to permit only a single circuit for some protocols to
some destinations. Only in such a case, if a colliding incoming
call is received while a call request is pending, the incoming call
shall be rejected. Note that this may result in a failure to
establish a connection. In such a case, each system shall wait at
least a configurable collision retry time before retrying. Adding a
random increment, with exponential backoff if necessary, is
recommended.

3.8 Either system MAY close a virtual circuit. If the virtual circuit
is closed or reset while a datagram is being transmitted, the
datagram is lost. Systems SHOULD be able to configure a minimum
holding time for circuits to remain open as long as the endpoints

are up. (Note that holding time, the time the circuit has been open,
differs from idle time.)

3.9 Each system MUST use an inactivity timer to clear virtual circuits
that are idle for some period of time. Some X.25 networks,
including the ISDN under present tariffs in most areas, charge for
virtual circuit holding time. Even where they do not, the resource
SHOULD be released when idle. The timer SHOULD be configurable; a
timer value of "infinite" is acceptable when explicitly configured.
The default SHOULD be a small number of minutes. For IP, a
reasonable default is 90 seconds.

3.10 Systems SHOULD allow calls from unconfigured calling addresses
(presumably not collect calls, however); this SHOULD be a
configuration option. A system accepting such a call will, of
course, not transmit on that virtual circuit if it cannot determine
the protocol (e.g., IP) address of the caller. As an example, on
the DDN this is not a restriction because IP addresses can be
determined algorithmically based upon the caller's X.121 address
[7,9].

Allowing such calls helps work around various "helpful" address
translations done by the network(s), as well as allowing
experimentation with various address resolution protocols.

3.11 Systems SHOULD use a configurable hold-down timer to prevent calls
to failed destinations from being immediately retried.

3.12 X.25 implementations MUST minimally support the following features
in order to conform with this specification: call setup and
clearing and complete packet sequences. For better performance
and/or interoperability, X.25 implementations SHOULD also support:
extended frame and/or packet sequence numbering, flow control
parameter negotiation, and reverse charging.

3.13 The following X.25 features MUST NOT be used: interrupt packets and
the Q bit (indicating qualified data). Other X.25 features not
explicitly discussed in this document, such as fast select and the
D bit (indicating end-to-end significance) SHOULD NOT be used.

Use of the D bit will interfere with use of the M bit (more data
sequences) required for identification of PDUs. In particular, as
subscription to the D bit modification facility (X.25-1988, section
3.3) will prevent proper operation, this user facility MUST NOT be
subscribed.

3.14 ISO/IEC 8208 [11] defines the clearing diagnostic code 249 to
signify that a requested protocol is not supported. Systems MAY

use this diagnostic code when clearing an incoming call because the
identified protocol is not supported. Non-8208 systems more
typically use a diagnostic code of 0 for this function. Supplying
a diagnostic code is not mandatory, but when it is supplied for
this reason, it MUST be either of these two values.

4. General Remarks

The following remarks are not specifications or requirements for
implementations, but provide developers and users with guidelines and
the results of operational experience with RFC877.

4.1 Protocols above the network layer, such as TCP or TP4, do not
affect this standard. In particular, no attempt is made to open
X.25 virtual circuits corresponding to TCP or TP4 connections.

4.2 Both the circuit and multiplexed encapsulations of SNAP may be used
to contain any SNAP encapsulated protocol. In particular, this
includes using an OUI of 00-00-00 and the two octets of PID
containing an Ethertype [7], or using IEEE 802.1's OUI of hex 00-
80-C2 with the bridging PIDs listed in RFC1294, "Multiprotocol
Interconnect over Frame Relay" [8]. Note that IEEE 802.1d bridging
can only be performed over a circuit using the Null (multiplexed)
encapsulation of SNAP, because of the necessity of preserving the
order of PDUs (including 802.1d Bridged PDUs) using different SNAP
headers.

4.3 Experience has shown that there are X.25 implementations that will
assign calls with CC CUD to the X.29 PAD (remote login) facility
when the IP layer is not installed, not configured properly, or not
operating (indeed, they assume that ALL calls for unconfigured or
unbound X.25 protocol IDs are for X.29 PAD sessions). Call
originators can detect that this has occurred at the receiver if the
originator receives any X.25 data packets with the Q bit set,
especially if the first octet of these packets is hex 02, 04, or 06
(X.29 PAD parameter commands). In this case, the originator should
clear the call, and log the occurrence so that the misconfigured
X.25 address can be corrected. It may be useful to also use the
hold-down timer (see section 3.11) to prevent further attempts for
some period of time.

4.4 It is often assumed that a larger X.25 data packet size will result
in increased performance. This is not necessarily true: in typical
X.25 networks it will actually decrease performance.

Many, if not most, X.25 networks completely store X.25 data packets
in each switch before forwarding them. If the X.25 network requires
a path through a number of switches, and low-speed trunks are used,

then negotiating and using large X.25 data packets could result in
large transit delays through the X.25 network as a result of the
time required to clock the data packets over each low-speed trunk.
If a small end-to-end window size is also used, this may also
adversely affect the end-to-end throughput of the X.25 circuit. For
this reason, segmenting large IP datagrams in the X.25 layer into
complete packet sequences of smaller X.25 data packets allows a
greater amount of pipelining through the X.25 switches, with
subsequent improvements in end-to-end throughput.

Large X.25 data packet size combined with slow (e.g., 9.6Kbps)
physical circuits will also increase individual packet latency for
other virtual circuits on the same path; this may cause unacceptable
effects on, for example, X.29 connections.

This discussion is further complicated by the fact that X.25
networks are free to internally combine or split X.25 data packets
as long as the complete packet sequence is preserved.

The optimum X.25 data packet size is, therefore, dependent on the
network, and is not necessarily the largest size offered by that
network.

4.5 Another method of increasing performance is to open multiple virtual
circuits to the same destination, specifying the same CUD. Like
packet size, this is not always the best method.

When the throughput limitation is due to X.25 window size, opening
multiple circuits effectively multiplies the window, and may
increase performance.

However, opening multiple circuits also competes more effectively
for the physical path, by taking more shares of the available
bandwidth. While this may be desirable to the user of the
encapsulation, it may be somewhat less desirable to the other users
of the path.

Opening multiple circuits may also cause datagram sequencing and
reordering problems in end systems with limited buffering (e.g., at
the TCP level, receiving segments out of order, when a single
circuit would have delivered them in order). This will only affect
performance, not correctness of operation.

Opening multiple circuits may also increase the cost of delivering
datagrams across a public data network.

4.6 This document does not specify any method of dynamic IP to X.25 (or
X.121) address resolution. The problem is left for further study.

Typical present-day implementations use static tables of varying
kinds, or an algorithmic transformation between IP and X.121
addresses [7,9]. There are proposals for other methods. In
particular, RFC1183 [10] describes Domain Name System (DNS)
resource records that may be useful either for automatic resolution
or for maintenance of static tables. Use of these method(s) is
entirely experimental at this time.

5. Packet Formats

For each protocol encoding, the diagrams outline the call request and
the data packet format. The data packet shown is the first of a
complete packet (M bit) sequence.

5.1 IP Encapsulation

Call Request:

+----------------+-----------+------------+----+
| GFI, LCN, type | addresses | facilities | CC |
+----------------+-----------+------------+----+

X.25 data packets:

+----------------+------------------------+
| GFI, LCN, I | IP datagram |
+----------------+------------------------+

5.2 CLNP, ES-IS, IS-IS Encapsulation

Call Request:

+----------------+-----------+------------+----+
| GFI, LCN, type | addresses | facilities | 81 |
+----------------+-----------+------------+----+

X.25 data packets:

+----------------+--------------------------------+
| GFI, LCN, I | CLNP, ES-IS, or IS-IS datagram |
+----------------+--------------------------------+

(Note that these datagrams are self-identifying in their
first octet).

5.3 SNAP Encapsulation

Call Request:

+----------------+-----------+------------+----+-----------------+
| GFI, LCN, type | addresses | facilities | 80 | SNAP (5 octets) |
+----------------+-----------+------------+----+-----------------+

X.25 data packets:

+----------------+-------------------------------------+
| GFI, LCN, I | Protocol Data Unit (no SNAP header) |
+----------------+-------------------------------------+

5.4 Null (Multiplexed) Encapsulation

Call Request:

+----------------+-----------+------------+----+
| GFI, LCN, type | addresses | facilities | 00 |
+----------------+-----------+------------+----+

X.25 data packets:

+----------------+-----------------+---------------------+
| GFI, LCN, I | NLPID (1 octet) | Protocol Data Unit |
+----------------+-----------------+---------------------+

Examples of data packets:

Multiplexed IP datagram:

+----------------+----+-----------------------+
| GFI, LCN, I | CC | IP datagram |
+----------------+----+-----------------------+

Multiplexed CLNP datagram:

+----------------+----+-------------------------+
| GFI, LCN, I | 81 | CLNP datagram |
+----------------+----+-------------------------+

Multiplexed SNAP PDU:

+----------------+----+-----------------+--------------------+
| GFI, LCN, I | 80 | SNAP (5 octets) | Protocol Data Unit |
+----------------+----+-----------------+--------------------+

6. Security Considerations

Security issues are not discussed in this memo.

7. References

[1] Korb, J., "A Standard for the Transmission of IP Datagrams Over
Public Data Networks", RFC877, Purdue University, September
1983.

[2] ISO/IEC TR 9577, Information technology - Telecommunications and
Information exchange between systems - Protocol Identification
in the network layer, 1990 (E) 1990-10-15.

[3] IEEE, "IEEE Standard for Local and Metropolitan Area Networks:
Overview and Architecture", IEEE Standards 802-1990.

[4] ISO/IEC 8473, Information processing systems - Data
communications - Protocol for providing the connectionless- mode
network service, 1988.

[5] ISO/IEC 9542, Information processing systems -
Telecommunications and information exchange between systems -
End system to intermediate system routeing protocol for use in
conjunction with the protocol for providing the connectionless-
mode network service (ISO/IEC 8473), 1988.

[6] Postel, J., Editor., "Internet Protocol - DARPA Internet Program
Protocol Specification", RFC791, USC/Information Sciences
Institute, September 1981.

[7] Reynolds, J. and J. Postel, "Assigned Numbers", RFC1340,
USC/Information Sciences Institute, July 1992.

[8] Bradley, T., Brown, C., and A. Malis, "Multiprotocol
Interconnect over Frame Relay", RFC1294, Wellfleet
Communications and BBN Communications, January 1992.

[9] "Defense Data Network X.25 Host Interface Specification",
contained in "DDN Protocol Handbook", Volume 1, DDN Network
Information Center 50004, December 1985.

[10] Everhart, C., Mamakos, L., Ullmann, R, and P. Mockapetris,
Editors, "New DNS RR Definitions", RFC1183, Transarc,
University of Maryland, Prime Computer, USC/Information Sciences
Institute, October 1990.

[11] ISO/IEC 8208, Information processing systems - Data

communications - X.25 Packet Level Protocol for Data Terminal
Equipment, 1987.

---

时间:  2010-4-17 20:32

作者: microcloud     标题: RFC1598 - PPP in X.25

Working Group W. Simpson
Request for Comments: 1598 Daydreamer
Category: Standards Track March 1994

PPP in X.25

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.

Abstract

The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
This document describes the use of X.25 for framing PPP encapsulated
packets.

This document is the product of the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the ietf-ppp@merit.edu mailing list.

Applicability

This specification is intended for those implementations which desire
to use facilities which are defined for PPP, such as the Link Control
Protocol, Network-layer Control Protocols, authentication, and
compression. These capabilities require a point-to-point
relationship between peers, and are not designed for multi-point or
multi-access environments.

Table of Contents

1. Introduction .......................................... 1

2. Physical Layer Requirements ........................... 2

3. The Data Link Layer ................................... 2
3.1 Frame Format .................................... 3
3.2 Modification of the Basic Frame ................. 3

4. Call Setup ............................................ 4

5. Configuration Details ................................. 5

SECURITY CONSIDERATIONS ...................................... 6

REFERENCES ................................................... 6

ACKNOWLEDGEMENTS ............................................. 6

CHAIR'S ADDRESS .............................................. 7

AUTHOR'S ADDRESS ............................................. 7

1. Introduction

CCITT recommendation X.25 [2] describes a network layer protocol
providing error-free, sequenced, flow controlled, virtual circuits.
X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335
and 6256.

PPP also uses ISO 3309 HDLC as a basis for its framing [3].

When X.25 is configured as a point-to-point circuit, PPP can use X.25
as a framing mechanism, ignoring its other features. This is
equivalent to the technique used to carry SNAP headers over X.25 [4].

At one time, it had been hoped that PPP HDLC frames and X.25 frames
would co-exist on the same links. Equipment could gradually be
converted to PPP. Subsequently, it has been learned that some
switches actually remove the X.25 header, transport packets to
another switch using a different protocol such as Frame Relay, and
reconstruct the X.25 header at the final hop. Co-existance and
gradual migration are precluded.

2. Physical Layer Requirements

PPP treats X.25 framing as a bit synchronous link. The link MUST be
full-duplex, but MAY be either dedicated (permanent) or switched.

Interface Format

PPP presents an octet interface to the physical layer. There is
no provision for sub-octets to be supplied or accepted.

Transmission Rate

PPP does not impose any restrictions regarding transmission rate,
other than that of the particular X.25 interface.

Control Signals

Implementation of X.25 requires the provision of control signals,
which indicate when the link has become connected or disconnected.
These in turn provide the Up and Down events to the LCP state
machine.

Because PPP does not normally require the use of control signals,
the failure of such signals MUST NOT affect correct operation of
PPP. Implications are discussed in [2].

Encoding

The definition of various encodings is the responsibility of the
DTE/DCE equipment in use, and is outside the scope of this
specification.

While PPP will operate without regard to the underlying
representation of the bit stream, X.25 requires NRZ encoding.

3. The Data Link Layer

This specification uses the principles, terminology, and frame
structure described in "Multiprotocol Interconnect on X.25 and ISDN
in the Packet Mode" [4].

The purpose of this specification is not to document what is already
standardized in [4]. Instead, this document attempts to give a
concise summary and point out specific options and features used by
PPP.

3.1. Frame Format

Since both "PPP in HDLC Framing" [3] and X.25 use ISO 3309 as a basis
for framing, the X.25 header is easily substituted for the smaller
HDLC header. The fields are transmitted from left to right.

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
+-+-+-+-+-+-+-+-+
| Flag (0x7e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | Control |D|Q| SVC# (hi) | SVC# (lo) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|p(r) |M|p(s) |0| PPP Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The PPP Protocol field and the following Information and Padding
fields are described in the Point-to-Point Protocol Encapsulation
[1].

3.2. Modification of the Basic Frame

The Link Control Protocol can negotiate modifications to the basic
frame structure. However, modified frames will always be clearly
distinguishable from standard frames.

Address-and-Control-Field-Compression

Because the Address and Control field values are not constant, and
are modified as the frame is transported by the network switching
fabric, Address-and-Control-Field-Compression MUST NOT be
negotiated.

Protocol-Field-Compression

Note that unlike the HDLC framing, the X.25 framing does not align
the Information field on a 32-bit boundary. Alignment to a 16-bit
boundary occurs when the Protocol field is compressed to a single
octet. When this improves throughput, Protocol-Field-Compression
SHOULD be negotiated.

4. Call Setup

When the link is configured as a Permanent Virtual Circuit (PVC),
support for Switched Virtual Circuit (SVC) call setup and clearing is
not required. Calls are Established and Terminated using PPP LCP
packets.

When the link is configured as a Switched Virtual Circuit (SVC), the
first octet in the Call User Data (CUD) Field (the first data octet
in the Call Request packet) is used for protocol demultiplexing, in
accordance with the Subsequent Protocol Identifier (SPI) in ISO/IEC
TR 9577 [5]. This field contains a one octet Network Layer Protocol
Identifier (NLPID), which identifies the encapsulation in use over
the X.25 virtual circuit. The CUD field MAY contain more than one
octet of information.

The PPP encapsulation MUST be indicated by the PPP NLPID value (CF
hex). Any subsequent octet in this CUD is extraneous and MUST be
ignored.

Multipoint networks (or multicast groups) MUST refuse calls which
indicate the PPP NLPID in the CUD.

The accidental connection of a link to feed a multipoint network (or
multicast group) SHOULD result in a misconfiguration indication.
This can be detected by multiple responses to the LCP Configure-
Request with the same Identifier, coming from different framing
addresses. Some implementations might be physically unable to either
log or report such information.

Conformance with this specification requires that the PPP NLPID (CF)
be supported. In addition, conformance with [4] requires that the IP
NLPID (CC) be supported, and does not require that other NLPID values
be supported, such as Zero (00), SNAP (80), CLNP (81) or ES-IS (82).

When IP address negotiation and/or VJ header compression are desired,
the PPP call setup SHOULD be attempted first. If the PPP call setup
fails, the normal IP call setup MUST be used.

The PPP NLPID value SHOULD NOT be used to demultiplex circuits which
use the Zero NLPID in call setup, as described in [4]. When such a
circuit exists concurrently with PPP encapsulated circuits, only
network layer traffic which has not been negotiated by the associated
NCP is sent over the Zero NLPID circuit.

Rationale:

Using call setup to determine if PPP is supported should be

inexpensive, when users aren't charged for failed calls.

Using the Zero NLPID call together with PPP could be expensive,
when users are charged per packet or for connect time, due to the
probing of PPP configuration packets at each call.

PPP configuration provides a direct indication of the availability
of service, and on that basis is preferred over the Zero NLPID
technique, which can result in "black-holes".

5. Configuration Details

The following Configuration Options are recommended:

Magic Number
Protocol Field Compression

The standard LCP configuration defaults apply to X.25 links, except
MRU.

To ensure interoperability with existing X.25 implementations, the
initial Maximum-Receive-Unit (MRU) is 1600 octets [4]. This only
affects the minimum required buffer space available for receiving
packets, not the size of packets sent.

The typical network feeding the link is likely to have a MRU of
either 1500, or 2048 or greater. To avoid fragmentation, the
Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
exceed 1500, unless a peer MRU of 2048 or greater is specifically
negotiated.

The X.25 packet size is not directly related to the MRU. Instead,
Protocol Data Units (PDUs) are sent as X.25 "complete packet
sequences". That is, PDUs begin on X.25 data packet boundaries and
the M bit ("more data") is used to fragment PDUs that are larger than
one X.25 data packet in length.

Security Considerations

Implementations MUST NOT consider PPP authentication on call setup
for one circuit between two systems to apply to concurrent call setup
for other circuits between those same two systems. This results in
possible security lapses due to over-reliance on the integrity and
security of switching systems and administrations. An insertion
attack might be undetected. An attacker which is able to spoof the
same calling identity might be able to avoid link authentication.

References

[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
1548, December 1993.

[2] CCITT Recommendation X.25, "Interface Between Data Terminal
Equipment (DTE) and Data Circuit Terminating Equipment (DCE)
for Terminals Operating in the Packet Mode on Public Data
Networks", Vol. VIII, Fascicle VIII.2, Rec. X.25.

[3] Simpson, W., Editor, "PPP in HDLC Framing", RFC1549, December
1993.

[4] Malis, A., Robinson, D., and R. Ullmann, "Multiprotocol
Interconnect on X.25 and ISDN in the Packet Mode", RFC1356,
August 1992.

[5] ISO/IEC TR 9577, "Information technology - Telecommunications
and Information exchange between systems - Protocol
Identification in the network layer", 1990 (E) 1990-10-15.

Acknowledgments

This design was inspired by the paper "Parameter Negotiation for the
Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
University of California, Berkeley, 1992, unpublished.

本篇文章来源于 中国协议分析网|www.cnpaf.net 原文链接：http://www.cnpaf.net/Class/Rfcen/200502/2641.html

---

通信人家园 (https://www.txrjy.com/)

Powered by C114