GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4129

Network Working Group R. Mukundan Request for Comments: 4129 Wipro Technologies Category: Standards Track K. Morneault

                                                         Cisco Systems
                                                        N. Mangalpally
                                                       Nortel Networks
                                                           August 2005
         Digital Private Network Signaling System (DPNSS)/
             Digital Access Signaling System 2 (DASS 2)
                   Extensions to the IUA Protocol

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 This document defines a mechanism for backhauling Digital Private
 Network Signaling System 1 (DPNSS 1) and Digital Access Signaling
 System 2 (DASS 2) messages over IP by extending the ISDN User
 Adaptation (IUA) Layer Protocol defined in RFC 3057.  DPNSS 1,
 specified in ND1301:2001/03 (formerly BTNR 188), is used to
 interconnect Private Branch Exchanges (PBX) in a private network.
 DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN.
 This document aims to become an Appendix to IUA and to be the base
 for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation.

Mukundan, et al. Standards Track [Page 1] RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005

Table of Contents

 1.  Introduction .................................................  2
     1.1.  Scope ..................................................  2
     1.2.  Terminology ............................................  3
     1.3.  DPNSS Overview .........................................  4
     1.4.  Proposed DPNSS Backhaul Architecture ...................  5
 2.  Changes from IUA .............................................  5
     2.1.  New Message Class for DUA ..............................  5
     2.2.  Message Header .........................................  6
     2.3.  Unit Data Message ......................................  7
     2.4.  DLC Status Message .....................................  7
     2.5.  Management (MGMT) Messages .............................  9
 3.  IANA Considerations .......................................... 10
 4.  Use of SCTP Payload Protocol ID .............................. 10
 5.  Message Sequence in DUA ...................................... 11
     5.1.  Resetting of single DLC ................................ 11
     5.2.  Resetting all DLCs in a Link ........................... 11
     5.3.  Information Transfer on a DLC .......................... 12
     5.4.  Link Takedown (Single DLC) ............................. 12
     5.5.  Link Takedown (All DLCs) ............................... 12
     5.6.  Getting Link Status .................................... 12
     5.7.  Error Conditions ....................................... 12
 6.  Security Considerations ...................................... 13
 7.  References ................................................... 13
     7.1.  Normative References ................................... 13
 8.  Acknowledgements ............................................. 13

1. Introduction

 This document describes a method of implementing Digital Private
 Network Signaling System 1 (DPNSS 1) [2] (henceforth referred to as
 just DPNSS) and Digital Access Signaling System 2 (DASS 2)[3]
 backhaul messaging over IP using a modified version of the ISDN User
 Adaptation Protocol (IUAP) [1].  The DPNSS/DASS 2 User Adaptation
 (DUA) builds on top of IUA by defining the necessary extensions to
 IUA for a DPNSS/DASS2 implementation.

1.1. Scope

 There is a need for Switched Circuit Network (SCN) signaling protocol
 delivery from a DPNSS Signaling Gateway (SG) to a Media Gateway
 Controller (MGC).  The delivery mechanism should support the
 following protocols:
  1. DPNSS (Digital Private Network Signaling System) [2]
  2. DASS 2 (Digital Access Signaling System Number 2) [3]

Mukundan, et al. Standards Track [Page 2] RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005

 Unless specifically mentioned, the details in this document are
 applicable to both DPNSS and DASS 2.

1.2. Terminology

 Data channel (D-channel) - A 64 kbit/s time slot that functions as a
 common signaling channel on a 2048 kbits/s interface or a 1544
 kbits/s interface that is provisioned to carry DPNSS signaling.
 DPNSS channel - Time slots 1 to 15 and 17 to 31 on a 2048 kbits/s
 interface or Time slots 1 to 23 on a 1544 kbits/s interface are
 termed as DPNSS channels.  These are the traffic channels that carry
 voice or data traffic.
  1. DPNSS supports 60 Channels (30 Real and 30 Virtual)
  2. DASS2 supports 30 Channels (All Real)
 Data Link Connection(DLC) - A DLC is the level 2 process that
 controls the transfer of level 3 messages on behalf of one DPNSS
 channel.  A DLC uniquely identifies one DPNSS channel.
  1. DPNSS supports 60 DLCs (30 Real and 30 Virtual)
  2. DASSII supports 30 DLCs (All Real)
 DPNSS Link -  A logical collection of the D-channel and the
 associated DPNSS channels in a 2048 kbits/s interface or a 1544
 kbits/s interface is called a "DPNSS Link".
 Real channel - A signalling channel with an associated traffic
 channel (TS).
 Virtual channel - A signalling channel with no associated traffic
 channel.
 NT1 - The DPNSS minimum retransmission period.
 NT2 - The DPNSS minimum post retransmission acknowledgement delay.
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [5].

Mukundan, et al. Standards Track [Page 3] RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005

1.3. DPNSS Overview

 DPNSS is an industry standard interface (ref. ND1301:2001/03) [2],
 which is defined between a PBX and an Access Network (AN).  DPNSS
 extends facilities that are normally only available between
 extensions on a single PBX to all extensions on PBXs that are
 connected in a private network.  DPNSS was originally derived from
 BT's Digital Access Signaling System I (DASS I), and was enhanced
 where necessary to meet the private network requirements.  Some of
 these enhancements were incorporated in DASS 2 [3].  DPNSS uses a
 2048 kbits/s or 1544 kbits/s Digital Transmission System Interface,
 as shown in Figure 1 below.
  1. ——— ———- o–o

| | 2048 kbits/s | |——- /\

          |        |--------------|        |         --
          |  PBX   | 1544 kbits/s |  AN    |
          |        |--------------|        |        o--o
          |        |              |        |-------  /\
          ----------              ----------         --
                          Figure 1
 Channel 16 is on a 2048 kbits/s (E1) interface and channel 24 is on a
 1544 kbits/s (T1) interface and is reserved for data communication
 between LE and AN.  The channels reserved for data are called "Data
 Channels" or "D-Channels."
 The D-Channels are the physical media used to exchange data between
 the DPNSS protocol peer entities.  A logical collection of the
 D-channel and the associated DPNSS channels is called a "DPNSS Link".

Mukundan, et al. Standards Track [Page 4] RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005

1.4. Proposed DPNSS Backhaul Architecture

  • * DPNSS IP *
  • PBX *—————* SG *————–* MGC *
  • * *
          +-----+                                  +-----+
          |DPNSS|              (NIF)               |DPNSS|
          | L3  |                                  | L3  |
          +-----+           +----------+           +-----+
          |     |           |     | DUA|           | DUA |
          |DPNSS|           |DPNSS+----+           +-----+
          | L2  |           | L2  |SCTP|           |SCTP |
          |     |           |     +----+           +-----+
          |     |           |     | IP +           | IP  |
          +-----+           +-----+----+           +-----+
       NIF  - Nodal Interworking function
       SCTP - Stream Control Transmission Protocol
       DUA  - DPNSS User Adaptation Layer Protocol

2. Changes from IUA

 This section outlines the differences between DUA and IUA.

2.1. New Message Class for DUA

 The DPNSS/DASS2 Layer 2 to Layer 3 primitives [2] [3] need to be
 identifiable from IUA boundary primitive transport messages and the
 boundary primitive transport messages of other IUA extensions (i.e.,
 V5 or GR-303).  Therefore, it is necessary to use a different message
 class parameter for DUA messages.
 For all DPNSS/DASS2 interface boundary primitives, a new Message
 Class is introduced:
       13     DPNSS/DASS2 Boundary Primitives Transport Messages
              (DPTM)
 Similar to IUA, other valid message classes for DUA are:
        0       Management (MGMT) Message
        3       ASP State Maintenance (ASPSM) Messages
        4       ASP Traffic Maintenance (ASPTM) Messages

Mukundan, et al. Standards Track [Page 5] RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005

2.2. Message Header

 The IUA Message Header [1] MUST be used with the DPTM messages, but
 the DLCI field in the DLCI parameter is formatted differently.
 Figure 2 below shows the IUA Message Header with integer-based
 Interface Identifier.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Tag (0x1)           |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                 Interface Identifier (integer)                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Tag (0x5)           |             Length=8          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            DLCI               |              Spare            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 2 IUA Message Header (integer-based Interface Identifier)
 In DUA, the DLCI field has a different format, in accordance with the
 ND1301:2001/03 (formerly BTNR 188) [2].
       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Reserved  |V|0|Channel No.|1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Reserved:  7 bits
 Should be set to all '0's and ignored by the receiver.
 V-bit:  1 bit
    The V-bit is used to determine if the message is for a particular
    DLC or if it is applicable for all the DLCs in the carrier.  The
    possible values of the V-bit are listed below:
          Value          Description
            0            Action is to be performed on all DLCs;
                         Channel number parameter is ignored.
            1            Action is to be performed on a single
                         DLC specified by channel number.

Mukundan, et al. Standards Track [Page 6] RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005

    This V-bit value is used only by the Establish and Release
    messages.  Data messages should ignore this value.  This indicator
    is provided so that a single command can be issued to establish or
    release all the DLCs in one DPNSS Link.
 For Channel Number (Channel No.), the valid values are 0 to 63 for
 DPNSS and 0 to 31 for DASS 2.  This is because DASS 2 does not
 support virtual DLCs and, hence, has only 32 DLCs.

2.3. Unit Data Message

 DPNSS layer 2 does not have a unit data primitive and, hence, the
 Unit Data Messages (Request, Indication) are invalid for a DUA
 application.  The Data Request and Indication messages (message types
 1 and 2, respectively) will be used with DUA.

2.4. DLC Status Message

 For DUA, a new message is necessary to carry the status of the DLCs.
 This message will be a Management message (i.e., its message class
 will be a value of 0 for Management).  The following message types
 will be used for these messages:
      5        DLC Status Request
      6        DLC Status Confirm
      7        DLC Status Indication
 The DLC Status messages are exchanged between DUA layer peers to
 request, confirm, and indicate the status of the DLCs.  The DLC
 Status messages contain the common message header, followed by IUA
 message header, as described in section 2.2.

Mukundan, et al. Standards Track [Page 7] RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005

 In addition, the DLC Status Confirm and Indication messages will
 contain the new parameter, called the DLC Status parameter.  This
 parameter will have the following format for an E1 interface:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Tag (0x12)           |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | NA| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | NA|D17|D18|D19|D20|D21|D22|D23|D24|D25|D26|D27|D28|D29|D30|D31|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|D42|D43|D44|D45|D46|D47|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | NA|D49|D50|D51|D52|D53|D54|D55|D56|D57|D58|D59|D60|D61|D62|D63|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 NA stands for Not Applicable.  D0 and D16 are not applicable for an
 E1 interface because timeslot 0 is used for E1 framing and
 synchronization bits and timeslot 16 is used for signaling.  For
 DPNSS, there would be a total of max 60 DLCs (30 real + 30 virtual)
 and in case of DASS2 there would be a total of 30 DLCs (no virtuals).
 This parameter will have the following format for a T1 interface:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Tag (0x12)           |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | D0| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |D16|D17|D18|D19|D20|D21|D22| NA|D24|D25|D26|D27|D28|D29|D30|D31|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|D42|D43|D44|D45|D46| NA|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 D23 is not applicable for a T1 interface because timeslot 23 is used
 for signaling.  For DPNSS, there would be a total of max 46 DLCs (23
 real + 23 virtual) and in case of DASS2 there would be a total of 23
 DLCs (no virtuals).

Mukundan, et al. Standards Track [Page 8] RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005

 The parameter carries the status of DLCs using two bits for each DLC.
 The possible values for the two bits are shown below:
       Value          Description
         00        Out Of Service
         01        Reset Attempted
         10        Reset Completed
         11        Information Transfer
 For DASS 2, the value 00 (Out Of Service) is invalid because the DASS
 2 DLC does not have this state.  In addition, the Idle state is a
 transient state local to the DLC, therefore, a value is not allocated
 for it.
 For DASS 2, there are no virtual DLCs and, hence, information about
 only 32 DLCs need to be carried.  Therefore, the status message will
 have a length of 12 for a DASS 2 DLC Status message.

2.5. Management (MGMT) Messages

 Only the Notify and Error messages are valid for DUA.  The TEI Status
 messages are not used.

2.5.1. Error Message

 The ERR message is sent when an invalid value or unrecognized message
 is found in an incoming message.
 The Error Code parameter indicates the reason for the Error Message.
 These are the supported values in IUA.
   Invalid Version                               0x01
   Invalid Interface Identifier                  0x02
   Unsupported Message Class                     0x03
   Unsupported Message Type                      0x04
   Unsupported Traffic Handling Mode             0x05
   Unexpected Message                            0x06
   Protocol Error                                0x07
   Unsupported Interface Identifier Type         0x08
   Invalid Stream Identifier                     0x09
   Unassigned TEI                                0x0a
   Unrecognized SAPI                             0x0b
   Invalid TEI, SAPI combination                 0x0c
   Refused - Management Blocking                 0x0d
   ASP Identifier Required                       0x0e
   Invalid ASP Identifier                        0x0f

Mukundan, et al. Standards Track [Page 9] RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005

 In DUA, the error codes 0x0a, 0x0b, and 0x0c are invalid, as they are
 specific to ISDN.
 The following additional error codes are supported in DUA:
      Channel Number out of range                   0x1c
      Channel Number not configured                 0x1d
 The "Channel Number out of range" error is sent if a message is
 received with a channel number greater than 63 for DPNSS or 31 for
 DASS 2.
 The "Channel Number not configured" error is sent if a message is
 received with a channel number that is not configured.

3. IANA Considerations

 IANA has assigned a DUA value for the SCTP Payload Protocol
 Identifier field that is used in SCTP Payload Data chunks.  The
 following value for the SCTP Payload Protocol Identifier field SHOULD
 be used for DUA:
       SCTP Payload Protocol ID = "10"

4. Use of SCTP Payload Protocol ID

 As an option, the IUA value for SCTP Payload Protocol ID MAY also be
 used for DUA, for instance, if one wanted to backhaul ISDN and DPNSS
 over the same SCTP association.  However, use of separate SCTP
 Payload Protocol IDs (10 for DUA and 1 for IUA) is recommended as the
 primary option, even in scenarios where ISDN and DPNSS are backhauled
 over the same SCTP association.
 SCTP Payload Protocol ID of "10" SHOULD be used for DUA if only DPNSS
 is backhauled over an SCTP association (i.e., in scenarios where
 simultaneous backhauling of ISDN and DPNSS over the same association
 is NOT required).
 The SCTP Payload Protocol Identifier is included in each SCTP Data
 chunk, to indicate which protocol the SCTP is carrying.  This Payload
 Protocol Identifier is not directly used by SCTP but MAY be used by
 certain network entities to identify the type of information being
 carried in a Data chunk.

Mukundan, et al. Standards Track [Page 10] RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005

5. Message Sequence in DUA

 An example of the message flows for establishing a data link on a
 signaling channel, passing PDUs and releasing a data link on a DPNSS
 channel is shown below.  An active association between MGC and SG is
 established prior to the following message flows.

5.1. Resetting of single DLC

    i)  Successful
     PBX                     SG                        MGC
         <----------- SABMR          <----------- Est Req(Ind=1)
     UA   ----------->       Est Cfm -----------> (DLC in RC State)
                              Ind=1)
    ii) Unsuccessful(Link Failure)
       PBX                     SG                        MGC
         <----------- SABMR         <----------- Est Req(Ind=1)
         Retransmissions over
         NT1 and NT2 expired
                             Rel Ind -----------> (DLC in RA state)
                            (RELEASE_OTHER,Ind=1)

5.2. Resetting all DLCs in a Link

       PBX                     SG                    MGC
            <----------- 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

Mukundan, et al. Standards Track [Page 11] RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005

 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)

Mukundan, et al. Standards Track [Page 12] RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005

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.

Mukundan, et al. Standards Track [Page 13] RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005

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

Mukundan, et al. Standards Track [Page 14] RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005

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.

Mukundan, et al. Standards Track [Page 15]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4129.txt · Last modified: 2005/09/29 19:28 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki