RFC5331 日本語訳
5331 MPLS Upstream Label Assignment and Context-Specific Label Space.R. Aggarwal, Y. Rekhter, E. Rosen. August 2008. (Format: TXT=30779 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Aggarwal
Request for Comments: 5331 Juniper Networks
Category: Standards Track Y. Rekhter
Juniper Networks
E. Rosen
Cisco Systems, Inc.
August 2008
Aggarwalがコメントのために要求するワーキンググループR.をネットワークでつないでください: 5331年の杜松はカテゴリをネットワークでつなぎます: 規格はE.ローゼンシスコシステムズInc.2008年8月にY.Rekhter杜松ネットワークを追跡します。
MPLS Upstream Label Assignment and Context-Specific Label Space
MPLSの上流のラベル課題と文脈特有のラベルスペース
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space".
RFC3031はMPLS構造を川下で割り当てられたMPLSラベルに制限します。 このドキュメントは上流へ割り当てられたMPLSラベルの概念を紹介します。 それは、上流のMPLSラベル課題のための手順について説明して、「文脈特有のラベルスペース」の概念を紹介します。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification of Requirements ...................................2
3. Context-Specific Label Space ....................................2
4. Upstream Label Assignment .......................................3
4.1. Upstream-Assigned and Downstream-Assigned Labels ...........4
5. Assigning Upstream-Assigned Labels ..............................5
6. Distributing Upstream-Assigned Labels ...........................5
7. Upstream Neighbor Label Space ...................................6
8. Context Label on LANs ...........................................9
9. Usage of Upstream-Assigned Labels ..............................10
10. Security Considerations .......................................10
11. Acknowledgements ..............................................11
12. References ....................................................11
12.1. Normative References .....................................11
12.2. Informative References ...................................11
1. 序論…2 2. 要件の仕様…2 3. 文脈特有のラベルスペース…2 4. 上流のラベル課題…3 4.1. 上流へ割り当てられて川下で割り当てられたラベル…4 5. 上流へ割り当てられたラベルを割り当てます…5 6. 上流へ割り当てられたラベルを分配します…5 7. 上流の隣人はスペースをラベルします…6 8. LANの文脈ラベル…9 9. 上流へ割り当てられたラベルの使用法…10 10. セキュリティ問題…10 11. 承認…11 12. 参照…11 12.1. 標準の参照…11 12.2. 有益な参照…11
Aggarwal, et al. Standards Track [Page 1] RFC 5331 August 2008
Aggarwal、他 規格は2008年8月にRFC5331を追跡します[1ページ]。
1. Introduction
1. 序論
RFC 3031 [RFC3031] limits the MPLS architecture to downstream- assigned MPLS labels. To quote from RFC 3031:
RFC3031[RFC3031]はMPLS構造を川下の割り当てられたMPLSラベルに制限します。 RFC3031から引用するために:
"In the MPLS architecture, the decision to bind a particular label L to a particular Forwarding Equivalence Class (FEC) F is made by the Label Switching Router (LSR) which is DOWNSTREAM with respect to that binding. The downstream LSR then informs the upstream LSR of the binding. Thus labels are "downstream-assigned", and label bindings are distributed in the "downstream to upstream" direction."
「MPLS構造では、特定のラベルLを特定のForwarding Equivalence Class(FEC)Fまで縛るという決定はその結合に関するDOWNSTREAMであるLabel Switching Router(LSR)によってされます。」 そして、川下のLSRは結合について上流のLSRに知らせます。 「その結果、ラベルは「川下で割り当てられます」、そして、ラベル結合は「上流への川下」方向に広げられます。」
This document introduces the notion of upstream-assigned MPLS labels to the MPLS architecture. The procedures for upstream assignment of MPLS labels are described.
このドキュメントは上流へ割り当てられたMPLSラベルの概念をMPLS構造に取り入れます。 MPLSラベルの上流の課題のための手順は説明されます。
RFC 3031 describes per-platform and per-interface label space. This document generalizes the latter to a "Context-Specific Label Space" and describes a "Neighbor Label Space" as an example of this. Upstream-assigned labels are always looked up in a context-specific label space.
RFC3031はプラットホームとインタフェースあたりのラベルスペースについて説明します。 このドキュメントは、「文脈特有のラベルスペース」に後者を一般化して、「隣人ラベルスペース」をこの例として記述します。 上流へ割り当てられたラベルは文脈特有のラベルスペースでいつも調べられます。
2. Specification of Requirements
2. 要件の仕様
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Context-Specific Label Space
3. 文脈特有のラベルスペース
RFC 3031 describes per-platform and per-interface label spaces. This document introduces the more general concept of a "Context-Specific Label Space". An LSR may maintain one or more context-specific label spaces. In general, labels MUST be looked up in the per-platform label space unless something about the context determines that a label be looked up in a particular context-specific label space.
RFC3031はプラットホームとインタフェースあたりのラベル空間について説明します。 このドキュメントは「文脈特有のラベルスペース」の、より一般的な概念を紹介します。 LSRは1つ以上の文脈特有のラベル空間を維持するかもしれません。 一般に、文脈に関する何かが、ラベルが特定の文脈特有のラベルスペースで調べられることを決定しない場合、1プラットホームあたりのラベルスペースでラベルを調べなければなりません。
One example of a context-specific label space is the per-interface label space discussed in RFC 3031. When an MPLS packet is received over a particular interface, the top label of the packet may need to be looked up in the receiving interface's per-interface label space. In this case, the receiving interface is the context of the packet. Whether MPLS packets received over a particular interface need to have their top labels looked up in a per-interface label space depends on some characteristic or configuration of the interface.
1インタフェースあたり文脈特有のラベルスペースに関する1つの例がRFC3031で議論したラベルスペースです。 特定のインタフェースの上にMPLSパケットを受け取るとき、パケットのトップラベルは、受信インタフェースの1インタフェースあたりのラベルスペースで調べられる必要があるかもしれません。 この場合、受信インタフェースはパケットの文脈です。 特定のインタフェースの上に受け取られたMPLSパケットが、1インタフェースあたり1つのラベルスペースでそれらのトップラベルを調べさせる必要であるかどうかインタフェースの何らかの特性か構成に依存します。
Aggarwal, et al. Standards Track [Page 2] RFC 5331 August 2008
Aggarwal、他 規格は2008年8月にRFC5331を追跡します[2ページ]。
Per-interface label space [RFC3031] is an example of a context- specific label space used for downstream-assigned labels. Context- specific label spaces can also be used for upstream-assigned labels, as described below.
1インタフェースあたりのラベルスペース[RFC3031]は川下で割り当てられたラベルに使用される文脈の特定のラベルスペースに関する例です。 また、上流へ割り当てられたラベルに以下で説明されるように文脈の特定のラベル空間を使用できます。
When MPLS labels are upstream-assigned, the context of an MPLS label L is provided by the LSR that assigns the label and binds the label to a FEC F for a Label Switched Path (LSP) LSP1. The LSR that assigns the label distributes the binding and context to an LSR Lr that then receives MPLS packets on LSP1 with label L. When Lr receives an MPLS packet on LSP1, it MUST be able to determine the context of this packet.
MPLSラベルが上流へ割り当てられるとき、MPLSラベルLの文脈はLabel Switched Path(LSP)LSP1でFEC Fにラベルを割り当てて、ラベルを縛るLSRによって提供されます。 ラベルを割り当てるLSRは結合を広げます、そして、次にラベルL.When Lrと共にLSP1でMPLSパケットを受けるLSR Lrへの文脈はLSP1でMPLSパケットを受けます、そして、それはこのパケットの文脈を決定できなければなりません。
An example of such a context is a tunnel over which MPLS packets on LSP1 may be received. In this case, the top label of the MPLS packet, after tunnel decapsulation, is looked up in a label space that is specific to the root of the tunnel. This does imply that Lr be able to determine the tunnel over which the packet was received. Therefore, if the tunnel is an MPLS tunnel, penultimate-hop-popping (PHP) MUST be disabled for the tunnel.
そのような文脈に関する例はLSP1の上のMPLSパケットが受け取られるかもしれないトンネルです。 この場合、MPLSパケットのトップラベルはトンネル被膜剥離術の後にトンネルの根に特定のラベルスペースで調べられます。 これは、Lrがパケットが受け取られたトンネルを決定できるのを含意します。 したがって、トンネルがMPLSトンネルであるなら、終わりから二番目のホップの飛び出し(PHP)をトンネルに無能にしなければなりません。
Another example of such a context is the neighbor from which MPLS packets on LSP1 may be received. In this case, the top label of the MPLS packet, transmitted by the neighbor on LSP1, is looked up in a "Neighbor-Specific Label Space".
そのような文脈に関する別の例はLSP1の上のMPLSパケットが受け取られるかもしれない隣人です。 この場合、LSP1で隣人によって伝えられたMPLSパケットのトップラベルは「隣人特有のラベルスペース」で調べられます。
The above two examples are further described in Section 7.
上記の2つの例がセクション7でさらに説明されます。
There may be other sorts of contexts as well. For instance, we define the notion of an MPLS label being used to establish a context, i.e., identify a label space. A "context label" is one that identifies a label table in which the label immediately below the context label should be looked up. A context label carried as an outermost label over a particular multi-access subnet/tunnel MUST be unique within the scope of that subnet/tunnel.
また、他の種類の文脈があるかもしれません。 例えば、私たちは文脈を証明するのに使用されるMPLSラベルの概念を定義します、すなわち、ラベルスペースを特定してください。 「文脈ラベル」は文脈ラベルのすぐ下のラベルが見上げられるべきであるラベルテーブルを特定するものです。 特定のマルチアクセスサブネット/トンネルの上の一番はずれのラベルがそのサブネット/トンネルの範囲の中でユニークであるに違いないので、文脈ラベルは運ばれました。
4. Upstream Label Assignment
4. 上流のラベル課題
When two MPLS LSRs are adjacent in an MPLS Label Switched Path (LSP), one of them can be termed an "upstream LSR" and the other a "downstream LSR" [RFC3031]. Consider two LSRs, Ru and Rd, that have agreed to bind Label L to a FEC F for packets sent from Ru to Rd. Then, with respect to this binding, Ru is the "upstream LSR", and Rd is the "downstream LSR"."
2MPLS LSRsがMPLS Label Switched Path(LSP)で隣接しているとき、「上流のLSR」ともう片方の「川下のLSR」[RFC3031]と彼らのひとりを呼ぶことができます。 Ruから通りに送られたパケットでFEC FにLabel Lを縛るために同意されて、そうした2LSRs、Ru、およびRdを考えてください。 「次に、この結合に関して、Ruは「上流のLSR」です、そして、Rdは「川下のLSR」です。」
If the binding between L and F was made by Rd and advertised to Ru, then the label binding is known as "downstream-assigned". RFC 3031 only discusses downstream-assigned label bindings.
LとFの間の結合がRdによって作られていて、Ruに広告に掲載されたなら、ラベル結合は「川下で割り当てられる」として知られています。 RFC3031は川下で割り当てられたラベル結合について議論するだけです。
Aggarwal, et al. Standards Track [Page 3] RFC 5331 August 2008
Aggarwal、他 規格は2008年8月にRFC5331を追跡します[3ページ]。
If the binding between L and F was made by Ru and advertised to Rd, then the label binding is known as "upstream-assigned".
LとFの間の結合がRuによって作られていて、Rdに広告に掲載されたなら、ラベル結合は「上流へ割り当てられる」として知られています。
If the binding between L and F was made by a third party, say R3, and then advertised to both Ru and Rd, we also refer to the label binding as "upstream-assigned".
また、LとFの間の結合は第三者によってされました、とR3が言って、RuとRdがその時両方に広告を出したなら、私たちは「上流へ割り当てられる」として固まるラベルについて言及します。
An important observation about upstream-assigned labels is the following. When an upstream-assigned label L is at the top of the label stack, it must be looked up by an LSR that is not the LSR that assigned and distributed the label binding for L. Therefore, an upstream-assigned label MUST always be looked up in a context- specific label space, as described in Section 7.
上流へ割り当てられたラベルの周りの重要な観測は以下です。 上流へ割り当てられたラベルLがラベルスタックの先端にあるとき、L.Thereforeで固まるラベルを割り当てて、分配したLSRでないLSRはそれを見上げなければならなくて、文脈の特定のラベルスペースで上流へ割り当てられたラベルをいつも調べなければなりません、セクション7で説明されるように。
We do not require any coordination between the upstream label assignments and the downstream label assignments; a particular label value may be upstream-assigned to one FEC and downstream-assigned to a different FEC.
私たちは上流のラベル課題と川下のラベル課題の間の少しのコーディネートも必要としません。 特定のラベル値は、上流へ1FECに割り当てられて川下で異なったFECに割り当てられるかもしれません。
The ability to use upstream-assigned labels is an OPTIONAL feature. Upstream-assigned labels MUST NOT be used unless it is known that the downstream LSR supports them.
上流へ割り当てられたラベルを使用する能力はOPTIONALの特徴です。 川下のLSRがそれらを支持するのが知られていない場合、上流へ割り当てられたラベルを使用してはいけません。
One use case of upstream-assigned labels is MPLS multicast, and an example of this is provided in Section 9.
上流へ割り当てられることのケースがラベルする1つの使用がMPLSマルチキャストです、そして、この例をセクション9に提供します。
4.1. Upstream-Assigned and Downstream-Assigned Labels
4.1. 上流へ割り当てられて川下で割り当てられたラベル
It is possible that some LSRs on an LSP for FEC F distribute downstream-assigned label bindings for FEC F, while other LSRs distribute upstream-assigned label bindings. It is possible for an LSR to distribute a downstream-assigned label binding for FEC F to its upstream adjacent LSR AND distribute an upstream-assigned label binding for FEC F to its downstream adjacent LSR. When two LSRs, Ru and Rd, are adjacent on an LSP for FEC F (with Ru being the upstream neighbor and Rd the downstream neighbor), either Ru distributes an upstream-assigned label binding for F to Rd, or else Rd distributes a downstream-assigned label binding to Ru, but NOT both. Whether upstream-assigned or downstream-assigned labels are to be used for a particular FEC depends on the application using the LSP.
FEC FのためのLSPの上のいくつかのLSRsがFEC Fのために川下で割り当てられたラベル結合を広げるのは、可能です、他のLSRsが上流へ割り当てられたラベル結合を広げますが。 LSRがFEC Fで上流に固まる川下で割り当てられたラベルを分配するように、隣接しているLSR ANDがFEC Fで川下の隣接しているLSRに固まる上流へ割り当てられたラベルを分配するのは、可能です。 FEC F(上流の隣人と川下の隣人のRdであるRuでの)において、2LSRs(RuとRd)がLSPで隣接しているとき、RuがFでRdに固まる上流へ割り当てられたラベルを分配するか、またはRdはRuに付きますが、ともに付くというわけではない川下で割り当てられたラベルを分配します。 上流へ割り当てられたか川下で割り当てられたラベルが特定のFECに使用されることになっているかどうかが、LSPを使用することでアプリケーションによります。
Any application that requires the use of upstream-assigned labels MUST specify that explicitly, or else it is to be assumed that downstream-assigned labels are used. An application on an LSR uses a label distribution protocol to indicate to its peer LSRs whether a particular label binding distributed by the LSR uses upstream- assigned or downstream-assigned label. Details of such procedures are outside the scope of this document. In some cases, the decision
上流へ割り当てられたラベルの使用を必要とするどんなアプリケーションも、または、明らかに、川下で割り当てられたラベルが使用されていると思われることになっていると指定しなければなりません。 LSRにおけるアプリケーションは結合が用途上流が割り当てたLSRで分配した特定のラベルか川下で割り当てられたラベルであることにかかわらず同輩LSRsに示すラベル分配プロトコルを使用します。 このドキュメントの範囲の外にそのような手順の詳細があります。 いくつかの場合決定
Aggarwal, et al. Standards Track [Page 4] RFC 5331 August 2008
Aggarwal、他 規格は2008年8月にRFC5331を追跡します[4ページ]。
as to which is used for a particular application may be made by a configuration option.
どれが特定用途に使用されるかに関して、設定オプションで作られているかもしれません。
5. Assigning Upstream-Assigned Labels
5. 上流へ割り当てられたラベルを割り当てます。
The only requirement on an upstream LSR assigning upstream-assigned labels is that an upstream-assigned label must be unambiguous in the context-specific label space in which the downstream LSR will look it up. An upstream LSR that is the headend of multiple tunnels SHOULD, by default, assign the upstream-assigned labels, for all the LSPs carried over these tunnels, from a single label space, which is common to all those tunnels. Further, an upstream LSR that is the head of multiple tunnels SHOULD use the same IP address as the head identifier of these tunnels, provided that the head identifier of these tunnels includes an IP address. The LSR could assign the same label value to both a downstream-assigned and an upstream-assigned label. The downstream LSR always looks up upstream-assigned MPLS labels in a context-specific label space as described in Section 7.
上流へ割り当てられたラベルを割り当てる上流のLSRに関する唯一の要件は上流へ割り当てられたラベルが川下のLSRがそれを見上げる文脈特有のラベルスペースで明白であるに違いないということです。 倍数のヘッドエンドである上流のLSRはSHOULDにトンネルを堀って、デフォルトで、上流へ割り当てられたラベルを割り当ててください、これらのトンネルの上まで運ばれたすべてのLSPsのために、ただ一つのラベルスペースからそれらのすべてのトンネルまで。(スペースは一般的です)。 さらに、倍数のヘッドである上流のLSRは同じIPがこれらのトンネルに関するヘッド識別子として記述するSHOULD使用にトンネルを堀ります、これらのトンネルに関するヘッド識別子がIPアドレスを含んでいれば。 LSRはaが川下で割り当てた両方と上流へ割り当てられたラベルに同じラベル値を割り当てることができました。 川下のLSRはセクション7で説明されるように文脈特有のラベルスペースでいつも上流へ割り当てられたMPLSラベルを見上げます。
An entry for the upstream-assigned labels is not created in the Incoming Label Map (ILM) [RFC3031] at the upstream LSR as these labels are not incoming labels. Instead, an upstream label is an outgoing label, with respect to the upstream LSR, for MPLS packets transmitted on the MPLS LSP in which the upstream LSR is adjacent to the downstream LSR. Hence, an upstream label is part of a Next Hop Label Forwarding Entry (NHLFE) at the upstream LSR.
上流へ割り当てられたラベルのためのエントリーは、これらのラベルが入って来るラベルでないので、上流のLSRのIncoming Label Map(ILM)[RFC3031]で作成されません。 代わりに、上流のラベルは出発しているラベルです、上流のLSRに関して、上流のLSRが川下のLSRに隣接しているMPLS LSPで伝えられたMPLSパケットのために。 したがって、上流のラベルは上流のLSRのNext Hop Label Forwarding Entry(NHLFE)の一部です。
When Ru advertises a binding of label L for FEC F to Rd, it creates a NHLFE entry corresponding to L. This NHLFE entry results in imposing the label L on the MPLS label stack of the packet forwarded using the NHLFE entry. If Ru is a transit router on the LSP for FEC F, it binds the ILM for the LSP to this NHLFE. If Ru is an ingress router on the LSP for FEC F, it binds the FEC to the NHLFE entry.
RuがFEC FのためにラベルLの結合のRdに広告を出すとき、それはNHLFEエントリーを使用することで進められたパケットのMPLSラベルスタックにラベルLを課す際にL.This NHLFEエントリー結果に対応するNHLFEエントリーを作成します。 RuがFEC FのためのLSPの上のトランジットルータであるなら、それはLSPでこのNHLFEにILMを縛ります。 RuがFEC FのためのLSPの上のイングレスルータであるなら、それはNHLFEエントリーにFECを縛ります。
6. Distributing Upstream-Assigned Labels
6. 上流へ割り当てられたラベルを分配します。
Upstream-assigned label bindings MUST NOT be used unless it is known that the downstream LSR supports them. How this is known is outside the scope of this document.
川下のLSRがそれらを支持するのが知られていない場合、上流へ割り当てられたラベル結合を使用してはいけません。 このドキュメントの範囲の外にこれがどう知られているかがあります。
MPLS upstream label assignment requires a label distribution protocol to distribute the binding from the upstream LSR to the downstream LSR. Considerations that pertain to a label distribution protocol that are described in [RFC3031] apply.
MPLSの上流のラベル課題は、上流のLSRから川下のLSRまでの結合を広げるためにラベル分配プロトコルを必要とします。 [RFC3031]で説明されるラベル分配プロトコルに関係する問題が適用されます。
The distribution of the upstream-assigned labels is similar to either the ordered LSP control or independent LSP control of the downstream- assigned labels. In the former case, an LSR distributes an upstream-
上流へ割り当てられたラベルの分配は命令されたLSPコントロールかラベルが割り当てられた川下の独立しているLSPコントロールのどちらかと同様です。 前の場合では、LSRは上流を分配します。
Aggarwal, et al. Standards Track [Page 5] RFC 5331 August 2008
Aggarwal、他 規格は2008年8月にRFC5331を追跡します[5ページ]。
assigned label binding for a FEC F if it is either (a) the ingress LSR for FEC F, or (b) if it has already received an upstream label binding for that FEC from its adjacent upstream LSR for FEC F, or (c) if it has received a request for a downstream label binding from its upstream adjacent LSR. In the latter case, each LSR, upon noting that it recognizes a particular FEC, makes an independent decision to bind an upstream-assigned label to that FEC and to distribute that binding to its label distribution peers.
(c) (b) FEC Fのための(a) イングレスLSRかそれともそれが既にFEC Fのために隣接している上流LSRからそのFECで固まる上流のラベルを受けたかどうかが、どちらかである、または上流の隣接しているLSRから固まる川下のラベルを求める要求を受け取ったなら、FEC Fのためにラベル結合を割り当てました。 後者の場合では、特定のFECを認識することに注意するとき、各LSRは上流へ割り当てられたラベルをそのFECに縛って、それを分配するという独立決議をラベル分配同輩にとって拘束力があるようにします。
7. Upstream Neighbor Label Space
7. 上流の隣人ラベルスペース
If the top label of an MPLS packet being processed by LSR Rd is upstream-assigned, the label is looked up in a context-specific label space, not in a per-platform label space.
LSR Rdによって処理されるMPLSパケットのトップラベルが上流へ割り当てられるなら、ラベルは1プラットホームあたり1つのラベルスペースで見上げられるのではなく、文脈特有のラベルスペースで見上げられます。
Rd uses a context-specific label space that it maintains for Ru to "reserve" MPLS labels assigned by Ru. Hence, if Ru distributes an upstream-assigned label binding L for FEC F to Rd, then Rd reserves L in the separate ILM for Ru's context-specific label space. This is the ILM that Rd uses to look up an MPLS label that is upstream- assigned by Ru. This label may be the top label on the label stack of a packet received from Ru or it may be exposed as the top label on the label stack, as a result of Rd popping one or more labels off the label stack, from such a packet.
RuがRuによって割り当てられたMPLSラベルを「予約する」ようにそれが維持する文脈特有のラベルスペースを第使用します。 したがって、RuがFEC FのためのLをRdに縛る上流へ割り当てられたラベルを分配するなら、Rdは別々のILMでRuの文脈特有のラベルスペースにLを予約します。 これはRdがRuによって割り当てられて、上流であるMPLSラベルを見上げるのに使用するILMです。 このラベルはRuから受け取られたパケットのラベルスタックの上のトップラベルであるかもしれませんかそれはラベルスタックの上のトップラベルであることがばれるかもしれません、ラベルスタックで1個以上のラベルを飛び出させるRdの結果、、そのようなパケットから。
This implies that Rd MUST be able to determine whether the top label of an MPLS packet being processed is upstream-assigned and, if yes, the "context" of this packet. How this determination is made depends on the mechanism that is used by Ru to transmit the MPLS packet with an upstream-assigned top label L to Rd.
これは、Rdが処理されるMPLSパケットのトップラベルが上流へ割り当てられるか、そして、はいこのパケットの「文脈」を決定できなければならないのを含意します。 どうこの決断をするかは上流へ割り当てられたトップラベルLでMPLSパケットを通りに送るのにRuによって使用されるメカニズムによります。
If Ru transmits this packet by encapsulating it in an IP or MPLS tunnel, then the fact that L is upstream-assigned is determined by Rd by the tunnel on which the packet is received. Whether a given tunnel can be used for transmitting MPLS packets with either downstream-assigned or upstream-assigned MPLS labels, or both, depends on the tunnel type and is described in [RFC5332]. When Rd receives MPLS packets with a top label L on such a tunnel, it determines the "context" of this packet based on the tunnel on which the packet is received. There must be a mechanism for Ru to inform Rd that a particular tunnel from Ru to Rd will be used by Ru for transmitting MPLS packets with upstream-assigned MPLS labels. Such a mechanism will be provided by the label distribution protocol between Ru and Rd and will likely require extensions to existing label distribution protocols. The description of such a mechanism is outside the scope of this document.
RuがIPかMPLSトンネルでそれを要約することによってこのパケットを伝えるなら、Lが上流へ割り当てられるという事実はパケットが受け取られているトンネルによってRdによって決定されます。 川下で割り当てられたか上流へ割り当てられたMPLSと共にMPLSパケットを伝えるのに与えられたトンネルを使用できるか否かに関係なく、ラベル、または両方が、トンネルタイプに頼っていて、[RFC5332]で説明されます。 そのようなトンネルの上にトップラベルLがある状態でRdがMPLSパケットを受けるとき、それはパケットが受け取られているトンネルに基づくこのパケットの「文脈」を決定します。 Ruが、特定のRuからRdまでのトンネルが上流へ割り当てられたMPLSラベルでMPLSパケットを伝えるのにRuによって使用されることをRdに知らせるメカニズムがあるに違いありません。 そのようなメカニズムは、ラベル分配プロトコルによってRuとRdの間に提供されて、おそらく既存のラベル分配プロトコルに拡大を必要とするでしょう。 このドキュメントの範囲の外にそのようなメカニズムの記述があります。
Aggarwal, et al. Standards Track [Page 6] RFC 5331 August 2008
Aggarwal、他 規格は2008年8月にRFC5331を追跡します[6ページ]。
Rd maintains an "Upstream Neighbor Label Space" for upstream-assigned labels, assigned by Ru. When Ru transmits MPLS packets the top label of which is upstream-assigned over IP or MPLS tunnels, then Rd MUST be able to determine the root of these IP/MPLS tunnels. Rd MUST then use a separate label space for each unique root.
Ruによって割り当てられた上流へ割り当てられたラベルのために「上流の隣人ラベルスペース」であると第主張します。 Ruがそれのトップラベルが上流へIPかMPLSの上に配属されたトンネルであるMPLSパケットを伝えると、RdはこれらのIP/MPLSトンネルの根を測定できなければなりません。 そして、それぞれのユニークな根に別々のラベルスペースを第使用しなければなりません。
The root is identified by the head-end IP address of the tunnel. If the same upstream router, Ru, uses different head-end IP addresses for different tunnels, then the downstream router, Rd, MUST maintain a different Upstream Neighbor Label Space for each such head-end IP address.
根はトンネルのギヤエンドのIPアドレスによって特定されます。 同じ上流のルータ(Ru)が異なったトンネルに異なったギヤエンドのIPアドレスを使用するなら、川下のルータ(Rd)はそのようなそれぞれのギヤエンドのIPアドレスのために異なったUpstream Neighbor Label Spaceを維持しなければなりません。
Consider the following conditions:
以下の条件を考えてください:
1) Ru is the "root" of two tunnels, call them A and B.
1) Ruは2の「根」トンネルであり、それらをAとBと呼んでください。
2) IP address X is an IP address of Ru.
2) IPアドレスXはRuのIPアドレスです。
3) The signaling protocol used to set up tunnel A identified A's
root node as IP address X.
3) トンネルAを設立するのに使用されるシグナリングプロトコルは、Aの根のノードがIPアドレスXであると認識しました。
4) The signaling protocol used to set up tunnel B identified B's
root node as IP address X.
4) トンネルBを設立するのに使用されるシグナリングプロトコルは、ビーズ根のノードがIPアドレスXであると認識しました。
5) Packets sent through tunnels A and B may be carrying upstream-
assigned labels.
5) トンネルAを通して送られたパケットとBはラベルが割り当てられた上流を運んでいるかもしれません。
6) Ru is the LSR that assigned the upstream-assigned labels
mentioned in condition 5.
6) Ruは状態5で言及された上流へ割り当てられたラベルを割り当てたLSRです。
If and only if these conditions hold, then Ru MUST use the same label space when upstream-assigning labels for packets that travel through tunnel A that it uses when upstream-assigning labels for packets that travel through tunnel B.
そして、トンネルBを通るその旅行をパケットのためのラベルに上流へ割り当てるときそれが使用するトンネルAを通るその旅行をパケットのためのラベルに上流へ割り当てるとき、これらの状態が成立する場合にだけ、Ruは同じラベルスペースを使用しなければなりません。
Suppose that Rd is a node that belongs to tunnels A and B, but is not the root node of either tunnel. Then Rd may assume that the same upstream-assigned label space is used on both tunnels IF AND ONLY IF the signaling protocol used to set up tunnel A identified the root node as IP address X and the signaling protocol used to set up tunnel B identified the root node as the same IP address X.
RdがトンネルAとBに属すノードですが、どちらかのトンネルの根のノードでないと仮定してください。 そして、Rdは、シグナリングプロトコルが以前はよくトンネルAを設立していただけであるならANDが、根のノードがIPアドレスXであると認識して、トンネルBを設立するのに使用されるシグナリングプロトコルが、根のノードが同じIPアドレスXであると認識したなら同じ上流へ割り当てられたラベルスペースが両方のトンネルの上で使用されると仮定するかもしれません。
In addition, the protocol that is used for distributing the upstream- assigned label to be used over a particular tunnel MUST identify the "assigner" using the same IP address that is used by the protocol that sets up the tunnel to identify the root node of the tunnel. Implementors must take note of this, even if the tunnel setup
さらに、トンネルの根のノードを特定するためにトンネルを設立するプロトコルによって使用されるのと同じIPアドレスを使用して、特定のトンネルの上で使用されるために上流の割り当てられたラベルを分配するのに使用されるプロトコルは「指定人」を特定しなければなりません。 トンネルがセットアップされても、作成者はこれに注目しなければなりません。
Aggarwal, et al. Standards Track [Page 7] RFC 5331 August 2008
Aggarwal、他 規格は2008年8月にRFC5331を追跡します[7ページ]。
protocol is different from the protocol that is used for distributing the upstream-assigned label to be used over the tunnel.
プロトコルはトンネルの上で使用されるために上流へ割り当てられたラベルを分配するのに使用されるプロトコルと異なっています。
The precise set of procedures for identifying the IP address of the root of the tunnel depend, of course, on the protocol used to set up the tunnel. For Point-to-Point (P2P) tunnels, the intention is that the headend of the tunnel is the "root". For Point-to-Multipoint (P2MP) or Multipoint-to-Multipoint (MP2MP) tunnels, one can always identify one node as being the "root" of the tunnel.
トンネルの根のIPアドレスを特定するための正確なセットの手順はもちろんトンネルを設立するのに使用されるプロトコルに依存します。 Pointからポイント(P2P)へのトンネルに関しては、意志はトンネルのヘッドエンドが「根」であるということです。 MultipointからPointから多点(P2MP)か多点(MP2MP)へのトンネルに関しては、1つはトンネルの「根」であるとしていつも1つのノードを特定できます。
Some tunnels may be set up by configuration, rather than by signaling. In these cases, the IP address of the root of the tunnel must be configured.
いくつかのトンネルがシグナリングでというよりむしろ構成によって設立されるかもしれません。 これらの場合では、トンネルの根のIPアドレスを構成しなければなりません。
Some tunnels may not even require configuration, e.g., a Generic Routing Encapsulation (GRE) tunnel can be "created" just by encapsulating packets and transmitting them. In such a case, the IP address of the root is considered to be the IP source address of the encapsulated packets.
いくつかのトンネルは構成(例えばルート設定Encapsulation(GRE)がパケットをカプセルに入れるだけで「作成でき」て、それらを伝えながらトンネルを堀るGeneric)を必要とさえしないかもしれません。 このような場合には、根のIPアドレスは要約のパケットのIPソースアドレスであると考えられます。
If the tunnel on which Rd receives MPLS packets with a top label L is an MPLS tunnel, then Rd determines a) that L is upstream-assigned and b) the context for L, from the labels above L in the label stack. Note that one or more of these labels may also be upstream-assigned labels.
RdがトップラベルLでMPLSパケットを受けるトンネルがMPLSトンネルであるなら、Rdは、Lのためにa) そのLが上流へ割り当てられて、文脈がb)が割り当てられることを決定します、ラベルスタックのLの上のラベルから。 また、これらのラベルの1つ以上が上流へ割り当てられたラベルであるかもしれないことに注意してください。
If the tunnel on which Rd receives MPLS packets with a top label L is an IP/GRE tunnel, then Rd determines a) that L is upstream-assigned [RFC5332] and b) the context for L, from the source address in the IP header.
RdがトップラベルLでMPLSパケットを受けるトンネルがIP/GREトンネルであるなら、Rdは、Lをあるa)が[RFC5332]とb)にLのための文脈を上流へ割り当てたことを決定します、IPヘッダーのソースアドレスから。
When Ru and Rd are adjacent to each other on a multi-access data link media, if Ru would transmit the packet, with top label L, by encapsulating it in a data link frame, then whether L is upstream- assigned or downstream assigned can be determined by Rd, as described in [RFC5332]. This is possible because if L is upstream-assigned, then [RFC5332] uses a different ether type in the data link frame. However, this is not sufficient for Rd to determine the context of this packet. In order for Rd to determine the context of this packet, Ru encapsulates the packet in a one-hop MPLS tunnel. This tunnel uses an MPLS context label that is assigned by Ru. Section 8 describes how the context label is assigned. Rd maintains a separate "Upstream Neighbor Label Space" for Ru. The "context" of this packet, i.e., Ru's upstream neighbor label space, in which L was reserved, is determined by Rd from the top context label and the interface on which the packet is received. The ether type in the data link frame is set to indicate that the top label is upstream- assigned. The second label in the stack is L.
Rdは[RFC5332]で説明されるようにいつ、互いに隣接してデータ・リンクメディア、次に、Lが割り当てられた状態で上流であるか否かに関係なく、RuがトップラベルLでデータ・リンクフレームでそれを要約することによってパケットを伝えるだろうか、そして、または川下が割り当てたマルチアクセスにはRuとRdがあるか決定できます。 Lが上流へ割り当てられるなら[RFC5332]がデータ・リンクフレームで異なったエーテル型を使用するので、これは可能です。 しかしながら、Rdがこのパケットの文脈を決定するように、これは十分ではありません。 Rdがこのパケットの文脈を決定するように、RuはワンバウンドのMPLSトンネルでパケットをカプセルに入れります。 このトンネルはRuによって割り当てられるMPLS文脈ラベルを使用します。 セクション8は文脈ラベルがどう割り当てられるかを説明します。 Ruのために別々の「上流の隣人ラベルスペース」であると第主張します。 このパケットの「文脈」(すなわち、Ruの上流の隣人ラベルスペース)はトップ文脈ラベルからのRdとパケットが受け取られているインタフェースのそばで断固としています。(そこでは、Lが予約されました)。 データ・リンクフレームのエーテル型はトップラベルが割り当てられた状態で上流であることを示すように用意ができています。 スタックにおける2番目のラベルはLです。
Aggarwal, et al. Standards Track [Page 8] RFC 5331 August 2008
Aggarwal、他 規格は2008年8月にRFC5331を追跡します[8ページ]。
8. Context Label on LANs
8. LANの文脈ラベル
For a labeled packet with an ether type of "upstream label assignment", the top label is used as the context. The context label value is assigned by the upstream LSR and advertised to the downstream LSRs. Mechanisms for advertising the context label will be provided by the label distribution protocol between the upstream and downstream LSRs. The description of such a mechanism is outside the scope of this document.
「上流のラベル課題」のエーテル型がいるラベルされたパケットのために、トップラベルは文脈として使用されます。 文脈ラベル価値を上流のLSRが割り当てて、川下のLSRsに広告を出します。 上流の、そして、川下のLSRsの間のラベル分配プロトコルは文脈ラベルの広告を出すためのメカニズムを提供するでしょう。 このドキュメントの範囲の外にそのようなメカニズムの記述があります。
The context label assigned by an LSR for use on a particular LAN interface MUST be unique across all the context labels assigned by other LSRs for use on the same LAN. When a labeled packet is received from the LAN, the context label MUST be looked up in the context of the LAN interface on which the packet is received.
特定のLANインタフェースにおける使用のためにLSRによって割り当てられた文脈ラベルは同じLANにおける使用のために他のLSRsによって割り当てられたすべての文脈ラベルの向こう側にユニークであるに違いありません。 LANからラベルされたパケットを受け取るとき、パケットが受け取られているLANインタフェースの文脈で文脈ラベルを調べなければなりません。
This document provides two methods that an LSR can use to choose a context label to advertise on a particular LAN.
このドキュメントはLSRが特定のLANに広告を出すために文脈ラベルを選ぶのに使用できる2つの方法を提供します。
The first method requires that each LSR be provisioned with a 20-bit context label for each LAN interface on which a context label is required. It is then left to the provisioning system to make sure that an assigned context label is unique across the corresponding LAN.
最初の方法は、各LSRが20ビットの文脈ラベルで文脈ラベルが必要であるそれぞれのLANインタフェースに食糧を供給されるのを必要とします。 そして、それが割り当てられた文脈ラベルが確実に対応するLANの向こう側にユニークになるようにするのが食糧を供給するシステムに残されます。
The second method allows the context labels to be auto-generated, but is only applicable if each LSR on the LAN has an IPv4 address as its primary IP address for the corresponding LAN interface. (If the LAN contains LSRs that have only IPv6 addresses for the LAN interface, then the first method is used.)
2番目の方法は、文脈ラベルが自動発生しているのを許容しますが、LANの各LSRに対応するLANインタフェースへの第一のIPアドレスとしてIPv4アドレスがある場合にだけ、適切です。 (LANがLANインタフェースへのIPv6アドレスしか持っていないLSRsを含んでいるなら、最初の方法は使用されています。)
Suppose that each LAN interface is configured with a primary IPv4 address that is unique on that LAN. The host part of the IPv4 address, identified by the network mask, is unique. If the IPv4 network mask is greater than 12 bits, it is possible to map the remaining 20 bits into a unique context label value. This enables the LSRs on the LAN to automatically generate a unique context label. To ensure that auto-generated context label values do not fall into the reserved label space range [RFC3032], the value of the host part of the IPv4 address is offset with 0x10, if this value is not greater than 0xFFFEF. Values of the host part of the IPv4 address greater than 0xFFFEF are not allowed to be used as context labels.
それぞれのLANインタフェースがそのLANでユニークな第一のIPv4アドレスによって構成されると仮定してください。 ネットワークマスクによって特定されたIPv4アドレスのホスト部分はユニークです。 IPv4ネットワークマスクが12ビット以上であるなら、ユニークな文脈ラベル価値に残っている20ビットを写像するのは可能です。 これは、LANのLSRsがユニークな文脈ラベルを自動的に発生させるのを可能にします。 自動発生している文脈ラベル値が予約されたラベルスペース範囲[RFC3032]に落ちないのを保証するために、IPv4アドレスのホスト部分の値は0×10で相殺されます、この値が0xFFFEFほど大きくないなら。 0xFFFEFよりすばらしいIPv4アドレスのホスト部分の値は文脈ラベルとして使用できません。
Consider LSR Rm (downstream) connected to Ru1 (upstream) on a LAN interface and to Ru2 (upstream) on a different LAN interface. Rm could receive a context label value derived from the LAN interface from Ru1 and from Ru2. It is possible that the context label values used by Ru1 and Ru2 are the same. This would occur if the LAN
LANインタフェースのRu1(上流へ)と、そして、異なったLANインタフェースのRu2(上流へ)に接続されたLSR Rm(川下)を考えてください。 RmはLANインタフェースからRu1とRu2から得られた文脈ラベル価値を受けることができました。 Ru1とRu2によって使用された文脈ラベル値が同じであることは、可能です。 これはLANであるなら起こるでしょう。
Aggarwal, et al. Standards Track [Page 9] RFC 5331 August 2008
Aggarwal、他 規格は2008年8月にRFC5331を追跡します[9ページ]。
interfaces of both Ru1 and Ru2 are configured with a primary IPv4 address where the lowest 20 bits are equal. However, this does not create any ambiguity, as it has already been stated that the context label MUST be looked up in the context of the LAN interface on which the packet is received.
Ru1とRu2の両方のインタフェースは最も低い20ビットが等しい第一のIPv4アドレスによって構成されます。 しかしながら、これは少しのあいまいさも作成しません、パケットが受け取られているLANインタフェースの文脈で文脈ラベルを調べなければならないと既に述べられていたとき。
9. Usage of Upstream-Assigned Labels
9. 上流へ割り当てられたラベルの使用法
A typical use case of upstream-assigned labels is for MPLS multicast and is described here for illustration. This use case arises when an upstream LSR Ru is adjacent to several downstream LSRs <Rd1...Rdn> in an LSP, LSP1 AND Ru is connected to <Rd1...Rdn> via a multi-access media or tunnel, AND Ru wants to transmit a single copy of an MPLS packet on the LSP to <Rd1...Rdn>. In the case of a tunnel, Ru can distribute an upstream-assigned label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and transmit an MPLS packet, the top label of which is L, on the tunnel. In the case of a multi-access media, Ru can distribute an upstream-assigned label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and transmit an MPLS packet, the top label of which is the context label that identifies Ru, and the label immediately below is L, on the multi-access media. Each of <Rd1..Rdn> will then interpret this MPLS packet in the context of Ru and forward it appropriately. This implies that <Rd1..Rdn> MUST all be able to support an Upstream Neighbor Label Space for Ru and Ru MUST be able to determine this. The mechanisms for determining this are specific to the application that is using upstream-assigned labels and is outside the scope of this document.
上流へ割り当てられることのケースがラベルする典型的な使用は、MPLSマルチキャストのためにあって、イラストのためにここで説明されます。 この使用、上流のLSR Ruが数個の川下のLSRs<Rd1に隣接しているとき、ケースは起こります…LSPのRdn>、LSP1 AND Ruは<Rd1に接続されます…マルチアクセスメディアかトンネルを通るRdn>、AND RuはLSPでMPLSパケットのただ一つのコピーを<Rd1に伝えたがっています…Rdn>。 トンネルの場合では、RuはLSP1のためのFEC、<Rd1に制限された上流へ割り当てられたラベルLを分配できます。>をRdnして、トンネルの上でMPLSパケットを送ります。そのトップラベルはLです。 マルチアクセスの場合では、メディアであり、RuはLSP1にFECに向かっている上流へ割り当てられたラベルLを分配できます、<Rd1に。そして、Rdn>、それのトップラベルがRuを特定する文脈ラベルであるMPLSパケットを伝えてください。そうすれば、すぐに以下のラベルはLです、マルチアクセスメディアで。 それぞれの<Rd1。Rdn>は適切に次に、Ruの文脈でこのMPLSパケットを解釈して、それを進めるでしょう。 これはその<Rd1を含意します。Rdn>はRuのためにUpstream Neighbor Label Spaceをすべて支持できなければなりません、そして、Ruはこれを決定できなければなりません。 これを決定するためのメカニズムは上流へ割り当てられたラベルを使用していて、このドキュメントの範囲の外にある利用に特定です。
10. Security Considerations
10. セキュリティ問題
The security considerations that apply to upstream-assigned labels and context labels are no different in kind than those that apply to downstream-assigned labels.
上流へ割り当てられたラベルと文脈ラベルに適用されるセキュリティ問題は川下で割り当てられたラベルに適用されるものと種類において異なっていません。
Note that procedures for distributing upstream-assigned labels and/or context labels are not within the scope of this document. Therefore, the security considerations that may apply to such procedures are not considered here.
このドキュメントの範囲の中に上流へ割り当てられたラベル、そして/または、文脈ラベルを分配するための手順がないことに注意してください。 したがって、そのような手順に適用されるかもしれないセキュリティ問題はここで考えられません。
Section 8 of this document describes a procedure that enables an LSR to automatically generate a unique context label for a LAN. This procedure assumes that the IP addresses of all the LSR interfaces on the LAN will be unique in their low-order 20 bits. If two LSRs whose IP addresses have the same low-order 20 bits are placed on the LAN, other LSRs are likely to misroute packets transmitted to the LAN by either of the two LSRs in question.
このドキュメントのセクション8はLSRがLANのためにユニークな文脈ラベルを自動的に発生させるのを可能にする手順について説明します。 この手順は、LANのすべてのLSRインタフェースのIPアドレスがそれらの下位の20ビットでユニークになると仮定します。 IPアドレスには下位の同じ20ビットがある2LSRsがLANに置かれるなら、他のLSRsが問題の2LSRsのどちらかによってLANに伝えられたmisrouteパケットにありそうです。
Aggarwal, et al. Standards Track [Page 10] RFC 5331 August 2008
Aggarwal、他 規格は2008年8月にRFC5331を追跡します[10ページ]。
More detailed discussion of security issues that are relevant in the context of MPLS and GMPLS, including security threats, related defensive techniques, and the mechanisms for detection and reporting, are discussed in "Security Framework for MPLS and GMPLS Networks [MPLS-SEC].
以上はMPLSの文脈で関連している安全保障問題の議論を詳しく述べました、そして、「MPLSとGMPLSネットワーク[MPLS-SEC]のためのセキュリティフレームワーク」で軍事的脅威、関連する防衛的なテクニック、および検出と報告のためのメカニズムを含むGMPLSについて議論します。
11. Acknowledgements
11. 承認
Thanks to IJsbrand Wijnands's contribution, specifically for the text on which Section 8 is based.
特にセクション8が基づいているテキストのためのIJsbrand Wijnandsの貢献ありがとうございます。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[RFC2119] 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月。
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encpsulations", RFC 5332, August 2008.
2008年8月の[RFC5332]エッケルトとT.とローゼンとE.とAggarwal、R.とY.Rekhter、「MPLSマルチキャストEncpsulations」RFC5332。
12.2. Informative References
12.2. 有益な参照
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3032] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, July 2008.
[MPLS-SEC] 牙、L.、エド、7月2008、「MPLSのためのセキュリティフレームワークとGMPLSネットワーク」は進行中で働いています。
Aggarwal, et al. Standards Track [Page 11] RFC 5331 August 2008
Aggarwal、他 規格は2008年8月にRFC5331を追跡します[11ページ]。
Authors' Addresses
作者のアドレス
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089
Rahul Aggarwal杜松は1194の北のマチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア 94089
EMail: rahul@juniper.net
メール: rahul@juniper.net
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089
ヤコフRekhter Juniperは1194の北のマチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア 94089
EMail: yakov@juniper.net
メール: yakov@juniper.net
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
マサチューセッツ通りBoxborough、エリックC.ローゼンシスコシステムズInc.1414MA 01719
EMail: erosen@cisco.com
メール: erosen@cisco.com
Aggarwal, et al. Standards Track [Page 12] RFC 5331 August 2008
Aggarwal、他 規格は2008年8月にRFC5331を追跡します[12ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を記述してください。
Aggarwal, et al. Standards Track [Page 13]
Aggarwal、他 標準化過程[13ページ]
一覧
スポンサーリンク
