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

Mukundanがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4129年のウィプロ技術カテゴリ: 規格は2005年8月にK.MorneaultシスコシステムズN.Mangalpallyノーテルネットワークを追跡します。

           Digital Private Network Signaling System (DPNSS)/
               Digital Access Signaling System 2 (DASS 2)
                     Extensions to the IUA Protocol

システム2(ダス2)拡大をIUAプロトコルに示すデジタル個人的なネットワークシグナリングシステム(DPNSS)/デジタルのアクセス

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(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.

このドキュメントは、IPの上でRFC3057で定義されたISDN User Adaptation(IUA)層のプロトコルを広げることによってDigital兵士のNetwork Signaling System1(DPNSS1)とDigital Access Signaling System2(ダス2)メッセージをbackhaulingするようにメカニズムを定義します。 ND1301: 2001/03(以前BTNR188)で指定されたDPNSS1は、私設のネットワークで兵士の支店Exchanges(PBX)とインタコネクトするのに使用されます。 BTNR190で指定されたダス2は、PBXsをPSTNに接続するのに使用されます。 このドキュメントはIUAへのAppendixになって、DPNSS1/ダス2User Adaptation(DUA)実装のためのベースであることを目指します。

Mukundan, et al.            Standards Track                     [Page 1]

RFC 4129      DPNSS/DASS 2 Extensions to the IUA Protocol    August 2005

Mukundan、他 IUAへの標準化過程[1ページ]RFC4129 2DPNSS/ダスExtensionsが2005年8月に議定書を作ります。

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. 序論… 2 1.1. 範囲… 2 1.2. 用語… 3 1.3. DPNSS概要… 4 1.4. DPNSS逆送アーキテクチャを提案します… 5 2. IUAからの変化… 5 2.1. DUAのための新しいメッセージのクラス… 5 2.2. メッセージヘッダー… 6 2.3. ユニットデータメッセージ… 7 2.4. DLCステータスメッセージ… 7 2.5. 管理(管理)メッセージ… 9 3. IANA問題… 10 4. SCTP有効搭載量Protocol IDの使用… 10 5. DUAのメッセージ系列… 11 5.1. 独身のDLCのリセット… 11 5.2. LinkのすべてのDLCsをリセットします… 11 5.3. DLCにおける情報転送… 12 5.4. 分解(独身のDLC)をリンクしてください… 12 5.5. 分解(すべてのDLCs)をリンクしてください… 12 5.6. リンク状態を得ます… 12 5.7. エラー条件… 12 6. セキュリティ問題… 13 7. 参照… 13 7.1. 標準の参照… 13 8. 承認… 13

1.  Introduction

1. 序論

   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.

このドキュメントはIPの上でDigital兵士のNetwork Signaling System1(DPNSS1)[2](今後は、まさしくDPNSSと呼ばれる)とDigital Access Signaling System2(ダス2)[3]が逆送メッセージングであるとISDN User Adaptationプロトコル(IUAP)[1]の変更されたバージョンを使用することで実装するメソッドを説明します。 DPNSS/ダス2User Adaptation(DUA)はDPNSS/DASS2実装のために必要な拡大をIUAと定義するのによるIUAの上に建てます。

1.1.  Scope

1.1. 範囲

   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:

DPNSS Signalingゲートウェイ(SG)からメディアゲートウェイController(MGC)までのSwitched Circuit Network(SCN)シグナリングプロトコル配送の必要があります。 排紙機構は以下のプロトコルをサポートするべきです:

      -  DPNSS (Digital Private Network Signaling System) [2]
      -  DASS 2 (Digital Access Signaling System Number 2) [3]

- DPNSS(デジタル個人的なネットワークシグナリングシステム)[2]--ダス2(デジタルアクセスシグナリングシステムNo.2)[3]

Mukundan, et al.            Standards Track                     [Page 2]

RFC 4129      DPNSS/DASS 2 Extensions to the IUA Protocol    August 2005

Mukundan、他 IUAへの標準化過程[2ページ]RFC4129 2DPNSS/ダスExtensionsが2005年8月に議定書を作ります。

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

明確に言及されない場合、詳細は本書ではDPNSSとダス2の両方に適切です。

1.2.  Terminology

1.2. 用語

   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.

データ・チャンネル(Dチャネル)--2048年のkbits/sインタフェースか1544kbits/sの一般的なシグナリングチャンネルがそれを連結するとき機能する64kbit/sの時間帯は、DPNSSシグナリングを運ぶために食糧を供給されます。

   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.

DPNSSは精神を集中します--DPNSSがチャネルを開設するように2048kbits/sの1〜15と17〜31が連結するか、またはTimeが1544年のkbits/sインタフェースで1〜23に溝をつける時間帯は呼ばれます。 これらは声かデータ通信量を通るトラフィックチャンネルです。

      -  DPNSS supports 60 Channels (30 Real and 30 Virtual)
      -  DASS2 supports 30 Channels (All Real)

- DPNSSは60Channels(30レアルと30Virtual)をサポートします--DASS2は30Channelsをサポートします。(すべて本当)です。

   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.

データLink Connection(DLC)--DLCは1個のDPNSSチャンネルを代表してレベル3 メッセージの転送を制御する平らな2プロセスです。 DLCは唯一1個のDPNSSチャンネルを特定します。

      -  DPNSS supports 60 DLCs (30 Real and 30 Virtual)
      -  DASSII supports 30 DLCs (All Real)

- DPNSSは60DLCs(30レアルと30Virtual)をサポートします--DASSIIは30DLCsをサポートします。(すべて本当)です。

   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".

DPNSS Link--2048年のkbits/sインタフェースか1544年のkbits/sインタフェースのDチャネルと関連DPNSSチャンネルの論理的な収集は「DPNSSリンク」と呼ばれます。

   Real channel - A signalling channel with an associated traffic
   channel (TS).

実際のチャンネル--関連トラフィックチャンネル(TS)の合図チャンネル。

   Virtual channel - A signalling channel with no associated traffic
   channel.

事実上のチャンネル--関連トラフィックチャンネルのない合図チャンネル。

   NT1 - The DPNSS minimum retransmission period.

NT1--DPNSSの最小の「再-トランスミッション」の期間。

   NT2 - The DPNSS minimum post retransmission acknowledgement delay.

NT2--DPNSSの最小のポスト「再-トランスミッション」承認遅れ。

   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].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[5]で説明されるように本書では解釈されることであるべきですか?

Mukundan, et al.            Standards Track                     [Page 3]

RFC 4129      DPNSS/DASS 2 Extensions to the IUA Protocol    August 2005

Mukundan、他 IUAへの標準化過程[3ページ]RFC4129 2DPNSS/ダスExtensionsが2005年8月に議定書を作ります。

1.3.  DPNSS Overview

1.3. DPNSS概要

   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.

DPNSSは産業標準インターフェースです。(審判。 ND1301: 2001/03) [2] どれがPBXとAccess Network(AN)の間で定義されますか? DPNSSは私設のネットワークで接続されるPBXsのにおけるすべての拡大について、通常、独身のPBXに拡大の間にあるだけである施設を広げています。 DPNSSは元々BTのDigital Access Signaling System I(ダスI)から得られて、個人的なネットワーク必要条件を満たすのに必要であるところで高められました。 これらの増進のいくつかがダス2[3]に組み込んでいました。 DPNSSは以下の図1に示されるように2048kbits/sか1544kbits/s Digital Transmission System Interfaceを使用します。

            ----------              ----------        o--o
            |        | 2048 kbits/s |        |-------  /\
            |        |--------------|        |         --
            |  PBX   | 1544 kbits/s |  AN    |
            |        |--------------|        |        o--o
            |        |              |        |-------  /\
            ----------              ----------         --

---------- ---------- o--o | | 2048kbits/s| |------- /\ | |--------------| | -- | PBX| 1544kbits/s| 1| | |--------------| | o--o | | | |------- /\ ---------- ---------- --

                            Figure 1

図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."

チャンネル16が2048年のkbits/s(1E)インタフェースにあって、チャンネル24は、1544年のkbits/s(T1)インタフェースにあって、データ通信のためにLEとANの間で予約されます。 データのために予約されたチャンネルは「データ・チャンネルかD-チャンネル」と呼ばれます。

   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".

D-チャンネルはDPNSSプロトコル同輩実体の間でデータを交換するのに使用される物理的なメディアです。 Dチャネルと関連DPNSSチャンネルの論理的な収集は「DPNSSリンク」と呼ばれます。

Mukundan, et al.            Standards Track                     [Page 4]

RFC 4129      DPNSS/DASS 2 Extensions to the IUA Protocol    August 2005

Mukundan、他 IUAへの標準化過程[4ページ]RFC4129 2DPNSS/ダスExtensionsが2005年8月に議定書を作ります。

1.4.  Proposed DPNSS Backhaul Architecture

1.4. 提案されたDPNSS逆送アーキテクチャ

            ******   DPNSS       ******      IP      *******
            *PBX *---------------* SG *--------------* MGC *
            ******               ******              *******

****** DPNSS******IP********PBX*---------------* SG*--------------* MGC********************

            +-----+                                  +-----+
            |DPNSS|              (NIF)               |DPNSS|
            | L3  |                                  | L3  |
            +-----+           +----------+           +-----+
            |     |           |     | DUA|           | DUA |
            |DPNSS|           |DPNSS+----+           +-----+
            | L2  |           | L2  |SCTP|           |SCTP |
            |     |           |     +----+           +-----+
            |     |           |     | IP +           | IP  |
            +-----+           +-----+----+           +-----+

+-----+ +-----+ |DPNSS| (NIF) |DPNSS| | L3| | L3| +-----+ +----------+ +-----+ | | | | デュア| | デュア| |DPNSS| |DPNSS+----+ +-----+ | L2| | L2|SCTP| |SCTP| | | | +----+ +-----+ | | | | IP+| IP| +-----+ +-----+----+ +-----+

         NIF  - Nodal Interworking function
         SCTP - Stream Control Transmission Protocol
         DUA  - DPNSS User Adaptation Layer Protocol

NIF--こぶのようなInterworking機能SCTP--ストリームControl Transmission Protocolデュア--DPNSS User Adaptation Layerプロトコル

2.  Changes from IUA

2. IUAからの変化

   This section outlines the differences between DUA and IUA.

このセクションはDUAとIUAの違いについて概説します。

2.1.  New Message Class for DUA

2.1. 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.

DPNSS/DASS2 Layer2からLayer3基関数[2][3]は、他のIUA拡張子(すなわち、V5かGR-303)のIUAの境界の原始の輸送メッセージと境界の原始の輸送メッセージから身元保証可能である必要があります。 したがって、DUAメッセージに異なったメッセージクラスパラメタを使用するのが必要です。

   For all DPNSS/DASS2 interface boundary primitives, a new Message
   Class is introduced:

すべてのDPNSS/DASS2インタフェース境界基関数に関しては、新しいMessage Classを導入します:

         13     DPNSS/DASS2 Boundary Primitives Transport Messages
                (DPTM)

13 DPNSS/DASS2境界基関数はメッセージを輸送します。(DPTM)

   Similar to IUA, other valid message classes for DUA are:

IUAと同様であることで、他のDUAに、有効なメッセージのクラスは以下の通りです。

          0       Management (MGMT) Message
          3       ASP State Maintenance (ASPSM) Messages
          4       ASP Traffic Maintenance (ASPTM) Messages

0 管理(管理)メッセージ3ASP州のメインテナンス(ASPSM)メッセージ4ASPトラフィックメインテナンス(ASPTM)メッセージ

Mukundan, et al.            Standards Track                     [Page 5]

RFC 4129      DPNSS/DASS 2 Extensions to the IUA Protocol    August 2005

Mukundan、他 IUAへの標準化過程[5ページ]RFC4129 2DPNSS/ダスExtensionsが2005年8月に議定書を作ります。

2.2.  Message Header

2.2. メッセージヘッダー

   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.

DPTMメッセージと共にIUA Message Header[1]を使用しなければなりませんが、DLCIパラメタのDLCI分野は異なってフォーマットされます。 以下の図2は整数ベースのInterface Identifierと共にIUA Message Headerを示しています。

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×1)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子(整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×5)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLCI| 予備| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2 IUA Message Header (integer-based Interface Identifier)

図2 IUAメッセージヘッダー(整数ベースのインタフェース識別子)

   In DUA, the DLCI field has a different format, in accordance with the
   ND1301:2001/03 (formerly BTNR 188) [2].

DUAでは、ND1301によると、DLCI分野は異なった形式を持っています: 2001/03(以前BTNR188)[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|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|V|0|チャンネルノー| 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved:  7 bits

予約される: 7ビット

   Should be set to all '0's and ignored by the receiver.

すべての'に0設定されて、受信機によって無視されるべきである、'

   V-bit:  1 bit

V-ビット: 1ビット

      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:

V-ビットは、メッセージが特定のDLCのためのものですかそれともキャリヤーのすべてのDLCsに、それが適切であるかどうか決定するのに使用されます。 V-ビットの可能な値は以下に記載されています:

            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.

値の記述0ActionはすべてのDLCsに実行されることになっています。 論理機番パラメタは無視されます。 1 動作は論理機番によって指定された独身のDLCに実行されることです。

Mukundan, et al.            Standards Track                     [Page 6]

RFC 4129      DPNSS/DASS 2 Extensions to the IUA Protocol    August 2005

Mukundan、他 IUAへの標準化過程[6ページ]RFC4129 2DPNSS/ダスExtensionsが2005年8月に議定書を作ります。

      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.

このV-ビット値はEstablishとReleaseメッセージだけによって使用されます。 データメッセージはこの値を無視するべきです。 1DPNSS LinkですべてのDLCsを設立するか、またはリリースするためにただ一つのコマンドを発行できるようにこのインディケータを提供します。

   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.

Channel Number(チャンネルNo.)に関しては、有効値は、ダス2のためのDPNSSのための0〜63と0〜31です。 これはダス2が仮想のDLCsをサポートしないで、またしたがって、32DLCsしか持っていないからです。

2.3.  Unit Data Message

2.3. ユニットデータメッセージ

   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.

DPNSS層2でデータはユニット原始的になりません、そして、したがって、DUAアプリケーションに、Unit Data Messages(要求、Indication)は無効です。 Data RequestとIndicationメッセージ(それぞれメッセージタイプ1と2)はDUAと共に使用されるでしょう。

2.4.  DLC Status Message

2.4. DLCステータスメッセージ

   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:

DUAに、新しいメッセージが、DLCsの状態を運ぶのに必要です。 このメッセージはManagementメッセージになるでしょう(すなわち、メッセージのクラスはManagementのための0の値になるでしょう)。 以下のメッセージタイプはこれらのメッセージに使用されるでしょう:

        5        DLC Status Request
        6        DLC Status Confirm
        7        DLC Status Indication

5 DLC状態要求6DLC状態は7DLC状態指示を確認します。

   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.

DLCsの状態を要求して、確認して、示すためにDUA層の同輩の間でDLC Statusメッセージを交換します。 DLC Statusメッセージはセクション2.2で説明されるようにIUAメッセージヘッダーによってついて来られた一般的なメッセージヘッダーを含んでいます。

Mukundan, et al.            Standards Track                     [Page 7]

RFC 4129      DPNSS/DASS 2 Extensions to the IUA Protocol    August 2005

Mukundan、他 IUAへの標準化過程[7ページ]RFC4129 2DPNSS/ダスExtensionsが2005年8月に議定書を作ります。

   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:

さらに、DLC Status ConfirmとIndicationメッセージはDLC Statusパラメタと呼ばれる新しいパラメタを含むでしょう。 このパラメタは1Eのインタフェースに以下の形式を持つでしょう:

    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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×12)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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).

NAはNot Applicableを表します。 timeslot0が1ユーロの縁どりと同期ビットに使用されて、timeslot16がシグナリングに使用されるので、1Eのインタフェースには、D0とD16は適切ではありません。 DPNSSのために、最大60DLCsの合計があるだろう、(30、本当の+30仮想、)、そこのDASS2の場合に、合計30DLCs(virtualsがない)がそうでしょう。

   This parameter will have the following format for a T1 interface:

このパラメタはT1インタフェースに以下の形式を持つでしょう:

    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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×12)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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).

timeslot23がシグナリングに使用されるので、T1インタフェースには、D23は適切ではありません。 DPNSSのために、最大46DLCsの合計があるだろう、(23、本当の+23仮想、)、そこのDASS2の場合に、合計23DLCs(virtualsがない)がそうでしょう。

Mukundan, et al.            Standards Track                     [Page 8]

RFC 4129      DPNSS/DASS 2 Extensions to the IUA Protocol    August 2005

Mukundan、他 IUAへの標準化過程[8ページ]RFC4129 2DPNSS/ダスExtensionsが2005年8月に議定書を作ります。

   The parameter carries the status of DLCs using two bits for each DLC.
   The possible values for the two bits are shown below:

パラメタは、各DLCに2ビットを使用することでDLCsの状態を運びます。 2ビットで可能な値は以下に示されます:

         Value          Description
           00        Out Of Service
           01        Reset Attempted
           10        Reset Completed
           11        Information Transfer

値の記述00の使われなくなっている01は試みられた10リセット完成した11情報転送をリセットしました。

   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.

ダス2にとって、ダス2DLCにはこの状態がないので、値00(出ているOf Service)は無効です。 さらに、Idle状態がDLCへの地方の一時的な状態である、したがって、値はそれのために割り当てられません。

   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のために、どんな仮想のDLCsもありません、そして、したがって、32DLCsだけの情報は運ばれる必要があります。 したがって、ステータスメッセージには、ダス2DLC Statusメッセージのための12の長さがあるでしょう。

2.5.  Management (MGMT) Messages

2.5. 管理(管理)メッセージ

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

DUAに、NotifyとErrorメッセージだけが有効です。 TEI Statusメッセージは使用されていません。

2.5.1.  Error Message

2.5.1. エラーメッセージ

   The ERR message is sent when an invalid value or unrecognized message
   is found in an incoming message.

入力メッセージで無効の値か認識されていないメッセージを見つけるとき、ERRメッセージを送ります。

   The Error Code parameter indicates the reason for the Error Message.
   These are the supported values in IUA.

Error CodeパラメタはError Messageの理由を示します。 これらは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

無効のバージョン0x01Invalid Interface Identifier0x02Unsupported Message Class0x03Unsupported Message Type0x04Unsupported Traffic Handling Mode0x05Unexpected Message0x06プロトコルError0x07Unsupported Interface Identifier Type0x08Invalid Stream Identifier0×09Unassigned TEI 0x0a Unrecognized SAPI 0x0b Invalid TEI、SAPI組み合わせ0x0c Refused--管理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

Mukundan、他 IUAへの標準化過程[9ページ]RFC4129 2DPNSS/ダスExtensionsが2005年8月に議定書を作ります。

   In DUA, the error codes 0x0a, 0x0b, and 0x0c are invalid, as they are
   specific to ISDN.

DUAでは、それらがISDNに特定であるようにエラーコードの0x0a、0x0b、および0x0cは無効です。

   The following additional error codes are supported in DUA:

以下の追加エラーコードはDUAでサポートされます:

        Channel Number out of range                   0x1c
        Channel Number not configured                 0x1d

範囲0x1c Channel NumberからのチャンネルNumberは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.

DPNSSのための63以上の論理機番かダス2のための31でメッセージを受け取るなら、「範囲からのチャンネルNumber」誤りを送ります。

   The "Channel Number not configured" error is sent if a message is
   received with a channel number that is not configured.

構成されない論理機番でメッセージを受け取るなら、「Numberが構成しなかったチャンネル」誤りを送ります。

3.  IANA Considerations

3. IANA問題

   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:

IANAはSCTP有効搭載量Data塊に使用されるSCTP有効搭載量プロトコルIdentifier分野にDUA値を割り当てました。 以下はSCTPのために有効搭載量プロトコルIdentifier分野SHOULDを評価します。DUAには、使用されてください:

         SCTP Payload Protocol ID = "10"

SCTP有効搭載量Protocol ID=「10インチ」

4.  Use of SCTP Payload Protocol ID

4. SCTP有効搭載量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.

また、例えば、オプションとして、1つが同じSCTP協会の上で逆送ISDNとDPNSSに欲しかったなら、SCTP有効搭載量Protocol IDへのIUA値はDUAに使用されるかもしれません。 しかしながら、別々のSCTP有効搭載量プロトコルID(DUAのための10とIUAのための1)の使用は第一のオプションとしてお勧めです、ISDNとDPNSSが同じSCTP協会の上でbackhauledされるシナリオでさえ。

   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).

「DPNSSだけがSCTP協会の上でbackhauledされるなら(すなわち、同じ協会の上のISDNとDPNSSの同時のbackhaulingは必要でないシナリオで)、10インチはデュアに使用されるべきである」SCTP有効搭載量Protocol ID。

   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.

SCTP有効搭載量プロトコルIdentifierは、SCTPがどのプロトコルを運ぶかを示すためにそれぞれのSCTP Data塊に含まれています。 この有効搭載量プロトコルIdentifierはSCTPによって直接使用されませんが、あるネットワーク実体によって使用されて、Data塊で運ばれる情報の種類を特定するかもしれません。

Mukundan, et al.            Standards Track                    [Page 10]

RFC 4129      DPNSS/DASS 2 Extensions to the IUA Protocol    August 2005

Mukundan、他 IUAへの標準化過程[10ページ]RFC4129 2DPNSS/ダスExtensionsが2005年8月に議定書を作ります。

5.  Message Sequence in DUA

5. 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.

DPNSSチャンネルでPDUsを渡して、データ・リンクをリリースするのは以下にメッセージに関する例がシグナリングチャンネルの上にデータ・リンクを設立するために流れるのが示されます。 MGCとSGとの活動的な協会は以下のメッセージ流れの前に設立されます。

5.1.  Resetting of single DLC

5.1. 独身のDLCのリセット

      i)  Successful

i) うまくいく

       PBX                     SG                        MGC
           <----------- SABMR          <----------- Est Req(Ind=1)
       UA   ----------->       Est Cfm -----------> (DLC in RC State)
                                Ind=1)

PBX SG MGC<。----------- SABMR<。----------- エストReq(インディアン座=1)UA----------->エストCfm----------->(RC状態のDLC) インディアン座=1)

      ii) Unsuccessful(Link Failure)

ii) 失敗(リンクの故障)

         PBX                     SG                        MGC
           <----------- SABMR         <----------- Est Req(Ind=1)
           Retransmissions over
           NT1 and NT2 expired
                               Rel Ind -----------> (DLC in RA state)
                              (RELEASE_OTHER,Ind=1)

PBX SG MGC<。----------- SABMR<。----------- NT1とNT2の上のエストReq(インディアン座=1)RetransmissionsはRelインディアン座を吐き出しました。----------->(RA状態のDLC)(リリース_他であり、インディアン座は1と等しいです)

5.2.  Resetting all DLCs in a Link

5.2. LinkのすべてのDLCsをリセットします。

         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

PBX SG MGC<。----------- SABMR(1)<。----------- エストReq(インディアン座=0)<。----------- SABMR(2)<。----------- SABMR(3)… <、-、-、-、-、-、-、-、-、-、-- SABMR(N)、各DLCでは、UAが受け取られているか、またはNT1/NT2は満期です。

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

エストCfm----------->(DLCs(インディアン座=0)の状態をアップデートしない)<。----------- 状態Req Status cfm---------->。(ステータスビットに基づくマークDLC状態)

   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

またはより多くのDLCsの1つがこの手順(例えば、2管理を層にする)の後に使われなくなっていたままで残っているなら、MGCがエストReq(インディアン座=1)と共に特定のDLCを示しながらこのDLCを再試行できる。

Mukundan, et al.            Standards Track                    [Page 11]

RFC 4129      DPNSS/DASS 2 Extensions to the IUA Protocol    August 2005

Mukundan、他 IUAへの標準化過程[11ページ]RFC4129 2DPNSS/ダスExtensionsが2005年8月に議定書を作ります。

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

エストReq(インディアン座=0)とSGは使われなくなっている適切なDLCを再試行するでしょう。

5.3.  Information Transfer on a DLC

5.3. DLCにおける情報転送

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

PBX SG MGC<。----------- ウイ(C)<。----------- データReq UI(R)----------->データインディアン座----------->。

5.4.  Link Takedown (Single DLC)

5.4. リンク分解(独身の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)

PBX SG MGC(DPNSSのためのOOSとしてのマークDLC)<。----------- Rel Req(DASSIIのためのRAとしてのマークDLC)(RELEASE_MGMT、インディアン座=1)Rel Cfm---------->。(インディアン座=1)

5.5.  Link Takedown (All DLCs)

5.5. リンク分解(すべての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)

PBX SG MGC(DPNSSに関して、OOSとしてすべてのDLCsをマークする)<。-------- Rel Req(DASSIIのためのRAとしてのマークDLC)(RELEASE_MGMT、インディアン座=0)Rel Cfm---------->。(インディアン座=0)

5.6.  Getting Link Status

5.6. リンク状態を得ます。

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

PBX SG MGC<。----------- スタットReqスタットCfm----------->。(ステータスビットに基づくマークDLC状態)

5.7.  Error Conditions

5.7. エラー条件

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

PBX SG MGCの無効のメッセージ<。-----------Est/Rel/Data/スタットReq誤りインディアン座----------->。(エラーコード)

Mukundan, et al.            Standards Track                    [Page 12]

RFC 4129      DPNSS/DASS 2 Extensions to the IUA Protocol    August 2005

Mukundan、他 IUAへの標準化過程[12ページ]RFC4129 2DPNSS/ダスExtensionsが2005年8月に議定書を作ります。

6.  Security Considerations

6. セキュリティ問題

   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.

ISDN User Adaptationプロトコル(IUAP)[1](セクション6)とSIGTRANプロトコルのためのセキュリティ問題が[4]を記録するので、セキュリティ問題はまた、このドキュメントに適用されます。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

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

[1]Morneault、K.、Rengasami、S.、カッラ、M.、およびG.Sidebottom、「ISDN Q.921-ユーザ適合層」、RFC3057、2001年2月。

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

[2]Ofcom/NICC ND1301: 2001/03、DPNSS[188]、デジタル個人的な合図システムノー1(DPNSS1)(以前BTNR188)。

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

[3] BTNR(ブリティッシュ・テレコムネットワーク要件)190は2のデジタルアクセスシグナリングシステムノー2を発行します。

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

[4]Loughney、J.、Tuexen、M.、およびJ.牧師-Balbas、「シグナリング輸送(SIGTRAN)プロトコルのためのセキュリティ問題」、RFC3788、2004年6月。

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

[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

8.  Acknowledgements

8. 承認

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

作者は彼らの役に立つ提案とコメントについてウィプロTechnologiesのシャーシー・クマーとVenkatesh Seshasayeeに感謝したがっています。

Mukundan, et al.            Standards Track                    [Page 13]

RFC 4129      DPNSS/DASS 2 Extensions to the IUA Protocol    August 2005

Mukundan、他 IUAへの標準化過程[13ページ]RFC4129 2DPNSS/ダスExtensionsが2005年8月に議定書を作ります。

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

Ranjith Mukundanウィプロ技術72、エレクトロニクス市のHosur本道バンガロール560100インド

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

以下に電話をしてください。 +91-80-51195893はメールされます: ranjith.mukundan@wipro.com

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

ケンMorneaultシスコシステムズInc.13615ダレスTechnology Driveハーンドン(ヴァージニア)。 20171 米国

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

以下に電話をしてください。 +1-703-484-3323 メールしてください: kmorneau@cisco.com

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

Narsimuloo Mangalpallyノーテルネットワーク250シドニー通りベルビル、オンタリオK8P 3Z3カナダ

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

以下に電話をしてください。 +1-613-967-5034 メールしてください: narsim@nortelnetworks.com

Mukundan, et al.            Standards Track                    [Page 14]

RFC 4129      DPNSS/DASS 2 Extensions to the IUA Protocol    August 2005

Mukundan、他 IUAへの標準化過程[14ページ]RFC4129 2DPNSS/ダスExtensionsが2005年8月に議定書を作ります。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

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

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Mukundan, et al.            Standards Track                    [Page 15]

Mukundan、他 標準化過程[15ページ]