RFC3443 日本語訳
3443 Time To Live (TTL) Processing in Multi-Protocol Label Switching(MPLS) Networks. P. Agarwal, B. Akyol. January 2003. (Format: TXT=18749 bytes) (Updates RFC3032) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Agarwal
Request for Comments: 3443 Brocade
Updates: 3032 B. Akyol
Category: Standards Track Cisco Systems
January 2003
Agarwalがコメントのために要求するワーキンググループP.をネットワークでつないでください: 3443はアップデートを紋織りにします: 3032年のB.Akyolカテゴリ: 標準化過程シスコシステムズ2003年1月
Time To Live (TTL) Processing in
Multi-Protocol Label Switching (MPLS) Networks
生きるマルチプロトコルラベルスイッチング(MPLS)ネットワークで処理される時間(TTL)
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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document describes Time To Live (TTL) processing in hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label Stack Encoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and "pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks.
このドキュメントは、階層的なMulti-プロトコルLabel Switching(MPLS)ネットワークでTime To Live(TTL)処理について説明して、MPLSのための操作のTTL-透過モードのラベルで切り換えられた経路を正式にする必要性によって動機づけられています。 それはRFC3032、「MPLSラベルスタックコード化」をアップデートします。 PipeとUniform Modelの両方で階層的なトンネルを処理するTTLが両方のための「プッシュ」という例で指定されて、ケースを「飛び出させます」。 ドキュメントは、また、RFC3270、「微分されたサービスのMPLSサポート」の補足となって、そのドキュメントでTTL処理で階層的なMPLSネットワークで紹介された用語を結びつけます。
Conventions used in this document
本書では使用されるコンベンション
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は[RFC-2119]で説明されるように本書では解釈されることであるべきですか?
1. Introduction and Motivation
1. 序論と動機
This document describes Time To Live (TTL) processing in hierarchical MPLS networks. We believe that this document adds details that have not been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods presented in this document complement [MPLS-DS].
このドキュメントは階層的なMPLSネットワークでTime To Live(TTL)処理について説明します。 私たちは、このドキュメントが記述されていない詳細を加えて[MPLS-ARCH、MPLS-ENCAPS]、方法が本書では補数[MPLS-DS]を提示したと信じています。
Agarwal & Akyol Standards Track [Page 1] RFC 3443 TTL Processing in MPLS Networks January 2003
2003年1月にMPLSネットワークで処理するAgarwal&Akyol標準化過程[1ページ]RFC3443TTL
In particular, a new mode of operation (referred to as the Pipe Model) is introduced to support the practice of configuring MPLS LSPs such that packets transiting the LSP see the tunnel as a single hop regardless of the number of intermediary label switch routers (LSR). The Pipe Model for TTL is currently being used in multiple networks and is provided as an option configurable by the network operator by several vendors.
特に、MPLS LSPsを構成する習慣を支持するために操作(Pipe Modelと呼ばれる)の新型を導入するので、LSPを通過するパケットが仲介者ラベルスイッチルータ(LSR)の数にかかわらず単一のホップであるとトンネルをみなします。 TTLのためのPipe Modelを現在、複数のネットワークに使用していて、いくつかの業者でネットワーク・オペレータが構成可能なオプションとして提供します。
This document formalizes the TTL processing in MPLS networks and ties it with the terminology introduced in [MPLS-DS].
このドキュメントは、MPLSネットワークでTTL処理を正式にして、用語が[MPLS-DS]で紹介されている状態で、それを結びます。
2. TTL Processing in MPLS Networks
2. MPLSネットワークにおけるTTL処理
2.1. Changes to RFC 3032 [MPLS-ENCAPS]
2.1. RFC3032への変化[MPLS-ENCAPS]
a) [MPLS-ENCAPS] only covers the Uniform Model and does NOT address
the Pipe Model or the Short Pipe Model. This document addresses
these two models and for completeness will also address the
Uniform Model.
a) [MPLS-ENCAPS]だけ、が、Uniform Modelを覆っていて、Pipe ModelかShort Pipe Modelを記述しません。 また、これらの2つのモデルと完全性のためのこのドキュメントアドレスはUniform Modelを記述するでしょう。
b) [MPLS-ENCAPS] does not cover hierarchical LSPs. This document
addresses this issue.
b) [MPLS-ENCAPS]は階層的なLSPsを覆っていません。 このドキュメントはこの問題を記述します。
c) [MPLS-ENCAPS] does not define TTL processing in the presence of
Penultimate Hop Popping (PHP). This document addresses this
issue.
c) [MPLS-ENCAPS]はPenultimate Hop Popping(PHP)の面前でTTL処理を定義しません。 このドキュメントはこの問題を記述します。
2.2. Terminology and Background
2.2. 用語とバックグラウンド
As defined in [MPLS-ENCAPS], MPLS packets use a MPLS shim header that indicates the following information about a packet:
[MPLS-ENCAPS]で定義されるように、MPLSパケットはパケットに関して以下の情報を示すMPLS詰め物のヘッダーを使用します:
a) MPLS Label (20 bits) b) TTL (8 bits) c) Bottom of stack (1 bit) d) Experimental bits (3 bits)
a) MPLS Label(20ビット)b) TTL(8ビット)c) スタック(1ビット)d)の下部 実験ビット(3ビット)
The experimental bits were later redefined in [MPLS-DS] to indicate the scheduling and shaping behavior that could be associated with an MPLS packet.
実験ビットは、後でスケジューリングを示すために[MPLS-DS]に再定義されて、MPLSパケットに関連づけることができた振舞いを形成していました。
[MPLS-DS] also defined two models for MPLS tunnel operation: Pipe and Uniform Models. In the Pipe Model, a MPLS network acts like a circuit when MPLS packets traverse the network such that only the LSP ingress and egress points are visible to nodes that are outside the tunnel. A Short variation of the Pipe Model is also defined in [MPLS-DS] to differentiate between different egress forwarding and QoS treatments. On the other hand, the Uniform Model makes all the
また、[MPLS-DS]はMPLSトンネル操作のために2つのモデルを定義しました: パイプと一定のモデル。 Pipe Modelでは、MPLSパケットがネットワークを横断するとき、MPLSネットワークがサーキットのように行動するので、LSPイングレスと出口ポイントだけがトンネルの外にあるノードに目に見えます。 また、Pipe ModelのShort変化は、異なった出口推進とQoS処理を区別するために[MPLS-DS]で定義されます。 他方では、Uniform Modelはすべてを作ります。
Agarwal & Akyol Standards Track [Page 2] RFC 3443 TTL Processing in MPLS Networks January 2003
2003年1月にMPLSネットワークで処理するAgarwal&Akyol標準化過程[2ページ]RFC3443TTL
nodes that a LSP traverses visible to nodes outside the tunnel. We will extend the Pipe and Uniform Models to include TTL processing in the following sections. Furthermore, TTL processing, when performing PHP, is also described in this document. For a detailed description of Pipe and Uniform Models, please see [MPLS-DS].
ノード、トンネルの外のノードに目に見えるそのa LSP横断。 私たちは、以下のセクションにTTL処理を含むようにPipeとUniform Modelsを広げるつもりです。 その上、また、PHPを実行するとき、TTL処理は本書では説明されます。 PipeとUniform Modelsの詳述に関しては、[MPLS-DS]を見てください。
TTL processing in MPLS networks can be broken down into two logical blocks: (i) the incoming TTL determination to take into account any tunnel egress due to MPLS Pop operations; (ii) packet processing of (possibly) exposed packets and outgoing TTLs.
MPLSネットワークにおけるTTL処理は2つの論理的なブロックへ砕けている場合があります: (i) MPLS Pop操作のためどんなトンネル出口も考慮に入れる入って来るTTL決断。 (ii) (ことによると)露出しているパケットと出発しているTTLsのパケット処理。
We also note here that signaling the LSP type (Pipe, Short Pipe or Uniform Model) is out of the scope of this document, and that is also not addressed in the current versions of the label distribution protocols, e.g. LDP [MPLS-LDP] and RSVP-TE [MPLS-RSVP]. Currently, the LSP type is configured by the network operator manually by means of either a command line or network management interface.
また、私たちは、ここでこのドキュメントの範囲の外にLSPタイプ(パイプ、Short PipeまたはUniform Model)に合図するのがあって、また、それがラベル分配プロトコル、例えば、自由民主党[MPLS-自由民主党]とRSVP-TE[MPLS-RSVP]の最新版で記述されないことに注意します。 現在、LSPタイプはコマンドラインかネットワークマネージメントインタフェースのどちらかによるネットワーク・オペレータによって手動で構成されます。
2.3. New Terminology
2.3. 新しい用語
iTTL: The TTL value to use as the incoming TTL. No checks are performed on the iTTL.
iTTL: 入って来るTTLとして使用するTTL値。 チェックは全くiTTLに実行されません。
oTTL: This is the TTL value used as the outgoing TTL value (see section 3.5 for exception). It is always (iTTL - 1) unless otherwise stated.
oTTL: これは出発しているTTLが評価するように使用されるTTL値(例外に関してセクション3.5を見る)です。 別の方法で述べられない場合、いつも(iTTL--1)それはそうです。
oTTL Check: Check if oTTL is greater than 0. If the oTTL Check is false, then the packet is not forwarded. Note that the oTTL check is performed only if any outgoing TTL (either IP or MPLS) is set to oTTL (see section 3.5 for exception).
oTTLはチェックします: oTTLが0歳以上であるかどうかチェックしてください。 oTTL Checkが偽であるなら、パケットは進められません。 何か出発しているTTL(IPかMPLSのどちらか)がoTTLに用意ができている場合にだけ(例外に関してセクション3.5を見てください)oTTLチェックが実行されることに注意してください。
3. TTL Processing in different Models
3. 異なったModelsのTTL Processing
This section describes the TTL processing for LSPs conforming to each of the 3 models (Uniform, Short Pipe and Pipe) in the presence/absence of PHP (where applicable).
このセクションはPHP(適切であるところ)の存在/不在でモデル3人の各人(ユニフォーム、Short Pipe、およびPipe)に従うLSPsのためにTTL処理について説明します。
Agarwal & Akyol Standards Track [Page 3] RFC 3443 TTL Processing in MPLS Networks January 2003
2003年1月にMPLSネットワークで処理するAgarwal&Akyol標準化過程[3ページ]RFC3443TTL
3.1. TTL Processing for Uniform Model LSPs (with or without PHP)
3.1. ユニフォームモデルLSPsのためのTTL処理(PHPのあるなしにかかわらず)
(consistent with [MPLS-ENCAPS]):
([MPLS-ENCAPS]と一致する):
========== LSP =============================>
========== LSP=============================>。
+--Swap--(n-2)-...-swap--(n-i)---+
/ (outer header) \
(n-1) (n-i)
/ \
>--(n)--Push...............(x).....................Pop--(n-i-1)->
(I) (inner header) (E or P)
+--スワッピング--(n-2)、-、…-スワッピング--(n-i)---+ /(外側のヘッダー)\(n-1)(n-i)/\>((n))は押されます…(x).....................ポップス--(n-i-1)->(I)(内側のヘッダー)(EかP)
(n) represents the TTL value in the corresponding header (x) represents non-meaningful TTL information (I) represents the LSP ingress node (P) represents the LSP penultimate node (E) represents the LSP Egress node
(n)が中の対応するヘッダー(x)が表す非重要なTTL情報(I)が表すLSPイングレスノード(P)が表すLSPの終わりから二番目のノード(E)が表すTTL値を表す、LSP Egressノード
This picture shows TTL processing for a Uniform Model MPLS LSP. Note that the inner and outer TTLs of the packets are synchronized at tunnel ingress and egress.
この絵はUniform Model MPLS LSPのために処理をTTLに示しています。 パケットの内側の、そして、外側のTTLsがトンネルイングレスと出口で連動することに注意してください。
3.2. TTL Processing for Short Pipe Model LSPs
3.2. 短いパイプモデルLSPsのためのTTL処理
3.2.1. TTL Processing for Short Pipe Model LSPs without PHP
3.2.1. PHPのない短いパイプモデルLSPsのためのTTL処理
========== LSP =============================>
========== LSP=============================>。
+--Swap--(N-1)-...-swap--(N-i)-----+
/ (outer header) \
(N) (N-i)
/ \
>--(n)--Push...............(n-1).....................Pop--(n-2)->
(I) (inner header) (E)
+--スワッピング--(N-1)、-、…-スワッピング--(N-i)-----+ /(外側のヘッダー)\(N)(N-i)/\>((n))は押されます…(n-1).....................ポップス--(n-2)->(I)(内側のヘッダー)(E)
(N) represents the TTL value (may have no relationship to n) (n) represents the tunneled TTL value in the encapsulated header (I) represents the LSP ingress node (E) represents the LSP Egress node
(N)が表す、(n)が表すTTL値(nとの関係を全く持っていないかもしれない)が要約のヘッダー(I)にイングレスノード(E)が表すLSPを表す、トンネルを堀られたTTLが、評価するLSP Egressノード
The Short Pipe Model was introduced in [MPLS-DS]. In the Short Pipe Model, the forwarding treatment at the egress LSR is based on the tunneled packet, as opposed to the encapsulating packet.
[MPLS-DS]でShort Pipe Modelを導入しました。 Short Pipe Modelでは、出口LSRでの推進処理はトンネルを堀られたパケットに基づいています、要約パケットと対照的に。
Agarwal & Akyol Standards Track [Page 4] RFC 3443 TTL Processing in MPLS Networks January 2003
2003年1月にMPLSネットワークで処理するAgarwal&Akyol標準化過程[4ページ]RFC3443TTL
3.2.2. TTL Processing for Short Pipe Model with PHP:
3.2.2. 略して処理するTTLがPHPのモデルを運びます:
========== LSP =====================================>
+-Swap-(N-1)-...-swap-(N-i)-+
/ (outer header) \
(N) (N-i)
/ \
>--(n)--Push.............(n-1)............Pop-(n-1)-Decr.-(n-2)->
(I) (inner header) (P) (E)
========== LSP=====================================>+スワッピング-(N-1)、-、…-スワッピング(N-i)-+/(外側のヘッダー)\(N)(N-i)/\>((n))は押されます…(n-1)............Decr.-(n-2)を飛び出させている(n-1)->(I)(内側のヘッダー)(P)(E)
(N) represents the TTL value (may have no relationship to n) (n) represents the tunneled TTL value in the encapsulated header (I) represents the LSP ingress node (P) represents the LSP penultimate node (E) represents the LSP egress node.
(n)が表すTTL値(nとの関係を全く持っていないかもしれない)は要約のヘッダー(I)にイングレスノード(P)が表すLSPを表しますトンネルを堀られたTTLが、評価する。(N)が表す、LSP終わりから二番目ののノード(E)はLSP出口ノードを表します。
Since the label has already been popped by the LSP's penultimate node, the LSP egress node just decrements the header TTL.
ラベルはLSPの終わりから二番目のノードによって既に飛び出さされたので、LSP出口ノードはヘッダーTTLをただ減少させます。
Also note that at the end of the Short Pipe Model LSP, the TTL of the tunneled packet has been decremented by two, with or without PHP.
また、Short Pipe Model LSPの端では、トンネルを堀られたパケットのTTLがPHPのあるなしにかかわらず2つ減少したことに注意してください。
3.3. TTL Processing for Pipe Model LSPs (without PHP only):
3.3. Pipe Model LSPs(PHPだけのない)のためのTTL Processing:
========== LSP =============================>
========== LSP=============================>。
+--Swap--(N-1)-...-swap--(N-i)-----+
/ (outer header) \
(N) (N-i)
/ \
>--(n)--Push...............(n-1)....................Pop--(n-2)->
(I) (inner header) (E)
+--スワッピング--(N-1)、-、…-スワッピング--(N-i)-----+ /(外側のヘッダー)\(N)(N-i)/\>((n))は押されます…(n-1)....................ポップス--(n-2)->(I)(内側のヘッダー)(E)
(N) represents the TTL value (may have no relationship to n) (n) represents the tunneled TTL value in the encapsulated header (I) represents the LSP ingress node (E) represents the LSP Egress node
(N)が表す、(n)が表すTTL値(nとの関係を全く持っていないかもしれない)が要約のヘッダー(I)にイングレスノード(E)が表すLSPを表す、トンネルを堀られたTTLが、評価するLSP Egressノード
From the TTL perspective, the treatment for a Pipe Model LSP is identical to the Short Pipe Model without PHP.
TTL見解から、Pipe Model LSPに関する処理はPHPなしでShort Pipe Modelと同じです。
Agarwal & Akyol Standards Track [Page 5] RFC 3443 TTL Processing in MPLS Networks January 2003
2003年1月にMPLSネットワークで処理するAgarwal&Akyol標準化過程[5ページ]RFC3443TTL
3.4. Incoming TTL (iTTL) determination
3.4. 入って来るTTL(iTTL)決断
If the incoming packet is an IP packet, then the iTTL is the TTL value of the incoming IP packet.
入って来るパケットがIPパケットであるなら、iTTLは入って来るIPパケットのTTL値です。
If the incoming packet is an MPLS packet and we are performing a Push/Swap/PHP, then the iTTL is the TTL of the topmost incoming label.
入って来るパケットがMPLSパケットであり、私たちがPush/スワッピング/PHPを実行しているなら、iTTLは最上の入って来るラベルのTTLです。
If the incoming packet is an MPLS packet and we are performing a Pop (tunnel termination), the iTTL is based on the tunnel type (Pipe or Uniform) of the LSP that was popped. If the popped label belonged to a Pipe Model LSP, then the iTTL is the value of the TTL field of the header, exposed after the label was popped (note that for the purpose of this document, the exposed header may be either an IP header or an MPLS label). If the popped label belonged to a Uniform Model LSP, then the iTTL is equal to the TTL of the popped label. If multiple Pop operations are performed sequentially, then the procedure given above is repeated with one exception: the iTTL computed during the previous Pop is used as the TTL of subsequent labels being popped; i.e. the TTL contained in the subsequent label is essentially ignored and replaced with the iTTL computed during the previous pop.
入って来るパケットがMPLSパケットであり、私たちがPop(トンネル終了)を実行しているなら、iTTLは飛び出したLSPのトンネルタイプ(パイプかUniform)に基づいています。 飛び出しているラベルがPipe Model LSPに属したなら、iTTLはラベルが飛び出した後にさらされたヘッダー(このドキュメント、露出しているヘッダーの目的のためのIPヘッダーかMPLSラベルのどちらかであるかもしれない注意)のTTL分野の値です。 飛び出しているラベルがUniform Model LSPに属したなら、iTTLは飛び出しているラベルのTTLと等しいです。 複数のPop操作が連続して実行されるなら、上に与えられた手順はただ1つを例外として繰り返されます: 前のPopの間に計算されたiTTLは飛び出すその後のラベルのTTLとして使用されます。 すなわち、その後のラベルに含まれたTTLを前のポップスの間、計算されるiTTLに本質的には無視して、取り替えます。
3.5. Outgoing TTL Determination and Packet Processing
3.5. 外向的なTTL決断とパケット処理
After the iTTL computation is performed, the oTTL check is performed. If the oTTL check succeeds, then the outgoing TTL of the (labeled/unlabeled) packet is calculated and packet headers are updated as defined below.
iTTL計算が実行された後に、oTTLチェックは実行されます。 oTTLチェックが成功するなら、(ラベルされるかラベルされていません)のパケットの出発しているTTLについて計算します、そして、以下で定義されるようにパケットのヘッダーをアップデートします。
If the packet was routed as an IP packet, the TTL value of the IP packet is set to oTTL (iTTL - 1). The TTL value(s) for any pushed label(s) is determined as described in section 3.6.
パケットがIPパケットとして発送されたなら、IPパケットのTTL値はoTTL(iTTL--1)に設定されます。 どんな押されたラベルのためのTTL値もセクション3.6で説明されるように決定しています。
For packets that are routed as MPLS, we have four cases:
MPLSとして発送されるパケットに関しては、私たちには、4つのケースがあります:
1) Swap-only: The routed label is swapped with another label and the
TTL field of the outgoing label is set to oTTL.
1) スワッピング専用: 発送されたラベルは別のラベルで交換されます、そして、出発しているラベルのTTL分野はoTTLに設定されます。
2) Swap followed by a Push: The swapped operation is performed as
described in (1). The TTL value(s) of any pushed label(s) is
determined as described in section 3.6.
2) スワッピングはPushで続きました: 交換された操作は(1)で説明されるように実行されます。 どんな押されたラベルのTTL値もセクション3.6で説明されるように決定しています。
3) Penultimate Hop Pop (PHP): The routed label is popped. The oTTL
check should be performed irrespective of whether the oTTL is used
to update the TTL field of the outgoing header. If the PHPed
label belonged to a Short Pipe Model LSP, then the TTL field of
the PHP exposed header is neither checked nor updated. If the
3) 終わりから二番目のホップポップス(PHP): 発送されたラベルは飛び出します。 oTTLが外向的なヘッダーのTTL分野をアップデートするのに使用されるかどうかの如何にかかわらずoTTLチェックは実行されるべきです。 PHPedラベルがShort Pipe Model LSPに属したなら、PHPのTTL分野はどちらもチェックされないで、アップデートされたヘッダーをさらしました。 the
Agarwal & Akyol Standards Track [Page 6] RFC 3443 TTL Processing in MPLS Networks January 2003
2003年1月にMPLSネットワークで処理するAgarwal&Akyol標準化過程[6ページ]RFC3443TTL
PHPed label was a Uniform Model LSP, then the TTL field of the PHP
exposed header is set to the oTTL. The TTL value(s) of additional
labels are determined as described in section 3.6
PHPedラベルがUniform Model LSPであった、そして、PHPのさらのヘッダーのTTL分野はoTTLに設定されます。 追加ラベルのTTL値はセクション3.6で説明されるように決定しています。
4) Pop: The pop operation happens before routing and hence it is not
considered here.
4) 以下を飛び出させてください。 飛び出し操作はルーティングの前に起こります、そして、したがって、それはここで考えられません。
3.6. Tunnel Ingress Processing (Push)
3.6. トンネルイングレス処理(プッシュ)
For each pushed Uniform Model label, the TTL is copied from the label/IP-packet immediately underneath it.
それぞれの押されたUniform Modelラベルに関しては、TTLはそれのすぐ下のIPラベル/パケットからコピーされます。
For each pushed Pipe Model or Short Pipe Model label, the TTL field is set to a value configured by the network operator. In most implementations, this value is set to 255 by default.
それぞれの押されたPipe ModelかShort Pipe Modelラベルにおいて、TTL分野はネットワーク・オペレータによって構成された値に設定されます。 ほとんどの実現では、この値はデフォルトで255に設定されます。
3.7. Implementation Remarks
3.7. 実現所見
1) Although iTTL can be decremented by a value larger than 1 while it
is being updated or oTTL is being determined, this feature should
be only used for compensating for network nodes that are not
capable of decrementing TTL values.
1) iTTLはそれがアップデートするか、oTTLである間、1が決定している状態であるより大きい値で減少できますが、この特徴は、TTL値を減少させることができないネットワーク・ノードを補うのに使用されるだけであるべきです。
2) Whenever iTTL is decremented, the implementer must make sure that
the value does not become negative.
2) iTTLが減少するときはいつも、implementerは、値が否定的にならないのを確実にしなければなりません。
3) In the Short Pipe Model with PHP enabled, the TTL of the tunneled
packet is unchanged after the PHP operation.
3) PHPが有効にされているShort Pipe Modelでは、トンネルを堀られたパケットのTTLはPHP操作の後に変わりがありません。
4. Conclusion
4. 結論
This Internet Document describes how the TTL field can be processed in an MPLS network. We clarified the various methods that are applied in the presence of hierarchical tunnels and completed the integration of Pipe and Uniform Models with TTL processing.
このインターネットDocumentはMPLSネットワークでどうTTL分野を処理できるかを説明します。 私たちは、階層的なトンネルがあるとき適用される様々な方法をはっきりさせて、TTL処理によるPipeとUniform Modelsの統合を終了しました。
5. Security Considerations
5. セキュリティ問題
This document does not add any new security issues other than the ones defined in [MPLS-ENCAPS, MPLS-DS]. In particular, the document does not define a new protocol or expand an existing one and does not introduce security problems into the existing protocols. The authors believe that clarification of TTL handling in MPLS networks benefits service providers and their customers since troubleshooting is simplified.
このドキュメントは[MPLS-ENCAPS、MPLS-DS]で定義されたもの以外の少しの新しい安全保障問題も加えません。 ドキュメントは、特に、新しいプロトコルを定義もしませんし、既存のものを膨張もさせないで、既存のプロトコルに警備上の問題を取り入れません。 作者はトラブルシューティングが簡易型であるのでMPLSネットワークで利益サービスプロバイダーと彼らの顧客を扱うTTLのその明確化を信じています。
Agarwal & Akyol Standards Track [Page 7] RFC 3443 TTL Processing in MPLS Networks January 2003
2003年1月にMPLSネットワークで処理するAgarwal&Akyol標準化過程[7ページ]RFC3443TTL
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC-2119] Bradner, S. "Key words for use in RFC's to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]ブラドナー、S. 「Indicate Requirement LevelsへのRFCのものにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[MPLS-アーチ] ローゼンとE.とViswanathanとA.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[MPLS-ENCAPS] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSはスタックコード化をラベルします」、RFC3032、2001年1月。
[MPLS-DS] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P. and J. Heinanen,
"Multi-Protocol Label Switching (MPLS) Support of
Differentiated Services", RFC 3270, May 2002.
[MPLS-DS]Le Faucheur、F.、ウー、L.、デイビー、B.、Davari、S.、バーナネン、P.、クリシュナン、R.、シェヴァル、P.、およびJ.Heinanen、「微分されたサービスのマルチプロトコルラベルスイッチング(MPLS)サポート」(RFC3270)は2002がそうするかもしれません。
6.2. Informative References
6.2. 有益な参照
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A.
and B. Thomas, "LDP Specification", RFC 3036, January
2001.
[MPLS-自由民主党] アンデションとL.とDoolanとP.とフェルドマンとN.とFredetteとA.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。
[MPLS-RSVP] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V. and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[MPLS-RSVP] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
7. Acknowledgements
7. 承認
The authors would like to thank the members of the MPLS working group for their feedback. We would especially like to thank Shahram Davari and Loa Andersson for their careful review of the document and their comments.
作者は彼らのフィードバックについてMPLSワーキンググループのメンバーに感謝したがっています。 ドキュメントと彼らのコメントに関する彼らの慎重なレビューについてShahram DavariとLoaアンデションに特に感謝申し上げます。
Agarwal & Akyol Standards Track [Page 8] RFC 3443 TTL Processing in MPLS Networks January 2003
2003年1月にMPLSネットワークで処理するAgarwal&Akyol標準化過程[8ページ]RFC3443TTL
8. Author's Addresses
8. 作者のアドレス
Puneet Agarwal Brocade Communications Systems, Inc. 1745 Technology Drive San Jose, CA 95110
Puneet AgarwalはInc.1745技術Driveサンノゼ、通信網カリフォルニア 95110を紋織りにします。
EMail: puneet@acm.org
メール: puneet@acm.org
Bora Akyol Cisco Systems 170 W. Tasman Drive San Jose, CA 95134
ボーラAkyolシスコシステムズ170W.タスマン・Driveサンノゼ、カリフォルニア 95134
EMail: bora@cisco.com
メール: bora@cisco.com
Agarwal & Akyol Standards Track [Page 9] RFC 3443 TTL Processing in MPLS Networks January 2003
2003年1月にMPLSネットワークで処理するAgarwal&Akyol標準化過程[9ページ]RFC3443TTL
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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機能のための基金は現在、インターネット協会によって提供されます。
Agarwal & Akyol Standards Track [Page 10]
Agarwal&Akyol標準化過程[10ページ]
一覧
スポンサーリンク
