📄 rfc2458.txt
字号:
sessions that result.
This contrasts with the situation in the PSTN. There, the end systems
are configured as shown in Figure 2. The end systems tend to be
specific to a particular type of traffic, so that, for example, the
majority of terminals are dedicated to carrying speech traffic
(telephones) or to carrying facsimile data (fax machines). The
terminals all connect to Central Offices (COs) via access lines, and
these COs are interconnected into a network.
/--\
()/\()__
/__\ \ .................................
\ ! ! ! /--\
__ \ [-!-] [-!-] ! ()/\()
\ \ \__[CO ]=========[CO ]==\\ ! ___/__\
[Fax]________[---] [---] \\ [-!-] / __
\\=======[CO ]____/ \ \
[---]________[Fax]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
Figure 2
Lu, et. al. Informational [Page 6]
RFC 2458 Pre-PINT Implementations November 1998
Communications between the terminals are all "circuit switched", so a
dedicated synchronous data path (or circuit) needs to be placed
between the end terminals for carrying all communications. Arranging
for such a circuit to be made or removed (cleared) is the
responsibility of the Central Offices in the network. A user makes a
request via his or her terminal, and this request is passed on to the
"local" Central Office. The relationship between the terminals and
the local Central Offices to which they are connected is strictly
Client/Server.
The COs are interconnected using two different types of connections.
One of these is called a trunk connection (shown as a double line in
the above figure) and is used to carry the data traffic generated by
the terminals. The other connection acts as part of a separate
network (and is shown as a dotted line in the above figure). This is
the signaling network, and is used by the Central Offices to request
a connection to be made between themselves and the destination of the
required circuit. This will be carried across the trunk link to the
"next" Central Office in the path. The path, once in place through
the PSTN, always takes the same route. This contrasts with the
Internet, where the underlying datagram nature of the infrastructure
means that data packets are carried over different routes, depending
on the combined traffic flows through the network at the time.
The call set up process can be viewed as having two parts: one in
which a request for connection is made, and the other in which the
circuit is made across the PSTN and call data flows between the
communicating parties. This is shown in the next pair of figures (3a
and 3b).
/--\
() ()
--____
/++\ \
/----\ \
A \ [-!-]
\->[CO ]
[---]
Time = 13:55
Figure 3a
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
Lu, et. al. Informational [Page 7]
RFC 2458 Pre-PINT Implementations November 1998
/--\
() ()
-- .................................
/ \<--- ^ ! ! /--\
/----\ \ ! v ! () ()
A' \ [-!-] [-!-] ! --
\__[CO ]=========[CO ]==\\ v ->-/ \
[---] [---] \\ [-!-] / /----\
\\=======[CO ]____/ B'
Time = 14:00 [---]
Figure 3b
Figure 3 shows a particular kind of service that can be provided;
call booking. With this service, a request is sent for a connection
to be made between the A and B telephones at a specified time. The
telephone is then replaced (the request phase is terminated). At the
specified time, the CO will make a connection across the network in
the normal way, but will, first, ring the "local" or A' telephone to
inform the user that his or her call is now about to be made.
For more complex services, the requesting telephone is often
connected via its "local" CO to a Service Node (SN), where the user
can be played prompts and can specify the parameters of his or her
request in a more flexible manner. This is shown below, in Figures
4a and 4b. For more details of the operation of the Service Node (and
other Intelligent Network units), see the Appendix.
When the SN is involved in the request and in the call setup process,
it appears, to the CO, to be another PSTN terminal. As such, the
initial request is routed to the Service Node, which, as an end
system, then makes two independent calls "out" to A' and B'.
/--\ [---]
() () [SN ]
--___ [|--]
/++\ \ |
/----\ \ |
\ |
A \ [|-!]
\->[CO ]
[---]
Time = 13:55
Figure 4a
Lu, et. al. Informational [Page 8]
RFC 2458 Pre-PINT Implementations November 1998
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
SN Service Node
/--\ [---]
() () [SN ]
-- [|--] /--\
/ \<-- | ............................... () ()
/----\ \ | ^ ! ! --
\ | / v v / \
A' \ [|-!] [-!-] [-!-] ->-/----\
\--[CO ] [CO ] [CO ] /
[---] [---] [---]___/ B'
Time = 14:00
Figure 4b
Note that in both cases as shown in Figures 3 and 4 a similar service
can be provided in which the B' telephone is replaced by an
Intelligent Peripheral (or an Special Resource Functional entity
within a Service Node), playing an announcement. This allows a "wake
up" call to be requested, with the Intelligent Peripheral or Service
Node Special Resource playing a suitable message to telephone A' at
the specified time. Again, for more details of the operation of the
Special Resources (and other Intelligent Network units), see the
Appendix.
4.2 Pre-PINT Systems
Although the pre-PINT systems reported here (i.e., those developed by
AT&T, Lucent, Siemens and Nortel) vary in the details of their
operation, they exhibit similarities in the architecture. This
section highlights the common features. Specific descriptions of
these systems will follow.
All of the systems can be seen as being quite similar to that shown
in the following diagram. In each case, the service is separated into
two parts; one for the request and another for execution of the
service. Figure 5 summarizes the process.
Lu, et. al. Informational [Page 9]
RFC 2458 Pre-PINT Implementations November 1998
_____
__ _____/ \_____
[__] / \
[-++-]-.-.>.-. Internet .-.-
\_____ _______/ .
\___/ v
[----] .
[PINT]-.-
[----]
%
v
[---]
[SN ]
[|--]
Figure 5a
Key: CO Central Office (Telephone Exchange)
SN Service Node
PINT PSTN/Internet Gateway
.-.-. Internet Access Link
%%% Gateway/Service Node Link
___ PSTN Access Lines
=== PSTN Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
_____
__ _____/ \_____
[__] / \
[----]-.-.-.-. Internet .-.-
\_____ _______/ .
\___/ |
[----] .
[PINT]-.-
[-%--]
%
%
/--\ [-%-]
() () [SN ]
-- [|--] /--\
/ \<-- | .................... () ()
/----\ \ | ^ ! ! --
\ | / v v / \
A' \ [|-!] [-!-] [-!-] ->-/----\
\--[CO ]=======[CO ]======[CO ] /
[---] [---] [---]__/ B'
Figure 5b
Lu, et. al. Informational [Page 10]
RFC 2458 Pre-PINT Implementations November 1998
Comparing Figure 4a with Figure 5a, the differences lie in the way
that the information specifying the request is delivered to the
Service Node. In the PSTN/IN method shown in the earlier diagram, the
user connects to the SN from the telephone labeled A, with the
connection being routed via the CO. In the latter case, the request
is delivered from an Internet node, via the PINT gateway, and thence
to the Service Node over a "private" link. The effect is identical,
in that the request for service is specified (although the actual
parameters used to specify the service required may differ somewhat).
The figures depicting the respective service execution phases
(Figures 4b and 5b) show that the operation, from the IN/PSTN
perspective, is again identical. The Service Node appears to initiate
two independent calls "out" to telephones A' and B'.
The alternative systems developed by AT&T and by Nortel allow another
option to be used in which the PINT Gateway does not have to connect
to the PSTN via a Service Node (or other Intelligent Network
component), but can instead connect directly to Central Offices that
support the actions requested by the gateway. In these alternatives,
the commands are couched at a "lower level", specifying the call
states required for the intended service connection rather than the
service identifier and the addresses involved (leaving the
Intelligent Network components to coordinate the details of the
service call on the gateway's behalf). In this way the vocabulary of
the commands is closer to that used to control Central Offices. The
difference really lies in the language used for the services
specification, and all systems can use the overall architecture
depicted in Figure 5; the only question remains whether the
Intelligent Network components are actually needed in these other
approaches.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -