rfc2719.txt

中、英文RFC文档大全打包下载完全版 .


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]