File: rfc2719.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1347 lines) | stat: -rw-r--r-- 48,646 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347






Network Working Group                                              L. Ong
Request for Comments: 2719                                Nortel Networks
Category: Informational                                         I. Rytina
                                                                M. Garcia
                                                                 Ericsson
                                                          H. Schwarzbauer
                                                                 L. Coene
                                                                  Siemens
                                                                   H. Lin
                                                                Telcordia
                                                                I. Juhasz
                                                                    Telia
                                                              M. Holdrege
                                                                   Lucent
                                                                 C. Sharp
                                                            Cisco Systems
                                                             October 1999


             Framework Architecture for Signaling Transport

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document defines an architecture framework and functional
   requirements for transport of signaling information over IP.  The
   framework describes relationships between functional and physical
   entities exchanging signaling information, such as Signaling Gateways
   and Media Gateway Controllers.  It identifies interfaces where
   signaling transport may be used and the functional and performance
   requirements that apply from existing Switched Circuit Network (SCN)
   signaling protocols.










Ong, et al.                  Informational                      [Page 1]

RFC 2719     Framework Architecture for Signaling Transport October 1999


Table of Contents

   1. Introduction..................................................2
   1.1 Overview.....................................................2
   1.2 Terminology..................................................3
   1.3  Scope.......................................................5
   2.  Signaling Transport Architecture.............................5
   2.1  Gateway Component Functions.................................5
   2.2  SS7 Interworking for Connection Control.....................6
   2.3  ISDN Interworking for Connection Control....................8
   2.4  Architecture for Database Access............................9
   3. Protocol Architecture........................................10
   3.1 Signaling Transport Components..............................10
   3.2 SS7 access for Media Gateway Control........................11
   3.3 Q.931 Access to MGC.........................................12
   3.4 SS7 Access to IP/SCP........................................12
   3.5 SG to SG....................................................14
   4. Functional Requirements......................................15
   4.1 Transport of SCN Signaling Protocols........................15
   4.2 Performance of SCN Signaling Protocols......................17
   4.2.1 SS7 MTP Requirements......................................17
   4.2.2 SS7 MTP Level 3 Requirements..............................17
   4.2.3 SS7 User Part Requirements................................18
   4.2.4 ISDN Signaling Requirements...............................18
   5. Management...................................................19
   6. Security Considerations......................................19
   6.1 Security Requirements.......................................19
   6.2 Security Mechanisms Currently Available in IP Networks......20
   7. Abbreviations................................................21
   8. Acknowledgements.............................................21
   9. References...................................................21
   Authors' Addresses..............................................22
   Full Copyright Statement........................................24

1. Introduction

1.1 Overview

   This document defines an architecture framework for transport of
   message-based signaling protocols over IP networks.  The scope of
   this work includes definition of encapsulation methods, end-to-end
   protocol mechanisms and use of existing IP capabilities to support
   the functional and performance requirements for signaling transport.

   The framework portion describes the relationships between functional
   and physical entities used in signaling transport, including the
   framework for control of Media Gateways, and other scenarios where
   signaling transport may be required.



Ong, et al.                  Informational                      [Page 2]

RFC 2719     Framework Architecture for Signaling Transport October 1999


   The requirements portion describes functional and performance
   requirements for signaling transport such as flow control, in-
   sequence delivery and other functions that may be required for
   specific SCN signaling protocols.

1.2 Terminology

   The following are general terms are used in this document:

   Backhaul:

   Backhaul refers to the transport of signaling from the point of
   interface for the associated data stream (i.e., SG function in the
   MGU) back to the point of call processing (i.e., the MGCU), if this
   is not local.

   Signaling Transport (SIG):

   SIG refers to a protocol stack for transport of SCN signaling
   protocols over an IP network. It will support standard primitives to
   interface with an unmodified SCN signaling application being
   transported, and supplements a standard IP transport protocol
   underneath with functions designed to meet transport requirements for
   SCN signaling.

   Switched Circuit Network (SCN):

   The term SCN is used to refer to a network that carries traffic
   within channelized bearers of pre-defined sizes.  Examples include
   Public Switched Telephone Networks (PSTNs) and Public Land Mobile
   Networks (PLMNs).  Examples of signaling protocols used in SCN
   include Q.931, SS7 MTP Level 3 and SS7 Application/User parts.

   The following are terms for functional entities relating to signaling
   transport in a distributed gateway model.

   Media Gateway (MG):

   A MG terminates SCN media streams, packetizes the media data,, if it
   is not already packetized, and delivers packetized traffic  to the
   packet network.  It performs these functions in reverse order for
   media streams flowing from the packet network to the SCN.









Ong, et al.                  Informational                      [Page 3]

RFC 2719     Framework Architecture for Signaling Transport October 1999


   Media Gateway Controller (MGC):

   An MGC handles the registration and management of resources at the
   MG. The MGC may have the ability to authorize resource usage based on
   local policy.  For signaling transport purposes, the MGC serves as a
   possible termination and origination point for SCN application
   protocols, such as SS7 ISDN User Part and Q.931/DSS1.

   Signaling Gateway (SG):

   An SG is a signaling agent that receives/sends SCN native signaling
   at the edge of the IP network. The SG function may relay, translate
   or terminate SS7 signaling in an SS7-Internet Gateway. The SG
   function may also be co-resident with the MG function to process SCN
   signaling associated with line or trunk terminations controlled by
   the MG (e.g., signaling backhaul).

   The following are terms for physical entities relating to signaling
   transport in a distributed gateway model:

   Media Gateway Unit (MGU)

   An MG-Unit is a physical entity that contains the MG function.  It
   may contain other functions, esp. an SG function for handling
   facility-associated signaling.

   Media Gateway Control Unit (MGCU)

   An MGC-Unit is a physical entity containing the MGC function.

   Signaling Gateway Unit (SGU)

   An SG-Unit is a physical entity containing the SG function.

   Signaling End Point (SEP):

   This is a node in an SS7 network that originates or terminates
   signaling messages.  One example is a central office switch.

   Signal Transfer Point (STP):

   This is a node in an SS7 network that routes signaling messages based
   on their destination point code in the SS7 network.








Ong, et al.                  Informational                      [Page 4]

RFC 2719     Framework Architecture for Signaling Transport October 1999


1.3  Scope

   Signaling transport provides transparent transport of message-based
   signaling protocols over IP networks.   The scope of this work
   includes definition of encapsulation methods, end-to-end protocol
   mechanisms and use of IP capabilities to support the functional and
   performance requirements for signaling.

   Signaling transport shall be used for transporting SCN signaling
   between a Signaling Gateway Unit and Media Gateway Controller Unit.
   Signaling transport may also be used for transport of message-based
   signaling between a Media Gateway Unit and Media Gateway Controller
   Unit, between dispersed Media Gateway Controller Units, and between
   two Signaling Gateway Units connecting signaling endpoints or signal
   transfer points in the SCN.

   Signaling transport will be defined in such a way as to support
   encapsulation and carriage of a variety of SCN protocols.  It is
   defined in such a way as to be independent of any SCN protocol
   translation functions taking place at the endpoints of the signaling
   transport, since its function is limited to the transport of the SCN
   protocol.

   Since the function being provided is transparent transport, the
   following areas are considered outside the scope of the signaling
   transport work:

   -  definition of the SCN protocols themselves.
   -  signaling interworking such as conversion from Channel Associated
      Signaling (CAS) to message signaling protocols.
   -  specification of the functions taking place within the SGU or MGU
   -  in particular, this work does not address whether the SGU provides
      mediation/interworking, as this is transparent to the transport
      function.
   -  similarly, some management and addressing functions taking place
      within the SGU or MGU are also considered out of scope, such as
      determination of the destination IP address for signaling, or
      specific procedures for assessing the performance of the transport
      session (i.e., testing and proving functions).

2.  Signaling Transport Architecture

2.1  Gateway Component Functions

   Figure 1 defines a commonly defined functional model that separates
   out the functions of SG, MGC and MG.  This model may be implemented
   in a number of ways, with functions implemented in separate devices
   or combined in single physical units.



Ong, et al.                  Informational                      [Page 5]

RFC 2719     Framework Architecture for Signaling Transport October 1999


   Where physical separation exists between functional entities,
   Signaling Transport can be applied to ensure that SCN signaling
   information is transported between entities with the required
   functionality and performance.

        +---------------+                      +--------------+
        |               |                      |              |
  SCN<-------->[SG]  <--+---------O------------+--> [SG]  <------> SCN
 signal |       |       |                      |     |        |   signal
        +-------|-------+                      +-----|--------+
       Signaling|gateway                    Signaling|gateway (opt)
                O                                    O
                |                                    |
        +-------|-------+                      +-----|--------+
        |       |       |                      |     |        |
        |      [MGC] <--+--------O-------------+--> [MGC]     |
        |       |       |                      |     |        |
        |       |       |                      |     |        |
        +-------|-------+                      +-----|--------+
        Gateway | controller                 Gateway | controller (opt)
                O                                    O
                |                                    |
        +-------|-------+                      +-----|--------+
  Media |       |       |                      |     |        | Media
 <------+---->[MG]  <---+-----RTP stream-------+-> [MG]  <----+-------->
  stream|               |                      |              | stream
        +---------------+                      +--------------+
        Media gateway                           Media gateway


                   Figure 1: Sigtran Functional Model

   As discussed above, the interfaces pertaining to signaling transport
   include SG to MGC, SG to SG.  Signaling transport may potentially be
   applied to the MGC to MGC or MG to MGC interfaces as well, depending
   on requirements for transport of the associated signaling protocol.

2.2  SS7 Interworking for Connection Control

   Figure 2 below shows some example implementations of these functions
   in physical entities as used for interworking of SS7 and IP networks
   for Voice over IP, Voice over ATM, Network Access Servers, etc.  No
   recommendation is made as to functional distribution and many other
   examples are possible but are not shown to be concise.  The use of
   signaling transport is independent of the implementation.






Ong, et al.                  Informational                      [Page 6]

RFC 2719     Framework Architecture for Signaling Transport October 1999


   For interworking with SS7-controlled SCN networks, the SG terminates
   the SS7 link and transfers the signaling information to the MGC using
   signaling transport.  The MG terminates the interswitch trunk and
   controls the trunk based on the control signaling it receives from
   the MGC. As shown below in case (a), the SG, MGC and MG may be
   implemented in separate physical units, or as in case (b), the MGC
   and MG may be implemented in a single physical unit.

   In alternative case (c), a facility-associated SS7 link is terminated
   by the same device (i.e., the MGU) that terminates the interswitch
   trunk. In this case, the SG function is co-located with the MG
   function, as shown below, and signaling transport is used to
   "backhaul" control signaling to the MGCU.

   Note: SS7 links may also be terminated directly on the MGCU by
   cross-connecting at the physical level before or at the MGU.

            SGU
           +--------+
   SS7<------>[SG]  |
   (ISUP)  |   |    |
           +---|----+
            ST |                SGU                       MGCU
           +---|----+           +--------+                +--------+
           | [MGC]  |      SS7---->[SG]  |                | [MGC]  |
           |   |    |           |   |    |                |  | |   |
           +---|----+           +---|----+                +--|-|---+
          MGCU |                 ST |                        | |
               |                    |                     ST | |
     Media +---|----+     Media +---|----+                +--|-|---+
      ------->[MG]  |      ----->[MG/MGC]|      SS7 link-->[SG]|   |
    stream |        |    stream |        |       Media------> [MG] |
           +--------+           +--------+       stream   +--------+
           MGU                  MGU                       MGU

            (a)                     (b)                      (c)

   Notes: ST = Signaling Transport used to carry SCN signaling

                     Figure 2: Example Implementations











Ong, et al.                  Informational                      [Page 7]

RFC 2719     Framework Architecture for Signaling Transport October 1999


   In some implementations, the function of the SG may be divided into
   multiple physical entities to support scaling, signaling network
   management and addressing concerns.  Thus, Signaling Transport can be
   used between SGs as well as from SG to MGC. This is shown in Figure 3
   below.

               SGU                                 MGCU
             +---------+                         +---------+
             |         |          ST             |         |
             |  [SG2]------------------------------>[MGC]  |
             |   ^ ^   |                         |         |
             +---|-|---+                         +---------+
                 | |
                 | |             ST
               ST| +--------------------------------+
                 |                                  |
                 |                                  |
        SS7  +---|----------+             SS7  +----|---------+
   -----------> [SG1]       |        -----------> [SG1]       |
    media    |              |         media    |              |
   ------------------->[MG] |        ------------------->[MG] |
    stream   +--------------+         stream   +--------------+
              MGU                                MGU


                        Figure 3: Multiple SG Case

   In this configuration, there may be more than one MGU handling
   facility associated signaling (i.e. more than one containing it's own
   SG function), and only a single SGU. It will therefore be possible to
   transport one SS7 layer between SG1 and SG2, and another SS7 layer
   between SG2 and MGC. For example, SG1 could transport MTP3 to SG2,
   and SG2 could transport ISUP to MGC.

2.3  ISDN Interworking for Connection Control

   In ISDN access signaling, the signaling channel is carried along with
   data channels, so that the SG function for handling Q.931 signaling
   is co-located with the MG function for handling the data stream.
   Where Q.931 is then transported to the MGC for call processing,
   signaling transport would be used between the SG function and MGC.
   This is shown in Figure 3 below.









Ong, et al.                  Informational                      [Page 8]

RFC 2719     Framework Architecture for Signaling Transport October 1999


                             MGCU
                             +-------------+
                             |    [MGC]    |
                             |     | |     |
                             +-----|-|-----+
                                   | |
                                   | O device control
                                   | |
                          Q.931/ST O |
                                   | |
                             +-----|-|-----+
                             |     | |     |
                       Q.931---->[SG]|     |
                      signals|       |     |
                             |       |     |
                    Media---->[MG]   |
                    stream   |             |
                             +-------------+
                             MGU


                   Figure 4: Q.931 transport model

2.4  Architecture for Database Access

   Transaction Capabilities (TCAP) is the application part within SS7
   that is used for non-circuit-related signaling.

   TCAP signaling within IP networks may be used for cross-access
   between entities in the SS7 domain and the IP domain, such as, for
   example:

   -  access from an SS7 network to a Service Control Point (SCP) in IP.
   -  access from an SS7 network to an MGC.
   -  access from an MGC to an SS7 network element.
   -  access from an IP SCP to an SS7 network element.

   A basic functional model for TCAP over IP is shown in Figure 5.













Ong, et al.                  Informational                      [Page 9]

RFC 2719     Framework Architecture for Signaling Transport October 1999


                            +--------------+
                            | IP SCP       |
                            +--|----|------+
                               |    |
            SGU                |    |                SGU
           +--------------+    |    |    +--------------+
           |              |    |    |    |              |
   SS7<--------->[SG] ---------+    |    |     [SG]<---------> SS7
   (TCAP)  |      |       |         |    |      |       |
           +------|-------+         |    +------|-------+
                  |                 |           |
                  O    +------------+           O
          MGCU    |    |                        | MGCU
          +-------|----|--+               +-----|--------+
          |       |    |  |               |     |        |
          |      [MGC]    |               |    [MGC]     |
          |       |       |               |     |        |
          +-------|-------+               +-----|--------+
                  |                             |
          +-------|-------+               +-----|------+
    Media |       |       |               |     |      | Media
   <------+---->[MG]  <---+--RTP stream---+--> [MG]  <-+-------->
    stream|               |               |            | stream
          +---------------+               +------------+
          MGU                             MGU


                     Figure 5: TCAP Signaling over IP

3. Protocol Architecture

   This section provides a series of examples of protocol architecture
   for the use of Signaling Transport (SIG).

3.1 Signaling Transport Components

   Signaling Transport in the protocol architecture figures below is
   assumed to consist of three components (see Figure 6):

   1) an adaptation sub-layer that supports specific primitives, e.g.,
      management indications, required by a particular SCN signaling
      application protocol.
   2) a Common Signaling Transport Protocol that supports a common set
      of reliable transport functions for signaling transport.
   3) a standard, unmodified IP transport protocol.






Ong, et al.                  Informational                     [Page 10]

RFC 2719     Framework Architecture for Signaling Transport October 1999


                 +-- +--------------------------------+
                 |   |      SCN adaptation module     |
                 |   +--------------------------------+
                 |                  |
               S |   +--------------------------------+
               I |   | Common Signaling Transport     |
               G |   +--------------------------------+
                 |                  |
                 |   +--------------------------------+
                 |   |     standard IP transport      |
                 +-- +--------------------------------+


                Figure 6: Signaling Transport Components

3.2. SS7 access for Media Gateway Control

   This section provides a protocol architecture for signaling transport
   supporting SS7 access for Media Gateway Control.

          ******   SS7  ******* SS7  ******     IP     *******
          *SEP *--------* STP *------* SG *------------* MGC *
          ******        *******      ******            *******

          +----+                                       +-----+
          |ISUP|                                       | ISUP|
          +----+        +-----+      +---------+       +-----+
          |MTP |        |MTP  |      |MTP | SIG|       | SIG |
          |L1-3|        |L1-3 |      |L1-3+----+       +-----+
          |    |        |     |      |    | IP |       | IP  |
          +----+        +-----+      +---------+       +-----+


          STP - Signal Transfer Point    SEP - Signaling End Point
          SG - Signaling Gateway         SIG - Signaling Transport
          MGC - Media Gateway Controller


                      Figure 7: SS7 Access to MGC












Ong, et al.                  Informational                     [Page 11]

RFC 2719     Framework Architecture for Signaling Transport October 1999


3.3. Q.931 Access to MGC

   This section provides a protocol architecture for signaling transport
   supporting ISDN point-to-point access (Q.931) for Media Gateway
   Control.

            ******    ISDN      *********     IP     *******
            * EP *--------------* SG/MG *------------* MGC *
            ******              *********            *******

            +----+                                   +-----+
            |Q931|                                   | Q931|
            +----+              +---------+          +-----+
            |Q921|              |Q921| SIG|          | SIG |
            +    +              +    +----+          +-----+
            |    |              |    | IP |          | IP  |
            +----+              +---------+          +-----+

            MG/SG - Media Gateway with SG function for backhaul
            EP - ISDN End Point


                         Figure 8: ISDN Access

3.4. SS7 Access to IP/SCP

   This section provides a protocol architecture for database access,
   for example providing signaling between two IN nodes or two mobile
   network nodes. There are a number of scenarios for the protocol
   stacks and the functionality contained in the SIG, depending on the
   SS7 application.

   In the diagrams, SS7 Application Part (S7AP) is used for generality
   to cover all Application Parts (e.g. MAP, IS-41, INAP, etc).
   Depending on the protocol being transported, S7AP may or may not
   include TCAP. The interface to the SS7 layer below S7AP can be either
   the TC-user interface or the SCCP-user interface.

   Figure 9a shows the scenario where SCCP is the signaling protocol
   being transported between the SG and an IP Signaling Endpoint (ISEP),
   that is, an IP destination supporting some SS7 application protocols.










Ong, et al.                  Informational                     [Page 12]

RFC 2719     Framework Architecture for Signaling Transport October 1999


          ******   SS7  ******* SS7  ******     IP      *******
          *SEP *--------* STP *------* SG *-------------* ISEP*
          ******        *******      ******             *******

          +-----+                                       +-----+
          |S7AP |                                       |S7AP |
          +-----+                                       +-----+
          |SCCP |                                       |SCCP |
          +-----+        +-----+      +---------+       +-----+
          |MTP  |        |MTP  |      |MTP |SIG |       |SIG  |
          +     +        +     +      +    +----+       +-----+
          |     |        |     |      |    | IP |       |IP   |
          +-----+        +-----+      +---------+       +-----+


        Figure 9a: SS7 Access to IP node - SCCP being transported

   Figure 9b shows the scenario where S7AP is the signaling protocol
   being transported between SG and ISEP. Depending on the protocol
   being transported, S7AP may or may not include TCAP, which implies
   that SIG must be able to support both the TC-user and the SCCP-user
   interfaces.

          ******   SS7  ******* SS7  ******     IP      *******
          *SEP *--------* STP *------* SG *-------------* ISEP*
          ******        *******      ******             *******

          +-----+                                       +-----+
          |S7AP |                                       |S7AP |
          +-----+                     +----+----+       +-----+
          |SCCP |                     |SCCP|    |       |     |
          +-----+        +-----+      +----|SIG |       |SIG  |
          |MTP  |        |MTP  |      |MTP |    |       |     |
          +     +        +     +      +    +----+       +-----+
          |     |        |     |      |    |IP  |       |IP   |
          +-----+        +-----+      +---------+       +-----+


        Figure 9b: SS7 Access to IP node - S7AP being transported












Ong, et al.                  Informational                     [Page 13]

RFC 2719     Framework Architecture for Signaling Transport October 1999


3.5. SG to SG

   This section identifies a protocol architecture for support of
   signaling between two endpoints in an SCN signaling network, using
   signaling transport directly between two SGs.

   The following figure describes protocol architecture for a scenario
   with two SGs providing different levels of function for interworking
   of SS7 and IP. This corresponds to the scenario given in Figure 3.

   The SS7 User Part (S7UP) shown is an SS7 protocol using MTP directly
   for transport within the SS7 network, for example, ISUP.

   In this scenario, there are two different usage cases of SIG, one
   which transports MTP3 signaling, the other which transports ISUP
   signaling.

            ******  SS7  ******   IP     ******  IP   ******
            *SEP *-------* SG1*----------* SG2*-------*MGC *
            ******       ******          ******       ******

            +----+                                    +----+
            |S7UP|                                    |S7UP|
            +----+                     +----+----+    +----+
            |MTP3|                     |MTP3|    |    |    |
            +----+    +---------+      +----+ SIG|    |SIG |
            |MTP2|    |MTP2|SIG |      |SIG |    |    |    |
            +    +    +    +----+      +----+----+    +----+
            |    |    |    | IP |      |   IP    |    | IP |
            +----+    +----+----+      +----+----+    +----+

            S7UP - SS7 User Part

                      Figure 10: SG to SG Case 1

   The following figure describes a more generic use of SS7-IP
   interworking for transport of SS7 upper layer signaling across an IP
   network, where the endpoints are both SS7 SEPs.













Ong, et al.                  Informational                     [Page 14]

RFC 2719     Framework Architecture for Signaling Transport October 1999


            ******   SS7  ******    IP     ******  SS7   ******
            *SEP *--------* SG *-----------* SG *--------*SEP *
            ******        ******           ******        ******

            +----+                                       +-----+
            |S7UP|                                       | S7UP|
            +----+                                       +-----+
            |MTP3|                                       | MTP3|
            +----+        +---------+     +---------+    +-----+
            |MTP2|        |MTP2| SIG|     |SIG |MTP2|    | MTP2|
            +    +        +    +----+     +----+    +    +     +
            |    |        |    | IP |     | IP |    |    |     |
            +----+        +----+----+     +----+----+    +-----+

                      Figure 11: SG to SG Case 2

4. Functional Requirements

4.1 Transport of SCN Signaling Protocols

   Signaling transport provides for the transport of native SCN protocol
   messages over a packet switched network.

   Signaling transport shall:

   1) Transport of a variety of SCN protocol types, such as the
   application and user parts of SS7 (including MTP Level 3, ISUP, SCCP,
   TCAP, MAP, INAP, IS-41, etc.) and layer 3 of the DSS1/PSS1 protocols
   (i.e. Q.931 and QSIG).

   2) Provide a means to identify the particular SCN protocol being
   transported.

   3) Provide a common base protocol defining header formats, security
   extensions and procedures for signaling transport, and support
   extensions as necessary to add individual SCN protocols if and when
   required.

   4) In conjunction with the underlying network protocol (IP), provide
   the relevant functionality as defined by the appropriate SCN lower
   layer.

   Relevant functionality may include (according to the protocol being
   transported):

   -  flow control
   -  in sequence delivery of signaling messages within a control stream




Ong, et al.                  Informational                     [Page 15]

RFC 2719     Framework Architecture for Signaling Transport October 1999


   -  logical identification of the entities on which the signaling
      messages originate or terminate
   -  logical identification of the physical interface controlled by the
      signaling message
   -  error detection
   -  recovery from failure of components in the transit path
   -  retransmission and other error correcting methods
   -  detection of unavailability of peer entities.

   For example:

   -  if the native SCN protocol is ISUP or SCCP, the relevant
      functionality provided by MTP2/3 shall be provided.
   -  if the native SCN protocol is TCAP, the relevant functionality
      provided by SCCP connectionless classes and MTP 2/3 shall be
      supported.
   -  if the native SCN protocol is Q.931, the relevant functionality
      provided by Q.921 shall be supported.
   -  if the native SCN protocol is MTP3, the relevant functionality of
      MTP2 shall be supported.

   5) Support the ability to multiplex several higher layer SCN sessions
   on one underlying signaling transport session.  This allows, for
   example, several DSS1 D-Channel sessions to be carried in one
   signaling transport session.

   In general, in-sequence delivery is required for signaling messages
   within a single control stream, but is not necessarily required for
   messages that belong to different control streams.  The protocol
   should if possible take advantage of this property to avoid blocking
   delivery of messages in one control stream due to sequence error
   within another control stream.  The protocol should also allow the SG
   to send different control streams to different destination ports if
   desired.

   6) Be able to transport complete messages of greater length than the
   underlying SCN segmentation/reassembly limitations.  For example,
   signaling transport should not be constrained by the length
   limitations defined for SS7 lower layer protocol (e.g. 272 bytes in
   the case of narrowband SS7) but should be capable of carrying longer
   messages without requiring segmentation.

   7) Allow for a range of suitably robust security schemes to protect
   signaling information being carried across networks. For example,
   signaling transport shall be able to operate over proxyable sessions,
   and be able to be transported through firewalls.





Ong, et al.                  Informational                     [Page 16]

RFC 2719     Framework Architecture for Signaling Transport October 1999


   8) Provide for congestion avoidance on the Internet, by supporting
   appropriate controls on signaling traffic generation (including
   signaling generated in SCN) and reaction to network congestion.

4.2 Performance of SCN Signaling Protocols

   This section provides basic values regarding performance requirements
   of key SCN protocols to be transported. Currently only message-based
   SCN protocols are considered.  Failure to meet these requirements is
   likely to result in adverse and undesirable signaling and call
   behavior.

4.2.1 SS7 MTP requirements

   The performance requirements below have been specified for transport
   of MTP Level 3 network management messages. The requirements given
   here are only applicable if all MTP Level 3 messages are to be
   transported over the IP network.

   -  Message Delay
      -  MTP Level 3 peer-to-peer procedures require response within 500
         to 1200 ms.  This value includes round trip time and processing
         at the remote end.
         Failure to meet this limitation will result in the initiation
         of error procedures for specific timers, e.g., timer T4 of
         ITU-T Recommendation Q.704.

4.2.2 SS7 MTP Level 3 requirements

   The performance requirements below have been specified for transport
   of MTP Level 3 user part messages as part of ITU-T SS7
   Recommendations [SS7].

   -  Message Loss
      -  no more than 1 in 10E+7 messages will be lost due to transport
         failure

   -  Sequence Error
      -  no more than 1 in 10E+10 messages will be delivered out-of-
         sequence (including duplicated messages) due to transport
         failure

   -  Message Errors
      -  no more than 1 in 10E+10 messages will contain an error that is
         undetected by the transport protocol (requirement is 10E+9 for
         ANSI specifications)





Ong, et al.                  Informational                     [Page 17]

RFC 2719     Framework Architecture for Signaling Transport October 1999


   -  Availability
      -  availability of any signaling route set is 99.9998% or better,
         i.e., downtime 10 min/year or less.  A signaling route set is
         the complete set of allowed signaling paths from a given
         signaling point towards a specific destination.

   -  Message length (payload accepted from SS7 user parts)
      -  272 bytes for narrowband SS7, 4091 bytes for broadband SS7

4.2.3 SS7 User Part Requirements

   More detailed analysis of SS7 User Part Requirements can be found in
   [Lin].

      ISUP Message Delay - Protocol Timer Requirements

      -  one example of ISUP timer requirements is the Continuity Test
         procedure, which requires that a tone generated at the sending
         end be returned from the receiving end within 2 seconds of
         sending an IAM indicating continuity test.  This implies that
         one way signaling message transport, plus accompanying nodal
         functions need to be accomplished within 2 seconds.

      ISUP Message Delay - End-to-End Requirements

      -  the requirement for end-to-end call setup delay in ISUP is that
         an end-to-end response message be received within 20-30 seconds
         of the sending of the IAM.  Note: while this is the protocol
         guard timer value, users will generally expect faster response
         time.

      TCAP Requirements - Delay Requirements

      -  TCAP does not itself define a set of delay requirements.  Some
         work has been done [Lin2] to identify application-based delay
         requirements for TCAP applications.

4.2.4 ISDN Signaling Requirements

      Q.931 Message Delay

      -  round-trip delay should not exceed 4 seconds.  A Timer of this
         length is used for a number of procedures, esp.  RELASE/RELEASE
         COMPLETE and CONNECT/CONNECT ACK where excessive delay may
         result in management action on the channel, or release of a
         call being set up.  Note: while this value is indicated by
         protocol timer specifications, faster response time is normally
         expected by the user.



Ong, et al.                  Informational                     [Page 18]

RFC 2719     Framework Architecture for Signaling Transport October 1999


         -  12 sec. timer (T309) is used to maintain an active call in
         case of loss of the data link, pending re-establishment.  The
         related ETSI documents specify a maximum value of 4 seconds
         while ANSI specifications [T1.607] default to 90 seconds.

5. Management

   Operations, Administration & Management (OA&M) of IP networks or SCN
   networks is outside the scope of SIGTRAN. Examples of OA&M include
   legacy telephony management systems or IETF SNMP managers. OA&M
   implementors and users should be aware of the functional interactions
   of the SG, MGC and MG and the physical units they occupy.

6. Security Considerations

6.1 Security Requirements

   When SCN related signaling is transported over an IP network two
   possible network scenarios can be distinguished:

   -  Signaling transported only within an Intranet;
      Security measures are applied at the discretion of the network
      owner.

   -  Signaling transported, at least to some extent, in the public
      Internet;
      The public Internet should be regarded generally as an "insecure"
      network and usage of security measures is  required.

   Generally security comprises several aspects

   -  Authentication:
      It is required to ensure that the information is sent to/from a
      known and trusted partner.

   -  Integrity:
      It is required to ensure that the information hasn't been modified
      while in transit.

   -  Confidentiality:
      It might be sometimes required to ensure that the transported
      information is encrypted to avoid illegal use.

   -  Availability:
      It is required that the communicating endpoints remain in service
      for authorized use even if under attack.





Ong, et al.                  Informational                     [Page 19]

RFC 2719     Framework Architecture for Signaling Transport October 1999


6.2 Security Mechanisms Currently Available in IP Networks

   Several security mechanisms are currently available for use in IP
   networks.

   -  IPSEC ([RFC2401]):
      IPSEC provides security services at the IP layer that address the
      above mentioned requirements. It defines the two protocols AH and
      ESP respectively that essentially provide data integrity and data
      confidentiality services.

      The ESP mechanism can be used in two different modes:
      - Transport mode;
      - Tunnel mode.

   In Transport mode IPSEC protects the higher layer protocol data
   portion of an IP packet, while in Tunnel mode a complete IP packet is
   encapsulated in a secure IP tunnel.

   If the SIG embeds any IP addresses outside of the SA/DA in the IP
   header, passage through a NAT function will cause problems. The same
   is true for using IPsec in general, unless an IPsec ready RSIP
   function is used as described in RFC 2663 [NAT].

   The use of IPSEC does not hamper the use of TCP or UDP as the
   underlying basis of SIG.  If automated distribution of keys is
   required the IKE protocol ([RFC2409]) can be applied.

   -  SSL, TLS ([RFC2246]):
      SSL and TLS also provide appropriate security services but operate
      on top of TCP/IP only.

   It is not required to define new security mechanisms in SIG, as the
   use of currently available mechanisms is sufficient to provide the
   necessary security.  It is recommended that IPSEC or some equivalent
   method be used, especially when transporting SCN signaling over
   public Internet.














Ong, et al.                  Informational                     [Page 20]

RFC 2719     Framework Architecture for Signaling Transport October 1999


7. Abbreviations

   CAS   Channel-Associated Signaling
   DSS1  Digital Subscriber Signaling
   INAP  Intelligent Network Application Part
   ISEP  IP Signaling End Point
   ISUP  Signaling System 7 ISDN User Part
   MAP   Mobile Application Part
   MG    Media Gateway
   MGU   Media Gateway Unit
   MGC   Media Gateway Controller
   MGCU  Media Gateway Controller Unit
   MTP   Signaling System 7 Message Transfer Part
   PLMN  Public Land Mobile Network
   PSTN  Public Switched Telephone Network
   S7AP  SS7 Application Part
   S7UP  SS7 User Part
   SCCP  SS7 Signaling Connection Control Part
   SCN   Switched Circuit Network
   SEP   Signaling End Point
   SG    Signaling Gateway
   SIG   Signaling Transport protocol stack
   SS7   Signaling System No. 7
   TCAP  Signaling System 7 Transaction Capabilities Part

8. Acknowledgements

   The authors would like to thank K. Chong, I. Elliott, Ian Spiers, Al
   Varney, Goutam Shaw, C. Huitema, Mike McGrew and Greg Sidebottom for
   their valuable comments and suggestions.

9. References

   [NAT]        Srisuresh P. and M. Holdrege, "IP Network Address
                Translator (NAT) Terminology and Considerations", RFC
                2663, August 1999.

   [PSS1/QSIG]   ISO/IEC 11572 Ed. 2 (1997-06), "Information technology
                - Telecommunications and information exchange between
                systems - Private Integrated Services Network - Circuit
                mode bearer services - Inter-exchange signalling
                procedures and protocol"

   [Q.931/DSS1] ITU-T Recommendation Q.931, ISDN user-network interface
                layer 3 specification (5/98)

   [SS7]        ITU-T Recommendations Q.700-775, Signalling System No. 7




Ong, et al.                  Informational                     [Page 21]

RFC 2719     Framework Architecture for Signaling Transport October 1999


   [SS7 MTP]    ITU-T Recommendations Q.701-6, Message Transfer Part of
                SS7

   [T1.607]     ANSI T1.607-1998, Digital Subscriber Signaling System
                Number 1 (DSS1) - Layer 3 Signaling Specification for
                Circuit-Switched Bearer Services

   [Lin]        Lin, H., Seth, T., et al., "Performance Requirements for
                Signaling in Internet Telephony", Work in Progress.

   [Lin2]       Lin, H., et al., "Performance Requirements for TCAP
                Signaling in Internet Telephony", Work in Progress.

   [RFC2246]    Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
                RFC 2246, January 1999.

   [RFC2409]    Harkins, D. and C. Carrel, "The Internet Key Exchange
                (IKE)", RFC 2409, November 1998.

   [RFC2401]    Kent, S. and R. Atkinson, "Security Architecture for the
                Internet Protocol", RFC 2401, November 1998.

Authors' Addresses

   Lyndon Ong
   Nortel Networks
   4401 Great America Parkway
   Santa Clara, CA 95054, USA

   EMail: long@nortelnetworks.com


   Ian Rytina
   Ericsson Australia
   37/360 Elizabeth Street
   Melbourne, Victoria 3000, Australia

   EMail: ian.rytina@ericsson.com


   Matt Holdrege
   Lucent Technologies
   1701 Harbor Bay Parkway
   Alameda, CA 94502  USA

   EMail: holdrege@lucent.com





Ong, et al.                  Informational                     [Page 22]

RFC 2719     Framework Architecture for Signaling Transport October 1999


   Lode Coene
   Siemens Atea
   Atealaan 34
   Herentals, Belgium

   EMail: lode.coene@siemens.atea.be


   Miguel-Angel Garcia
   Ericsson Espana
   Retama 7
   28005 Madrid, Spain

   EMail: Miguel.A.Garcia@ericsson.com


   Chip Sharp
   Cisco Systems
   7025 Kit Creek Road
   Res Triangle Pk, NC 27709, USA

   EMail: chsharp@cisco.com


   Imre Juhasz
   Telia
   Sweden

   EMail: imre.i.juhasz@telia.se


   Haui-an Paul Lin
   Telcordia Technologies
   Piscataway, NJ, USA

   EMail: hlin@research.telcordia.com


   HannsJuergen Schwarzbauer
   SIEMENS AG
   Hofmannstr. 51
   81359 Munich,  Germany

   EMail: HannsJuergen.Schwarzbauer@icn.siemens.de







Ong, et al.                  Informational                     [Page 23]

RFC 2719     Framework Architecture for Signaling Transport October 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Ong, et al.                  Informational                     [Page 24]