RFC3308 日本語訳

Network Working Group                                         P. Calhoun
Request for Comments: 3308                          Black Storm Networks
Category: Standards Track                                         W. Luo
                                                     Cisco Systems, Inc.
                                                            D. McPherson
                                                                     TCB
                                                               K. Peirce
                                                   Malibu Networks, Inc.
                                                          November 2002

コメントを求めるワーキンググループP.カルフーン要求をネットワークでつないでください: 3308年の黒い嵐はカテゴリをネットワークでつなぎます: 規格はInc.2002年11月にW.羅シスコシステムズInc.D.マクファーソンTCB K.ピアスマリブネットワークを追跡します。

                  Layer Two Tunneling Protocol (L2TP)
                   Differentiated Services Extension

層Twoのトンネリングプロトコル(L2TP)はサービス拡大を微分しました。

Status of this Memo

この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 (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   This document describes mechanisms which enable the Layer Two
   Tunneling Protocol (L2TP) to negotiate desired Per Hop Behavior (PHB)
   code for the L2TP control connection, as well as individual sessions
   within an L2TP tunnel.

このドキュメントはLayer Two Tunnelingプロトコル(L2TP)がL2TPコントロール接続のために必要なPer Hop Behavior(PHB)コードを交渉するのを可能にするメカニズムについて説明します、L2TPトンネルの中の個々のセッションと同様に。

   L2TP provides a standard method for tunneling PPP packets.  The
   current specification provides no provisions for supporting
   Differentiated Services (diffserv) over the L2TP control connection
   or subsequent data sessions.  As a result, no standard mechanism
   currently exists within L2TP to provide L2TP protocol negotiations
   for service discrimination.

L2TPはトンネリングPPPパケットに標準方法を提供します。 現在の仕様はL2TPコントロール接続か順次データセッションの間、Differentiated Services(diffserv)を支持するための条項を全く提供しません。 その結果、どんな標準のメカニズムも、現在、サービス区別のための議定書交渉をL2TPに供給するためにL2TPの中に存在しません。

Calhoun, et. al.            Standards Track                     [Page 1]

RFC 3308                L2TP Diffserv Extension            November 2002

etカルフーン、アル。 規格はL2TP Diffserv拡大2002年11月にRFC3308を追跡します[1ページ]。

Table of Contents

目次

   1.   Specification of Requirements ...............................  2
   2.   Introduction ................................................  2
   3.   Control Connection Operation ................................  3
   3.1. Control Connection DS AVP (SCCRQ, SCCRP) ....................  4
   4.   Session Operation ...........................................  4
   4.1. Session DS AVP (ICRQ, ICRP, OCRQ, OCRP) .....................  6
   5.   DS AVPs Correlation .........................................  6
   6.   PHB Encoding ................................................  6
   7.   DSCP Selection ..............................................  7
   8.   Packet Reordering and Sequence Numbers ......................  7
   9.   Crossing Differentiated Services Boundaries .................  7
   10.  IANA Considerations .........................................  8
   11.  Security Considerations .....................................  8
   12.  Acknowledgements ............................................  8
   13.  References ..................................................  8
   14.  Authors' Addresses ..........................................  9
   15.  Full Copyright Statement .................................... 10

1. 要件の仕様… 2 2. 序論… 2 3. 接続操作を制御してください… 3 3.1. 接続DS AVP(SCCRQ、SCCRP)を制御してください… 4 4. セッション操作… 4 4.1. セッションDS AVP(ICRQ、ICRP、OCRQ、OCRP)… 6 5. DS AVPs相関関係… 6 6. PHBコード化… 6 7. DSCP選択… 7 8. パケットReorderingと一連番号… 7 9. 交差点はサービス境界を微分しました… 7 10. IANA問題… 8 11. セキュリティ問題… 8 12. 承認… 8 13. 参照… 8 14. 作者のアドレス… 9 15. 完全な著作権宣言文… 10

1. Specification of Requirements

1. 要件の仕様

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

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

2. Introduction

2. 序論

   The L2TP specification currently provides no mechanism for supporting
   diffserv (DS).  This document describes mechanisms that enable L2TP
   to indicate desired PHB code, as defined in [RFC 3140], to be
   associated with an L2TP control connection, as well as individual
   sessions within an L2TP tunnel.

L2TP仕様は現在、diffserv(DS)を支持するのにメカニズムを全く提供しません。 このドキュメントはL2TPが必要なPHBコードを示すのを可能にするメカニズムについて説明します、L2TPコントロール接続に関連しているように[RFC3140]で定義されるように、L2TPトンネルの中の個々のセッションと同様に。

   The actual bit interpretation of the DS field is beyond the scope of
   this document, and is purposefully omitted.  This document is
   concerned only with defining a uniform exchange and subsequent
   mapping mechanism for the DS AVPs.

DS分野の実際の噛み付いている解釈は、このドキュメントの範囲を超えていて、故意に省略されます。 このドキュメントはDS AVPsのために一定の交換とその後のマッピングメカニズムを定義するだけに関係があります。

Calhoun, et. al.            Standards Track                     [Page 2]

RFC 3308                L2TP Diffserv Extension            November 2002

etカルフーン、アル。 規格はL2TP Diffserv拡大2002年11月にRFC3308を追跡します[2ページ]。

3. Control Connection Operation

3. コントロール接続操作

   As defined in [RFC 2661], a control connection operates in-band over
   a tunnel to control the establishment, release, and maintenance of
   sessions and of the tunnel itself.  As such, this document provides a
   mechanism to enable discrimination of L2TP control messages from
   other packets.  For this purpose, we introduce the Control Connection
   DS (CCDS) AVP.

[RFC2661]で定義されるように、コントロール接続はセッションとトンネルの設立、リリース、および維持自体を制御するトンネルの上でバンドで働いています。 そういうものとして、このドキュメントは、他のパケットからのL2TPコントロールメッセージの区別を可能にするためにメカニズムを提供します。 このために、私たちはControl Connection DS(CCDS)AVPを導入します。

   The presence of the CCDS AVP serves as an indication to the peer (LAC
   or LNS) that the tunnel initiator wishes both the tunnel initiator
   and terminator to use the per-hop behavior(s) (PHB(s)) indicated by
   the AVP's PHB code for all packets within the tunnel's control
   connection.  A PHB is a description of the externally observable
   forwarding behavior of a DS node applied to a particular DS behavior
   aggregate, as defined in [RFC 2475].  The most simple example of a
   PHB is one which guarantees a minimal bandwidth allocation of a link
   to a behavior aggregate.

CCDS AVPの存在はトンネル創始者がトンネルのコントロール接続の中のすべてのパケットに(というPHB(s))がAVPのものを示した1ホップあたりの振舞いPHBコードを使用するために両方にトンネル創始者とターミネータを願っているという同輩(LACかLNS)への指示として機能します。 PHBは特定のDS振舞い集合に適用されたDSノードの外部的に観察可能な推進動きの記述です、[RFC2475]で定義されるように。 PHBの最も簡単な例は振舞い集合へのリンクの最小量の帯域幅配分を保証するものです。

   Upon receipt of a Start-Control-Connection-Request (SCCRQ) containing
   the CCDS AVP, if the tunnel terminator provides no support for the
   CCDS AVP it MUST ignore the AVP and send an SCCRP to the tunnel
   initiator without the CCDS AVP.  The tunnel initiator interprets the
   absence of the CCDS AVP in the SCCRP as an indication that the tunnel
   terminator is incapable of supporting CCDS.

トンネルターミネータがCCDS AVPのサポートを全く提供しないならCCDS AVPを含むStartコントロール接続要求(SCCRQ)を受け取り次第、それは、CCDS AVPなしでトンネル創始者にAVPを無視して、SCCRPを送らなければなりません。 トンネル創始者はトンネルターミネータがCCDSを支持できないという指示としてSCCRPのCCDS AVPの不在を解釈します。

   Upon receipt of an SCCRP that contains no CCDS AVP in response to a
   SCCRQ that contained a CCDS AVP, if the tunnel initiator wants to
   continue tunnel establishment it sends an SCCCN.  Otherwise, it sends
   a StopCCN to the tunnel terminator to end the connection.  The
   StopCCN control message MUST contain the Result Code 8 that indicates
   CCDS AVP value (47) as the reason for sending the StopCCN.

トンネル創始者がトンネル設立を続けたいならCCDS AVPを含んだSCCRQに対応してCCDS AVPを全く含まないSCCRPを受け取り次第、それはSCCCNを送ります。 さもなければ、それは、接続を終わらせるためにトンネルターミネータにStopCCNを送ります。 StopCCNコントロールメッセージはStopCCNを送る理由としてCCDS AVP値(47)を示すResult Code8を含まなければなりません。

   If the tunnel terminator provides support for CCDS, it SHOULD use the
   Host Name AVP embedded in SCCRQ to consult its local policy, and to
   determine whether local policy permits the requested PHB code to be
   used on this control connection.  If it is unwilling or unable to
   support the requested PHB code after consulting the local policy, the
   tunnel terminator MUST send an SCCRP control message containing a
   CCDS AVP indicating the value it is willing to use.  If the CCDS AVP
   value is the same as the one in the SCCRQ, it signals the acceptance
   of the requested PHB code.  If the value is different it serves as a
   counter-offer by the tunnel terminator.

トンネルターミネータはCCDSのサポートを提供して、それはHost Name AVPがローカルの方針に相談して、要求されたPHBがこれで使用されるためにコード化する地方の方針許可証が接続を監督するかどうか決定するためにSCCRQに埋め込んだSHOULD使用です。 不本意であるか、またはローカルの方針に相談した後に要求されたPHBコードをサポートできないなら、トンネルターミネータで、CCDS AVPを含むSCCRPコントロールメッセージはそれが使用しても構わないと思っている値を示さなければなりません。 CCDS AVP値がSCCRQのものと同じであるなら、それは要求されたPHBコードの承認に合図します。 値が異なるなら、それは買申込みとしてトンネルターミネータで機能します。

Calhoun, et. al.            Standards Track                     [Page 3]

RFC 3308                L2TP Diffserv Extension            November 2002

etカルフーン、アル。 規格はL2TP Diffserv拡大2002年11月にRFC3308を追跡します[3ページ]。

   If the tunnel initiator receives an SCCRP that contains a CCDS AVP
   with a value other than that requested in the SCCRQ, the tunnel
   initiator SHOULD check the PHB code against its own policy.  If it is
   unwilling to use the value, the tunnel initiator MUST send a StopCCN
   control message containing the Result Code 8 that indicates CCDS AVP
   value (47) as the reason for sending the StopCCN.

SCCRQで要求されているのを除いて、トンネル創始者が値でCCDS AVPを含むSCCRPを受け取るなら、トンネル創始者SHOULDはそれ自身の方針に対してPHBコードをチェックします。 値を使用するのが不本意であるなら、トンネル創始者はStopCCNを送る理由としてCCDS AVP値(47)を示すResult Code8を含むStopCCNコントロールメッセージを送らなければなりません。

3.1. Control Connection DS AVP (SCCRQ, SCCRP)

3.1. コントロール接続DS AVP(SCCRQ、SCCRP)

   The CCDS AVP is encoded as Vendor ID 0, and the Attribute Type is 47.

CCDS AVPはVendor ID0としてコード化されます、そして、Attribute Typeは47歳です。

   Each CCDS AVP is encoded as follows:

各CCDS AVPは以下の通りコード化されます:

     Vendor ID = 0
     Attribute = 47

0業者ID=属性=47

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|H|0|0|0|0|    Length         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              47               |           PHB Code            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 47 | PHBコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This AVP MAY be present in the following message types:  SCCRQ and
   SCCRP.  This AVP MAY be hidden (the H-bit set to 0 or 1) and is
   optional (M-bit not set).  The length (before hiding) of this AVP
   MUST be 8 octets.  The encoding of the PHB code is described in
   Section 6.

このAVP MAY、以下のメッセージタイプで、存在してください: SCCRQとSCCRP。 このAVP MAYは隠されて(H-ビットは0か1にセットしました)、任意です(M-ビットはセットしませんでした)。 長さ、(隠れることの前の) このAVP MUSTでは、8つの八重奏になってください。 PHBコードのコード化はセクション6で説明されます。

4. Session Operation

4. セッション操作

   As defined in [RFC 2661], an L2TP session is connection-oriented. The
   LAC and LNS maintain states for each call that is initiated or
   answered by an LAC.  An L2TP session is created between the LAC and
   LNS when an end-to-end connection is established between a Remote
   System and the LNS.  Datagrams related to the connection are sent
   over the tunnel between the LAC and LNS.  As such, this document
   provides a mechanism to enable discrimination for packets within a
   particular session from those in other sessions.  For this purpose,
   we introduce the Session DS (SDS) AVP.

[RFC2661]で定義されるように、L2TPセッションは接続指向です。 LACとLNSはLACによって開始されるか、または答えられる各呼び出しのために州を維持します。 終わりから終わりとの接続がRemote SystemとLNSの間で確立されるとき、L2TPセッションはLACとLNSの間で作成されます。 LACとLNSの間のトンネルの上に接続に関連するデータグラムを送ります。 そういうものとして、このドキュメントは、他のセッションのときに特定のセッション以内にそれらからパケットのための区別を可能にするためにメカニズムを提供します。 このために、私たちはSession DS(SDS)AVPを導入します。

   The presence of the SDS AVP serves as an indication to the peer (LAC
   or LNS) that the session initiator wishes both the session initiator
   and terminator to use the per-hop behavior(s) (PHB(s)) indicated by
   the AVP's PHB code for all packets within the session.

SDS AVPの存在はセッション創始者がセッション中にすべてのパケットに(というPHB(s))がAVPのものを示した1ホップあたりの振舞いPHBコードを使用するために両方にセッション創始者とターミネータを願っているという同輩(LACかLNS)への指示として機能します。

Calhoun, et. al.            Standards Track                     [Page 4]

RFC 3308                L2TP Diffserv Extension            November 2002

etカルフーン、アル。 規格はL2TP Diffserv拡大2002年11月にRFC3308を追跡します[4ページ]。

   Upon receipt of an Incoming-Call-Request (ICRQ) or Outgoing-Call-
   Request (OCRQ) containing the SDS AVP if the session terminator
   provides no support for the requested PHB code, the session
   terminator MUST ignore the SDS AVP and send an ICRP or OCRP to the
   session initiator without the SDS AVP.  The session initiator
   interprets the absence of the SDS AVP in the ICRP or OCRP as an
   indication that the session terminator is incapable of supporting
   SDS.

セッションターミネータが要求されたPHBコードのサポートを全く提供しないならSDS AVPを含むIncoming呼び出し要求(ICRQ)かOutgoing-呼び出し要求(OCRQ)を受け取り次第、セッションターミネータは、SDS AVPなしでセッション創始者にSDS AVPを無視して、ICRPかOCRPを送らなければなりません。 セッション創始者はセッションターミネータがSDSを支持できないという指示としてICRPかOCRPのSDS AVPの不在を解釈します。

   Upon receipt of an ICRP or OCRP that contains no SDS AVP in response
   to an ICRQ or OCRQ that contained an SDS AVP, if the session
   initiator is willing to omit employing SDS AVP it continues session
   establishment as defined in [RFC 2661].  Otherwise, it sends a CDN to
   the session terminator to end the connection.  The CDN control
   message MUST contain the Result Code 12 that indicates SDS AVP value
   (48) as the reason for sending the CDN.

セッション創始者が、SDS AVPを使うのを忘れても構わないと思っているならSDS AVPを含んだICRQかOCRQに対応してSDS AVPを全く含まないICRPかOCRPを受け取り次第、それは[RFC2661]で定義されるようにセッション設立を続けています。 さもなければ、それは、接続を終わらせるためにセッションターミネータにCDNを送ります。 CDNコントロールメッセージはCDNを送る理由としてSDS AVP値(48)を示すResult Code12を含まなければなりません。

   In order to help the session terminator to distinguish one session
   from another when consulting the local policy of the PHB code, the
   session initiator MAY use the identifier or a combination of
   identifiers embedded in AVPs such as Proxy Authen Name AVP, Calling
   Number AVP, Called Number AVP, and Sub-Address AVP.  When Proxy
   Authen Name AVP is used as a distinguishor, it SHOULD be present in
   the ICRQ or OCRQ.  The designated DS identifier(s) used for looking
   up the PHB code SHOULD be configurable.

セッションターミネータを助けて、相談するとき、別のものと1つのセッションを区別するのに、PHBコードのローカルの方針、セッション創始者が識別子を使用するかもしれませんか、または識別子の組み合わせはProxy Authen Name AVP(Calling Number AVP、Called Number AVP、およびSub-アドレスAVP)としてそのようなものをAVPsに埋め込みました。 いつProxy Authen Name AVPはdistinguishorとして使用されるか、そして、それはSHOULDです。ICRQかOCRQに存在してください。 指定されたDS識別子は、PHBを見上げるのにコードSHOULDを使用しました。構成可能であってください。

   If the session terminator provides support for SDS, it SHOULD use the
   the designated DS identification AVP (via out-of-band agreement
   between the administrators of the LAC and LNS) to consult the local
   policy and determinate whether the local policy permits the requested
   PHB code to be used on this session.  If it is unwilling or unable to
   support the requested PHB code the session terminator MUST do one of
   the following:

セッションターミネータはSDSのサポートを提供します、それ。SHOULDは、ローカルの方針が、要求されたPHBコードがこのセッションのときに使用されることを許可するか否かに関係なく、ローカルの方針で確定的な状態で相談するのに、指定されたDS識別AVP(LACとLNSの管理者の間のバンドで出ている協定を通した)を使用します。 不本意であるか、または要求されたPHBコードをサポートできないなら、セッションターミネータは以下の1つをしなければなりません:

   1) Send a CDN message containing the Result Code 12 that indicates
      SDS AVP value (48) as the reason for sending the CDN.

1) CDNを送る理由としてSDS AVP値(48)を示すResult Code12を含むCDNメッセージを送ってください。

   2) Send an Incoming-Call-Reply (ICRP) or Outgoing-Call-Reply (OCRP)
      message containing an SDS AVP indicating the PHB code the
      terminator is willing to use for the session.

2) SDS AVPを含むIncoming呼び出し回答(ICRP)かOutgoing呼び出し回答(OCRP)メッセージにターミネータがセッションのために使用しても構わないと思っているPHBコードを示させてください。

   If the session terminator supports the PHB code in the SDS AVP
   session establishment MUST continue as defined in [RFC 2661].

セッションターミネータがPHBを支持するなら、SDS AVPセッション設立におけるコードは[RFC2661]で定義されるように続かなければなりません。

   If the session initiator receives an ICRP or OCRP that contains an
   SDS AVP with a value other than that requested in the ICRQ or OCRQ,
   and the session initiator is unwilling to use the value, the session
   initiator MUST send a CDN message containing the Result Code 12 that

ICRQかOCRQで要求されているのを除いて、セッション創始者が値でSDS AVPを含むICRPかOCRPを受け取って、セッション創始者が値を使用したがっていないなら、セッション創始者がResult Code12を含むCDNメッセージを送らなければならない、それ

Calhoun, et. al.            Standards Track                     [Page 5]

RFC 3308                L2TP Diffserv Extension            November 2002

etカルフーン、アル。 規格はL2TP Diffserv拡大2002年11月にRFC3308を追跡します[5ページ]。

   indicates SDS AVP value (48) as the reason for sending the CDN.  If
   the session initiator receives an ICRP or OCRP that contains an SDS
   AVP with a value other than that requested in the ICRQ or OCRQ, and
   the session initiator is willing to use the value, the session
   initiator MUST proceed as indicated in [RFC 2661].

CDNを送る理由としてSDS AVP値(48)を示します。 ICRQかOCRQで要求されているのを除いて、セッション創始者が値でSDS AVPを含むICRPかOCRPを受け取って、セッション創始者が、値を使用しても構わないと思っているなら、セッション創始者は[RFC2661]にみられるように続かなければなりません。

4.1. Session DS AVP (ICRQ, ICRP, OCRQ, OCRP)

4.1. セッションDS AVP(ICRQ、ICRP、OCRQ、OCRP)

   The SDS AVP is encoded as Vendor ID 0, and the Attribute Value is 48.

SDS AVPはVendor ID0としてコード化されます、そして、Attribute Valueは48歳です。

   Each SDS AVP is encoded as follows:

各SDS AVPは以下の通りコード化されます:

     Vendor ID = 0
     Attribute = 48

0業者ID=属性=48

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|H|0|0|0|0|    Length         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              48               |           PHB Code            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 48 | PHBコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This AVP MAY be present in the following message types:  ICRQ, ICRP,
   OCRQ and OCRP.  This AVP MAY be hidden (the H-bit set to 0 or 1) and
   is optional (M-bit is not set 0).  The length (before hiding) of this
   AVP MUST be 8 octets.  The encoding of the PHB code is described in
   Section 6.

このAVP MAY、以下のメッセージタイプで、存在してください: ICRQ、ICRP、OCRQ、およびOCRP。 このAVP MAYは隠されて(H-ビットは0か1にセットしました)、任意です(M-ビットはセット0ではありません)。 長さ、(隠れることの前の) このAVP MUSTでは、8つの八重奏になってください。 PHBコードのコード化はセクション6で説明されます。

5. DS AVPs Correlation

5. DS AVPs相関関係

   CCDS AVP and SDS AVP are independent of each other.  CCDS AVP is used
   to signal diffserv for the control connection between two L2TP peers,
   while SDS AVP is used for data connection.  The PHB code signaled in
   one AVP SHOULD NOT have any implication on the PHB code signaled in
   the other AVP.  Implementations MAY choose to implement either or
   both DS AVPs, and operations MAY choose to enable diffserv on either
   or both types of connections.

CCDS AVPとSDS AVPは互いから独立しています。 CCDS AVPは2人のL2TP同輩の間のコントロール接続のためにdiffservに合図するのに使用されます、SDS AVPがデータ接続に使用されますが。 コードが1AVP SHOULD NOTに示したPHBはもう片方のAVPで合図されたPHBコードにどんな意味も持っています。 実現が、どちらかを実行するのを選ぶかもしれませんか、またはDS AVPsと操作の両方が、どちらかかタイプの両方の接続のときにdiffservを有効にするのを選ぶかもしれません。

6. PHB Encoding

6. PHBコード化

   The PHB code is a left-justified 16-bit field using Per Hop Behavior
   (PHB) encoding defined in [RFC 3140].  Note that [RFC 3140] and its
   successor are the ultimate authority defining PHB encoding.

PHBコードは[RFC3140]で定義されたPer Hop Behavior(PHB)コード化を使用する左で正当な16ビットの分野です。 [RFC3140]とその後継者がPHBコード化を定義する最高権威であることに注意してください。

Calhoun, et. al.            Standards Track                     [Page 6]

RFC 3308                L2TP Diffserv Extension            November 2002

etカルフーン、アル。 規格はL2TP Diffserv拡大2002年11月にRFC3308を追跡します[6ページ]。

   Upon successful establishment of an L2TP tunnel control connection or
   individual L2TP session employing the appropriate DS AVP defined in
   this document, both LAC and LNS MUST use their own PHB-to-DSCP
   mappings of their present DS domains to map the PHB to a DSCP and
   place it in the DS field of the outer IP header of packets
   transmitted on the connection.

本書では定義された適切なDS AVPを使うL2TPトンネルコントロール接続か個々のL2TPセッションのうまくいっている設立のときに、LACとLNS MUSTの両方が、PHBをDSCPに写像して、接続のときに伝えられたパケットの外側のIPヘッダーのDS分野にそれを置くのにPHBからDSCPへのそれらの現在のDSドメインに関するそれら自身のマッピングを使用します。

7. DSCP Selection

7. DSCP選択

   The requirements or rules of each service and DSCP mapping are set
   through administrative policy mechanisms which are outside the scope
   of this document.

それぞれのサービスとDSCPマッピングの要件か規則がこのドキュメントの範囲の外にある施政方針メカニズムを通して設定されます。

8. Packet Reordering and Sequence Numbers

8. パケットReorderingと一連番号

   [RFC 2474] RECOMMENDS that PHB implementations not cause reordering
   of packets within an individual connection.  [RFC 3140] requires that
   a set of PHBs signaled using a single PHB ID MUST NOT cause
   additional packet reordering within an individual connection vs.
   using a single PHB.  Since the CCDS and SDS AVPs contain one PHB ID,
   use of diffserv PHBs in accordance with this specification should not
   cause additional packet reordering within an L2TP control or data
   connection.

[RFC2474] 個々の接続の中でパケットを再命令するPHB実現が引き起こさないRECOMMENDS。 [RFC3140]は、独身のPHB ID MUST NOTを使用することで合図されたPHBsの1セットが独身のPHBを使用することに対して個々の接続の中で再命令される追加パケットを引き起こすのを必要とします。 CCDSとSDS AVPsが1PHB IDを含んでいるので、この仕様に従ったdiffserv PHBsの使用はL2TPコントロールかデータ接続の中で再命令される追加パケットを引き起こすべきではありません。

   Sequence numbers are required to be present in all control messages
   and are used to provide reliable delivery on the control connection,
   as defined in [RFC 2661].  While packet reordering is inevitably as
   much a function of the network as it is local traffic conditioning,
   the probability of it occurring when employing the CCDS AVP is same
   as when not employing the AVP.  Data messages MAY use sequence
   numbers to reorder packets and detect lost packets.

一連番号は、すべてのコントロールメッセージに存在しているのが必要であり、コントロール接続のときに信頼できる配信を提供するのに使用されます、[RFC2661]で定義されるように。 パケット再命令はそれが地方の交通調節であるのとネットワークの同じくらい機能ですが、CCDS AVPを使うとき起こるという確率はAVPを使わないのにおいていつと同じであるか。 データメッセージは、追加注文パケットに一連番号を使用して、無くなっているパケットを検出するかもしれません。

9. Crossing Differentiated Services Boundaries

9. 微分されたサービス境界に交差しています。

   With the potential that an L2TP connection traverses an arbitrary
   number of DS domains, signaling PHBs via L2TP is more appropriate
   than signaling DSCPs, because it maintains a consistent end-to-end
   differentiated service for the L2TP connection.  As per [RFC 2983],
   the negotiated PHBs are mapped to locally defined DSCPs of the
   current DS domain at the tunnel ingress node.  At the DS domain
   boundary nodes, the DSCPs can be rewritten in the DS field of the
   outer IP header, so that the DSCPs are always with respect to
   whatever DS domain the packet happens to be in.

可能性で、L2TPを通してPHBsに合図して、L2TP接続がDSドメインの特殊活字の数字を横断するのは、DSCPsに合図するより適切です、一貫した終わりから終わりがL2TP接続のためにサービスを微分したと主張するので。 [RFC2983]に従って、交渉されたPHBsはトンネルイングレスノードで現在のDSドメインの局所的に定義されたDSCPsに写像されます。 DSドメイン境界ノードでは、外側のIPヘッダーのDS分野でDSCPsを書き直すことができます、いつもパケットがたまたまあるいかなるDSドメインに関してもDSCPsがあるように。

   As a result, it is perfectly acceptable that the outermost DS field
   of packets arriving on a given control connection or session are not
   marked with the same DSCP value that was used by the tunnel ingress
   node.

その結果、与えられたコントロール接続かセッションに到達するパケットの一番はずれのDS分野がトンネルイングレスノードによって使用されたのと同じDSCP値で示されないのは、完全に許容できます。

Calhoun, et. al.            Standards Track                     [Page 7]

RFC 3308                L2TP Diffserv Extension            November 2002

etカルフーン、アル。 規格はL2TP Diffserv拡大2002年11月にRFC3308を追跡します[7ページ]。

10. IANA Considerations

10. IANA問題

   This document defines 2 L2TP Differentiated Services Extension AVPs.
   The IANA has assigned the value of 47 for the "CCDS AVP" defined in
   section 5.1 and the value of 48 for SDS AVP defined in section 6.1.

このドキュメントは2L2TP Differentiated Services Extension AVPsを定義します。 IANAは"CCDS AVP"のためのセクション5.1で定義された47の値とSDS AVPのためのセクション6.1で定義された48の値を割り当てました。

   IANA has also assigned L2TP Result Code values of 8 for disconnecting
   control connection due to mismatching CCDS value (StopCCN), and 12
   for disconnecting call due to mismatching SDS value (CDN).

また、IANAはCCDS値(StopCCN)にミスマッチするのによるコントロール接続を外すために8の値をL2TP Result Codeに割り当てました、そして、SDS値(CDN)にミスマッチするため連絡を断つための12は呼びます。

11. Security Considerations

11. セキュリティ問題

   This encoding in itself raises no security issues.  However, users of
   this encoding should consider that modifying a DSCP MAY constitute
   theft or denial of service, so protocols using this encoding MUST be
   adequately protected.  No new security issues beyond those discussed
   in [RFC 2474] and [RFC 2475] are introduced here.

このコード化は本来安全保障問題を全く提起しません。 しかしながら、このコード化のユーザが、DSCP MAYを変更するとサービスの窃盗か否定が構成されると考えるべきであるので、適切にこのコード化を使用するプロトコルを保護しなければなりません。 [RFC2474]と[RFC2475]で議論したものを超えたどんな新しい安全保障問題もここで紹介されません。

12. Acknowledgements

12. 承認

   Many thanks to David Black, W. Mark Townsley, Nishit Vasavada, Andy
   Koscinski and John Shriver for their review and insightful feedback.

彼らのレビューと洞察に満ちたフィードバックのためにデヴィッドBlack、W.マークTownsley、Nishit Vasavada、アンディKoscinski、およびジョン・シュライバーをありがとうございます。

13. References

13. 参照

   [RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
              RFC 1661, July 1994.

[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。

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

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

   [RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black "Definition
              of the Differentiated Services Field (DS Field) in the
              IPv4 and IPv6 Headers", RFC 2474, December 1998.

[RFC2474] ニコルズとK.とブレークとS.とベイカーとF.とD.の黒い「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」、RFC2474、1998年12月。

   [RFC 2475] Blake, S., Black, D., Carlson, Z., Davies, E., Wang, Z.
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

[RFC2475] ブレークとS.と黒とD.とカールソンとZ.とデイヴィースとE.とワングとZ.とW.ウィス、「微分されたサービスのための構造」、RFC2475、1998年12月。

   [RFC 2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
              and B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661,
              August 1999.

Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.があしらう[RFC2661]、「層2はプロトコル(L2TP)にトンネルを堀ります」、RFC2661、1999年8月。

   [RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC
              2983, October 2000.

[RFC2983] 黒(D.)が「サービスとトンネルを微分した」、RFC2983、10月2000日

Calhoun, et. al.            Standards Track                     [Page 8]

RFC 3308                L2TP Diffserv Extension            November 2002

etカルフーン、アル。 規格はL2TP Diffserv拡大2002年11月にRFC3308を追跡します[8ページ]。

   [RFC 3140] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur,
              "Per Hop Behavior Identification Codes", RFC 3140, June
              2001.

[RFC3140]は黒くします、縁、S.、大工、B.、およびF.Le Faucheur、D.、「ホップ振舞い識別コード」単位で、RFC3140、2001年6月。

14. Authors' Addresses

14. 作者のアドレス

   Pat R. Calhoun
   110 Nortech Parkway
   San Jose, CA 95134-2307

Nortech Parkwayサンノゼ、パットR.Calhoun110カリフォルニア95134-2307

   Phone: +1 408.941.0500
   EMail: pcalhoun@bstormnetworks.com

以下に電話をしてください。 +1 408.941 .0500 メール: pcalhoun@bstormnetworks.com

   Wei Luo
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134

ウェイ羅シスコシステムズInc.170の西タスマン・Driveサンノゼ、カリフォルニア 95134

   Phone: +1 408.525.6906
   EMail: luo@cisco.com

以下に電話をしてください。 +1 408.525 .6906 メール: luo@cisco.com

   Danny McPherson
   TCB

ダニーマクファーソンTCB

   Phone: +1 303.470.9257
   EMail: danny@tcb.net

以下に電話をしてください。 +1 303.470 .9257 メール: danny@tcb.net

   Ken Peirce
   Malibu Networks, Inc.
   1107 Investment Blvd, Suite 250
   El Dorado Hills, CA 95762

ケンピアスマリブはカリフォルニア Inc.1107投資Blvd、250のスイートエルドラド丘、95762をネットワークでつなぎます。

   Phone: +1 916.941.8814
   EMail: Ken@malibunetworks.com

以下に電話をしてください。 +1 916.941 .8814 メール: Ken@malibunetworks.com

Calhoun, et. al.            Standards Track                     [Page 9]

RFC 3308                L2TP Diffserv Extension            November 2002

etカルフーン、アル。 規格はL2TP Diffserv拡大2002年11月にRFC3308を追跡します[9ページ]。

15. Full Copyright Statement

15. 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

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

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

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

Calhoun, et. al.            Standards Track                    [Page 10]

etカルフーン、アル。 標準化過程[10ページ]