RFC 4129 - Digital Private Network Signaling System (DPNSS)/(2)

时间:2006-11-01 来源: 作者: 点击:
-----------SABMR(1)-----------EstReq(Ind=0) -----------SABMR(2) -----------SABMR(3) ............. -----------SABMR(N) IneachDLCeither UAisreceivedor NT1/NT2isexpired EstCfm-----------(StatusofDLCs (I
  
              <----------- SABMR(1)    <----------- Est Req(Ind=0)
              <----------- SABMR(2)
              <----------- SABMR(3)
             .............
              <----------- SABMR(N)
              In each DLC either
              UA is received or
              NT1/NT2 is expired

                                 Est Cfm -----------> (Status of DLCs
                                 (Ind=0)               are not updated)
                                         <----------- Status Req
                               Status cfm ----------> (Mark DLC status
                                                       based on
                                                       status bits)

   If one of more DLCs remains out-of-service after this procedure
   (e.g., due to layer 2 management), the MGC can either retry this DLC
   with an Est Req(Ind=1) indicating the specific DLC or with an

   Est Req(Ind=0) and the SG will retry the appropriate DLC that is
   out-of-service.

5.3.  Information Transfer on a DLC

            PBX                     SG                        MGC
                 <----------- UI(C)            <----------- Data Req
            UI(R)----------->         Data Ind ----------->

5.4.  Link Takedown (Single DLC)

            PBX                     SG                        MGC
                (For DPNSS, mark DLC as OOS)   <----------- Rel Req
                (For DASSII, mark DLC as RA)              (RELEASE_MGMT,
                                                            Ind=1)
                                      Rel Cfm  ---------->
                                      (Ind=1)

5.5.  Link Takedown (All DLCs)

            PBX                     SG                        MGC
                (For DPNSS, mark all DLCs as OOS) <-------- Rel Req
                (For DASSII, mark DLC as RA)              (RELEASE_MGMT,
                                                            Ind=0)
                                        Rel Cfm  ---------->
                                        (Ind=0)

5.6.  Getting Link Status

            PBX                     SG                        MGC
                                           <-----------  Stat Req
                                  Stat Cfm -----------> (Mark DLC status
                                                         based on
                                                         status bits)

5.7.  Error Conditions

            PBX                     SG                        MGC
                              Invalid Message <-----------Est/Rel/Data/-
                                                           Stat Req
                                 Error Ind    ----------->
                                (Error Code)

6.  Security Considerations

   The security considerations for the ISDN User Adaptation Protocol
   (IUAP) [1] (Section 6) and the security considerations for SIGTRAN
   Protocols document [4] apply to this document as well.

7.  References

7.1.  Normative References

   [1]  Morneault, K., Rengasami, S., Kalla, M., and G. Sidebottom,
        "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001.

   [2] Ofcom/NICC ND1301:2001/03, DPNSS [188], Digital Private
        Signalling System No 1 (DPNSS 1) (Formerly BTNR 188).

   [3]  BTNR (British Telecom Network Requirements) 190 Issue 2 Digital
        Access Signaling System No 2.

   [4]  Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security
        Considerations for Signaling Transport (SIGTRAN) Protocols", RFC
        3788, June 2004.

   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

8.  Acknowledgements

   The authors would like to thank Shashi Kumar and Venkatesh Seshasayee
   of Wipro Technologies for their useful suggestions and comments.

Authors’ Addresses

   All correspondence regarding this document should be sent to the
   following addresses:

   Ranjith Mukundan
   Wipro Technologies
   72, Electronics City
   Hosur Main Road
   Bangalore 560100
   India

   Phone: +91-80-51195893
   EMail: ranjith.mukundan@wipro.com

   Ken Morneault
   Cisco Systems Inc.
   13615 Dulles Technology Drive
   Herndon, VA. 20171
   USA

   Phone: +1-703-484-3323
   EMail: kmorneau@cisco.com

   Narsimuloo Mangalpally
   Nortel Networks
   250 Sidney Street
   Belleville, Ontario K8P 3Z3
   Canada

   Phone: +1-613-967-5034
   EMail: narsim@nortelnetworks.com

Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容