rfc2719.txt

RFC 的详细文档！

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: [e-mail]


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

   EMail: [e-mail]


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

   EMail: [e-mail]





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


   Lode Coene
   Siemens Atea
   Atealaan 34
   Herentals, Belgium

   EMail: [e-mail]


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

   EMail: [e-mail]


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

   EMail: [e-mail]


   Imre Juhasz
   Telia
   Sweden

   EMail: [e-mail]


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

   EMail: [e-mail]


   HannsJuergen Schwarzbauer
   SIEMENS AG
   Hofmannstr. 51
   81359 Munich,  Germany

   EMail: [e-mail]







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]