RFC3035 日本語訳
3035 MPLS using LDP and ATM VC Switching. B. Davie, J. Lawrence, K.McCloghrie, E. Rosen, G. Swallow, Y. Rekhter, P. Doolan. January 2001. (Format: TXT=46463 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Davie
Request for Comments: 3035 J. Lawrence
Category: Standards Track K. McCloghrie
E. Rosen
G. Swallow
Cisco Systems, Inc.
Y. Rekhter
Juniper Networks
P. Doolan
Ennovate Networks, Inc.
January 2001
コメントを求めるワーキンググループB.デイビー要求をネットワークでつないでください: 3035年のJ.ローレンスカテゴリ: P.Doolan EnnovateがInc.2001年1月にネットワークでつなぐ標準化過程K.McCloghrie E.ローゼンG.ツバメシスコシステムズInc.Y.Rekhter杜松ネットワーク
MPLS using LDP and ATM VC Switching
自由民主党を使用するMPLSと気圧VCの切り換え
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 (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
The Multiprotocol Label Switching (MPLS) Architecture [1] discusses a way in which Asynchronous Transfer Mode (ATM) switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs (Label Switching Routers).
構造[1]が道について議論するそれのAsynchronous Transfer Mode(ATM)スイッチがLabel Switching Routersとして使用されるかもしれないMultiprotocol Label Switching(MPLS)。 彼らのデータ推進はこれらのルーティング・アルゴリズムの結果に基づいています。ATMスイッチがネットワーク層ルーティング・アルゴリズムを走らせる、(オープンShortest Path First(OSPF)、Intermediate SystemへのIntermediate Systemなど、(-、)、など、)、どんなATM特有のルーティングもアドレシングも必要ではありません。 このように使用されるATMスイッチはATM-LSRs(ラベルSwitching Routers)として知られています。
This document extends and clarifies the relevant portions of [1] and [2] by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see [1]) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms.
ATM-LSRsかATM-LSRsそれらのラベルであるときに時ラベルを分配するのに、使用されるために、Forwarding Equivalence Classesを表してください。このドキュメントがさらに詳細に手順を指定することによって[1]と[2]の関連部分を広げていて、はっきりさせる、どれ、(FECs、ルートがホップごとのベースでネットワーク層ルーティング・アルゴリズムで決定している[1])を見てくださいか。
This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to [3].
また、発信がATM-LSRsかATM-LSRsからパケットをラベルして、その点で[3]への仲間ドキュメントであるときに、このドキュメントは、使用されるためにMPLSカプセル化を指定します。
Davie Standards Track [Page 1] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
自由民主党を使用するデイビー標準化過程[1ページ]RFC3035MPLSと2001年1月に切り替わる気圧VC
Table of Contents
目次
1 Introduction ........................................... 2
2 Specification of Requirements .......................... 3
3 Definitions ............................................ 3
4 Special Characteristics of ATM Switches ................ 4
5 Label Switching Control Component for ATM .............. 5
6 Hybrid Switches (Ships in the Night) ................... 5
7 Use of VPI/VCIs ....................................... 5
7.1 Direct Connections ..................................... 6
7.2 Connections via an ATM VP .............................. 7
7.3 Connections via an ATM SVC ............................. 7
8 Label Distribution and Maintenance Procedures .......... 7
8.1 Edge LSR Behavior ...................................... 8
8.2 Conventional ATM Switches (non-VC-merge) ............... 9
8.3 VC-merge-capable ATM Switches .......................... 11
9 Encapsulation .......................................... 12
10 TTL Manipulation ....................................... 13
11 Optional Loop Detection: Distributing Path Vectors ..... 15
11.1 When to Send Path Vectors Downstream ................... 15
11.2 When to Send Path Vectors Upstream ..................... 16
12 Security Considerations ................................ 17
13 Intellectual Property Considerations ................... 17
14 References ............................................. 18
15 Acknowledgments ........................................ 18
16 Authors' Addresses ..................................... 18
17 Full Copyright Statement ............................... 20
1つの序論… 要件の2 2仕様… 3 3の定義… 気圧の3 4の特別な特性が切り替わります… 4 5は気圧のためにコンポーネントと切換制御をラベルします… 5 6ハイブリッドは(夜の船)を切り換えます… VPI/VCIsの5 7使用… 5 7.1 コネクションズを指示してください… 6 ATM VPを通した7.2コネクションズ… 7 ATM SVCを通した7.3コネクションズ… 7 8は分配と保守手順をラベルします… 7 8.1 LSRの振舞いを斜めに進ませてください… 8 8.2の従来の気圧は切り替わります(非VCは合併します)… 9 8.3できるVCマージ気圧は切り替わります… 11 9カプセル化… 12 10TTL操作… 13 11の任意の輪の検出: 経路ベクトルを分配します… 15 11.1、いつ、経路ベクトルを川下に送るために… 15 11.2、いつ、上流へ経路ベクトルを送るために… 16 12のセキュリティ問題… 17 13の知的所有権問題… 17 14の参照箇所… 18 15の承認… 18 16人の作者のアドレス… 18 17の完全な著作権宣言文… 20
1. Introduction
1. 序論
The MPLS Architecture [1] discusses the way in which ATM switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs.
MPLS Architecture[1]はATMスイッチがLabel Switching Routersとして使用されるかもしれない方法について議論します。 彼らのデータ推進はこれらのルーティング・アルゴリズムの結果に基づいています。ATMスイッチがネットワーク層ルーティング・アルゴリズムを走らせる、(OSPFなどのように-、など、)、どんなATM特有のルーティングもアドレシングも必要ではありません。 このように使用されるATMスイッチはATM-LSRsとして知られています。
This document extends and clarifies the relevant portions of [1] and [2] by specifying in more detail the procedures which are to be used for distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see [1]) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. The label distribution technique described here is referred to in [1] as "downstream-on-demand". This label distribution technique MUST be used by ATM-LSRs that are not capable of "VC merge" (defined in section 3), and is OPTIONAL for ATM-LSRs that are capable of VC merge.
このドキュメントは、さらに詳細にATM-LSRs、または、それらのラベルがForwarding Equivalence Classesを表すATM-LSRsからラベルを分配するのに使用されることである手順を指定することによって、[1]と[2]の関連部分を広げていて、はっきりさせます。ネットワーク層ルーティング・アルゴリズムでルートがホップごとのベースで決定している[1])を見てください。(FECs、ここで説明されたラベル分配技法は[1]に「川下に要求次第」と呼ばれます。 このラベル分配技法は、「VCは合併できない」(セクション3で、定義されます)ATM-LSRsが使用しなければならなくて、VCマージができるATM-LSRsのためのOPTIONALです。
Davie Standards Track [Page 2] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
自由民主党を使用するデイビー標準化過程[2ページ]RFC3035MPLSと2001年1月に切り替わる気圧VC
This document does NOT specify the label distribution techniques to be used in the following cases:
このドキュメントは以下の場合に使用されるためにラベル分配技法を指定しません:
- the routes are explicitly chosen before label distribution
begins, instead of being chosen on a hop-by-hop basis as label
distribution proceeds,
- ラベル分配が始まる前にルートは明らかに選ばれています、ラベル分配が続くのでホップごとのベースで選ばれることの代わりに
- the routes are intended to diverge in any way from the routes
chosen by the conventional hop-by-hop routing at any time,
- ルートが何らかの方法でいつでもホップごとの従来のルーティングによって選ばれたルートからそれることを意図します。
- the labels represent FECs that consist of multicast packets,
- ラベルはマルチキャストパケットから成るFECsを表します。
- the LSRs use "VP merge".
- LSRsは「VPマージ」を使用します。
Further statements made in this document about ATM-LSR label distribution do not necessarily apply in these cases.
本書ではATM-LSRラベル分配に関して出されたさらなる声明は必ずこれらの場合で適用されるというわけではありません。
This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to [3]. The specified encapsulation is to be used for multicast or explicitly routed labeled packets as well.
また、発信がATM-LSRsかATM-LSRsからパケットをラベルして、その点で[3]への仲間ドキュメントであるときに、このドキュメントは、使用されるためにMPLSカプセル化を指定します。 指定されたカプセル化はまた、マルチキャストに使用されたか、または明らかに発送されたラベルされたパケットであることです。
This document uses terminology from [1].
このドキュメントは[1]から用語を使用します。
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 RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
3. Definitions
3. 定義
A Label Switching Router (LSR) is a device which implements the label switching control and forwarding components described in [1].
Label Switching Router(LSR)は[1]で説明されたラベル切換制御と推進コンポーネントを実行する装置です。
A label switching controlled ATM (LC-ATM) interface is an ATM interface controlled by the label switching control component. When a packet traversing such an interface is received, it is treated as a labeled packet. The packet's top label is inferred either from the contents of the VCI field or the combined contents of the VPI and VCI fields. Any two LDP peers which are connected via an LC-ATM interface will use LDP negotiations to determine which of these cases is applicable to that interface.
ラベル切り換えの制御ATM(LC-ATM)インタフェースはラベル切換制御の部品によって制御されたATMインタフェースです。 そのようなインタフェースを横断するパケットが受け取られているとき、それはラベルされたパケットとして扱われます。 パケットのトップラベルはVCI分野のコンテンツかVPIとVCI分野の結合したコンテンツから推論されます。 LC-ATMインタフェースを通して接されるどんな2人の自由民主党の同輩も、これらのケースのどれがそのインタフェースに適切であるかを決定するのに自由民主党の交渉を使用するでしょう。
An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards cells between these interfaces, using labels carried in the VCI or VPI/VCI field, without reassembling the cells into frames before forwarding.
ATM-LSRはこれらのインタフェースの間にセルを送る多くのLC-ATMインタフェースがあるLSRです、VCIかVPI/VCI分野で運ばれたラベルを使用して、推進の前にフレームにセルを組み立て直さないで。
Davie Standards Track [Page 3] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
自由民主党を使用するデイビー標準化過程[3ページ]RFC3035MPLSと2001年1月に切り替わる気圧VC
A frame-based LSR is a LSR which forwards complete frames between its interfaces. Note that such a LSR may have zero, one or more LC-ATM interfaces.
フレームベースのLSRは完全なフレームをインタフェースの間に送るLSRです。 そのようなLSRにはゼロ、1つ以上のLC-ATMインタフェースがあるかもしれないことに注意してください。
Sometimes a single box may behave as an ATM-LSR with respect to certain pairs of interfaces, but may behave as a frame-based LSR with respect to other pairs. For example, an ATM switch with an ethernet interface may function as an ATM-LSR when forwarding cells between its LC-ATM interfaces, but may function as a frame-based LSR when forwarding frames from its ethernet to one of its LC-ATM interfaces. In such cases, one can consider the two functions (ATM-LSR and frame-based LSR) as being coresident in a single box.
単一の箱は、時々、ATM-LSRとしてインタフェースのある組に関して振る舞いますが、フレームベースのLSRとして他の組に関して反応するかもしれません。 例えば、イーサネットインタフェースがあるATMスイッチは、LC-ATMインタフェースの間にセルを送るとき、ATM-LSRとして機能しますが、フレームをイーサネットからLC-ATMの1つに送るとき、フレームベースのLSRが連結するとき、機能するかもしれません。 そのような場合、人は、コレジデントであるとして単一の箱の中に2つの機能が(ATM-LSRとフレームベースのLSR)であると考えることができます。
It is intended that an LC-ATM interface be used to connect two ATM- LSRs, or to connect an ATM-LSR to a frame-based LSR. The use of an LC-ATM interface to connect two frame-based LSRs is not considered in this document.
LC-ATMインタフェースが2ATM- LSRsを接続するか、またはフレームベースのLSRにATM-LSRを接続するのに使用されることを意図します。 2フレームベースのLSRsを接続するLC-ATMインタフェースの使用は本書では考えられません。
An ATM-LSR domain is a set of ATM-LSRs which are mutually interconnected by LC-ATM interfaces.
ATM-LSRドメインはLC-ATMインタフェースによって互いにインタコネクトされるATM-LSRsの1セットです。
The Edge Set of an ATM-LSR domain is the set of frame-based LSRs which are connected to members of the domain by LC-ATM interfaces. A frame-based LSR which is a member of an Edge Set of an ATM-LSR domain may be called an Edge LSR.
ATM-LSRドメインのEdge SetはLC-ATMインタフェースによってドメインのメンバーに接続されるフレームベースのLSRsのセットです。 ATM-LSRドメインのEdge SetのメンバーであるフレームベースのLSRはEdge LSRと呼ばれるかもしれません。
VC-merge is the process by which a switch receives cells on several incoming VCIs and transmits them on a single outgoing VCI without causing the cells of different AAL5 PDUs to become interleaved.
VC-マージは異なったAAL5 PDUsのセルがはさみ込まれるようになることを引き起こさない、スイッチが数個の入って来るVCIsでセルを受けて、独身の出発しているVCIで彼らを伝える過程です。
4. Special Characteristics of ATM Switches
4. 気圧スイッチの特別な特性
While the MPLS architecture permits considerable flexibility in LSR implementation, an ATM-LSR is constrained by the capabilities of the (possibly pre-existing) hardware and the restrictions on such matters as cell format imposed by ATM standards. Because of these constraints, some special procedures are required for ATM-LSRs.
MPLS構造がLSR実現におけるかなりの柔軟性を可能にしている間、ATM-LSRはATM規格によって課されたセル形式のような件で(ことによると先在します)のハードウェアと制限の能力によって抑制されます。 これらの規制のために、いくつかの特別な手順がATM-LSRsに必要です。
Some of the key features of ATM switches that affect their behavior as LSRs are:
LSRsとして彼らの振舞いに影響するATMスイッチに関する重要な特色のいくつかは以下の通りです。
- the label swapping function is performed on fields (the VCI
and/or VPI) in the cell header; this dictates the size and
placement of the label(s) in a packet.
- ラベルスワッピング機能はセルヘッダーのフィールド(VCI、そして/または、VPI)に実行されます。 これはパケットのラベルのサイズとプレースメントを書き取ります。
- multipoint-to-point and multipoint-to-multipoint VCs are
generally not supported. This means that most switches cannot
support 'VC-merge' as defined above.
- 一般に、多点からポイントと多点から多点へのVCsは支持されません。 これは、ほとんどのスイッチが上で定義されるように'VC-マージ'を支持できないことを意味します。
Davie Standards Track [Page 4] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
自由民主党を使用するデイビー標準化過程[4ページ]RFC3035MPLSと2001年1月に切り替わる気圧VC
- there is generally no capability to perform a 'TTL-decrement'
function as is performed on IP headers in routers.
- 一般に、ルータでIPヘッダーに実行される'TTL-減少'機能を実行する能力が全くありません。
This document describes ways of applying label switching to ATM switches which work within these constraints.
このドキュメントはこれらの規制の中で動作するATMスイッチとのラベルの切り換えを適用する方法を述べます。
5. Label Switching Control Component for ATM
5. 気圧のためのラベル切換制御の部品
To support label switching an ATM switch MUST implement the control component of label switching. This consists primarily of label allocation, distribution, and maintenance procedures. Label binding information is communicated by several mechanisms, notably the Label Distribution Protocol (LDP) [2]. This document imposes certain requirements on the LDP.
ラベルの切り換えを支持するために、ATMスイッチはラベルの切り換えのコントロールの部品を実行しなければなりません。 これは主としてラベル配分、分配、および保守手順から成ります。 情報を縛るラベルが数個のメカニズム、著しくLabel Distributionプロトコル(自由民主党)[2]によって伝えられます。 このドキュメントはある要件を自由民主党に課します。
This document considers only the case where the label switching control component uses information learned directly from network layer routing protocols. It is presupposed that the switch participates as a peer in these protocols (e.g., OSPF, IS-IS).
このドキュメントはラベル切換制御の部品が直接ネットワーク層ルーティング・プロトコルから学習された情報を使用するケースだけを考えます。 スイッチが同輩としてこれらのプロトコルに関与するのが予想される、(例えば、OSPF、-、)
In some cases, LSRs make use of other protocols (e.g., RSVP, PIM, BGP) to distribute label bindings. In these cases, an ATM-LSR would need to participate in these protocols. However, these are not explicitly considered in this document.
いくつかの場合、LSRsは、ラベル結合を広げるのに、他のプロトコル(例えば、RSVP、PIM、BGP)を利用します。 これらの場合では、ATM-LSRは、これらのプロトコルに参加する必要があるでしょう。 しかしながら、これらは明らかに本書では考えられません。
Support of label switching on an ATM switch does NOT require the switch to support the ATM control component defined by the ITU and ATM Forum (e.g., UNI, PNNI). An ATM-LSR may OPTIONALLY respond to OAM cells.
ATMスイッチにおけるラベルの切り換えのサポートは、ITUとATM Forum(例えば、UNI、PNNI)によって定義されたATMコントロールの部品を支えるためにスイッチを必要としません。 ATM-LSRは応じるかもしれません。OPTIONALLYはOAMセルに応じます。
6. Hybrid Switches (Ships in the Night)
6. ハイブリッドスイッチ(夜の船)
The existence of the label switching control component on an ATM switch does not preclude the ability to support the ATM control component defined by the ITU and ATM Forum on the same switch and the same interfaces. The two control components, label switching and the ITU/ATM Forum defined, would operate independently.
ATMスイッチのラベル切換制御の部品の存在は同じスイッチと同じインタフェースのITUとATM Forumによって定義されたATMコントロールの部品を支える能力を排除しません。 2つのコントロールの部品(切り換えとITU/ATM Forumが定義したラベル)が独自に作動するでしょう。
Definition of how such a device operates is beyond the scope of this document. However, only a small amount of information needs to be consistent between the two control components, such as the portions of the VPI/VCI space which are available to each component.
そのような装置がどう作動するかに関する定義はこのドキュメントの範囲を超えています。 しかしながら、少量の情報だけが、2つのコントロールの部品の間で一貫している必要があります、VPI/VCIスペースの各コンポーネントに利用可能な部分などのように。
7. Use of VPI/VCIs
7. VPI/VCIsの使用
Label switching is accomplished by associating labels with Forwarding Equivalence Classes, and using the label value to forward packets, including determining the value of any replacement label. See [1]
ラベルの切り換えはラベルをForwarding Equivalence Classesに関連づけて、パケットを進めるのにラベル値を使用することによって、達成されます、どんな交換ラベルの値も決定するのを含んでいて。 見てください。[1]
Davie Standards Track [Page 5] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
自由民主党を使用するデイビー標準化過程[5ページ]RFC3035MPLSと2001年1月に切り替わる気圧VC
for further details. In an ATM-LSR, the label is carried in the VPI/VCI field, or, when two ATM-LSRs are connected via an ATM "Virtual Path", in the VCI field.
さらに詳しい明細については。 2ATM-LSRsがATM「仮想の経路」を通して接続されるとき、または、ラベルはVPI/VCI分野でATM-LSRでは、運ばれます、VCI分野で。
Labeled packets MUST be transmitted using the null encapsulation, as defined in Section 6.1 of RFC 2684 [5].
ヌルカプセル化を使用して、RFC2684[5]のセクション6.1で定義されるようにラベルされたパケットを伝えなければなりません。
In addition, if two LDP peers are connected via an LC-ATM interface, a non-MPLS connection, capable of carrying unlabelled IP packets, MUST be available. This non-MPLS connection is used to carry LDP packets between the two peers, and MAY also be used (but is not required to be used) for other unlabeled packets (such as OSPF packets, etc.). The LLC/SNAP encapsulation of RFC 2684 [5] MUST be used on the non-MPLS connection.
さらに、2人の自由民主党の同輩がLC-ATMインタフェースを通して接されるなら、非ラベルされたIPパケットを運ぶことができる非MPLS接続は手があいていなければなりません。 この非MPLS接続は、2人の同輩の間まで自由民主党パケットを運ぶのに使用されて、また、他のラベルされていないパケット(OSPFパケットなどの)に使用されるかもしれません(しかし、使用されるのが必要ではありません)。 非MPLS接続のときにRFC2684[5]のLLC/SNAPカプセル化を使用しなければなりません。
It SHOULD be possible to configure an LC-ATM interface with additional VPI/VCIs that are used to carry control information or non-labelled packets. In that case, the VCI values MUST NOT be in the 0-32 range. These may use either the null encapsulation, as defined in Section 6.1 of RFC 2684 [5], or the LLC/SNAP encapsulation, as defined in Section 5.1 of RFC 2684 [5].
それ、SHOULD、制御情報を運ぶのに使用される追加VPI/VCIsか非ラベルされたパケットとのLC-ATMインタフェースを構成するのにおいて、可能であってください。 その場合、VCI値が0-32範囲にあるはずがありません。 これらはヌルカプセル化を使用するかもしれません、RFC2684[5]のセクション5.1における定義されるとしてのRFC2684[5]のセクション6.1、またはLLC/SNAPカプセル化で定義されるように。
7.1. Direct Connections
7.1. ダイレクトコネクションズ
We say that two LSRs are "directly connected" over an LC-ATM interface if all cells transmitted out that interface by one LSR will reach the other, and there are no ATM switches between the two LSRs.
私たちは、あるLSRによってそのインタフェースから伝えられたすべてのセルがもう片方に達して、2LSRsの間には、ATMスイッチが全くなければ2LSRsがLC-ATMインタフェースの上に「直接接続される」と言います。
When two LSRs are directly connected via an LC-ATM interface, they jointly control the allocation of VPIs/VCIs on the interface connecting them. They may agree to use the VPI/VCI field to encode a single label.
2LSRsがLC-ATMインタフェースを通して直接接続されるとき、彼らは、彼らを接続しながら、インタフェースで共同でVPIs/VCIsの配分を制御します。 彼らは、単一のラベルをコード化するのにVPI/VCI分野を使用するのに同意するかもしれません。
The default VPI/VCI value for the non-MPLS connection is VPI 0, VCI 32. Other values can be configured, as long as both parties are aware of the configured value.
VCI32、非MPLS接続のためのデフォルトVPI/VCI価値はVPI0です。 双方が構成された価値を意識している限り、他の値を構成できます。
A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST NOT be used as the encoding of a label.
ラベルのコード化として0-32 VCI部分が範囲で包括的であるVPI/VCI値を使用してはいけません。
With the exception of these reserved values, the VPI/VCI values used in the two directions of the link MAY be treated as independent spaces.
これらの予約された値を除いて、リンクの2つの方向に使用されるVPI/VCI値は独立している空間として扱われるかもしれません。
The allowable ranges of VCIs are communicated through LDP.
VCIsの許容できる範囲は自由民主党を通して伝えられます。
Davie Standards Track [Page 6] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
自由民主党を使用するデイビー標準化過程[6ページ]RFC3035MPLSと2001年1月に切り替わる気圧VC
7.2. Connections via an ATM VP
7.2. ATM VPを通したコネクションズ
Sometimes it can be useful to treat two LSRs as adjacent (in some LSP) across an LC-ATM interface, even though the connection between them is made through an ATM "cloud" via an ATM Virtual Path. In this case, the VPI field is not available to MPLS, and the label MUST be encoded entirely within the VCI field.
時々、それはLC-ATMインタフェースの向こう側に隣接していた状態で(いくらかのLSPの)2LSRsを扱うために役に立つ場合があります、彼らの間の接続はATM Virtual Pathを通してATM「雲」を通して作られていますが。 この場合、VPI分野はMPLSに利用可能ではありません、そして、完全にVCI分野の中でラベルをコード化しなければなりません。
In this case, the default VCI value of the non-MPLS connection between the LSRs is 32. Other values can be configured, as long as both parties are aware of the configured value. The VPI is set to whatever is required to make use of the Virtual Path.
この場合、LSRsの間の非MPLS接続のデフォルトVCI価値は32です。 双方が構成された価値を意識している限り、他の値を構成できます。 VPIはVirtual Pathを利用するのに必要であることなら何でもに用意ができています。
A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST NOT be used as the encoding of a label.
ラベルのコード化として0-32 VCI部分が範囲で包括的であるVPI/VCI値を使用してはいけません。
With the exception of these reserved values, the VPI/VCI values used in the two directions of the link MAY be treated as independent spaces.
これらの予約された値を除いて、リンクの2つの方向に使用されるVPI/VCI値は独立している空間として扱われるかもしれません。
The allowable ranges of VPI/VCIs are communicated through LDP. If more than one VPI is used for label switching, the allowable range of VCIs may be different for each VPI, and each range is communicated through LDP.
VPI/VCIsの許容できる範囲は自由民主党を通して伝えられます。 1VPIがラベルの切り換えに使用されるなら、各VPIにおいて、VCIsの許容できる範囲は異なるかもしれません、そして、各範囲は自由民主党を通して伝えられます。
7.3. Connections via an ATM SVC
7.3. ATM SVCを通したコネクションズ
Sometimes it may be useful to treat two LSRs as adjacent (in some LSP) across an LC-ATM interface, even though the connection between them is made through an ATM "cloud" via a set of ATM Switched Virtual Circuits.
時々、それはLC-ATMインタフェースの向こう側に隣接していた状態で(いくらかのLSPの)2LSRsを扱うために役に立つかもしれません、彼らの間の接続はATM Switched Virtual Circuitsの1セットを通してATM「雲」を通して作られていますが。
The current document does not specify the procedure for handling this case. Such procedures can be found in [4]. The procedures described in [4] allow a VCID to be assigned to each such VC, and specify how LDP can be used used to bind a VCID to a FEC. The top label of a received packet would then be inferred (via a one-to-one mapping) from the virtual circuit on which the packet arrived. There would not be a default VPI or VCI value for the non-MPLS connection.
現在のドキュメントは本件を扱うための手順を指定しません。 [4]でそのような手順を見つけることができます。 [4]で説明された手順は、VCIDがそのような各VCに割り当てられるのを許容して、どうFECにVCIDを縛るのにおいて使用されていた状態で自由民主党を使用できるかを指定します。 そして、容認されたパケットのトップラベルはパケットが到着した仮想のサーキットから推論されるでしょう(1〜1つのマッピングで)。 非MPLS接続のためのデフォルトVPIかVCI値がないでしょう。
8. Label Distribution and Maintenance Procedures
8. ラベル分配と保守手順
This document discusses the use of "downstream-on-demand" label distribution (see [1]) by ATM-LSRs. These label distribution procedures MUST be used by ATM-LSRs that do not support VC-merge, and MAY also be used by ATM-LSRs that do support VC-merge. The procedures differ somewhat in the two cases, however. We therefore describe the two scenarios in turn. We begin by describing the
このドキュメントは「川下要求次第」のラベル分配の使用について議論します。(ATM-LSRsで[1])を見てください。 これらのラベル分配手順は、VC-マージを支持しないATM-LSRsが用いなければならなくて、また、VC-マージを支持するATM-LSRsによって用いられるかもしれません。 しかしながら、手順はいくらか2つの場合において異なります。したがって、私たちは順番に2つのシナリオについて説明します。 私たちは、説明することによって、始めます。
Davie Standards Track [Page 7] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
自由民主党を使用するデイビー標準化過程[7ページ]RFC3035MPLSと2001年1月に切り替わる気圧VC
behavior of members of the Edge Set of an ATM-LSR domain; these "Edge LSRs" are not themselves ATM-LSRs, and their behavior is the same whether the domain contains VC-merge capable LSRs or not.
ATM-LSRドメインのEdge Setのメンバーの振舞い。 これらの「縁のLSRs」は自分たちでATM-LSRsではありません、そして、ドメインがVC-マージのできるLSRsを含んでいるか否かに関係なく、彼らの振舞いは同じです。
8.1. Edge LSR Behavior
8.1. 縁のLSRの振舞い
Consider a member of the Edge Set of an ATM-LSR domain. Assume that, as a result of its routing calculations, it selects an ATM-LSR as the next hop of a certain FEC, and that the next hop is reachable via a LC-ATM interface. The Edge LSR uses LDP to request a label binding for that FEC from the next hop. The hop count field in the request is set to 1 (but see the next paragraph). Once the Edge LSR receives the label binding information, it may use MPLS forwarding procedures to transmit packets in the specified FEC, using the specified label as an outgoing label. (Or using the VPI/VCI that corresponds to the specified VCID as the outgoing label, if the VCID technique of [4] is being used.)
ATM-LSRドメインのEdge Setのメンバーを考えてください。 ルーティング計算の結果、あるFECの次のホップとしてATM-LSRを選定して、次のホップがLC-ATMインタフェースを通して届いていると仮定してください。 Edge LSRは、次のホップからそのFECで固まるラベルを要求するのに自由民主党を使用します。 要求におけるホップカウント分野は1に設定されます(次のパラグラフを見てください)。 Edge LSRがいったん情報を縛るラベルを受けると、指定されたFECでパケットを伝えるために手順を進めながら、MPLSを使用するかもしれません、出発しているラベルとして指定されたラベルを使用して。 (または、VPI/VCIを使用して、それは出発しているラベルとして指定されたVCIDに対応しています、[4]のVCIDのテクニックが使用されているなら。)
Note: if the Edge LSR's previous hop is using downstream-on-demand label distribution to request a label from the Edge LSR for a particular FEC, and if the Edge LSR is not merging the LSP from that previous hop with any other LSP, and if the request from the previous hop has a hop count of h, then the hop count in the request issued by the Edge LSR should not be set to 1, but rather to h+1.
以下に注意してください。 Edge LSRの前のホップが特定のFECのためにEdge LSRからラベルを要求するのに川下要求次第のラベル分配を使用していて、Edge LSRがLSPをその前のホップからLSPといかなる他のも前のホップからの要求ではhのホップカウントがあるかどうかと合併していないなら、Edge LSRによって出された要求におけるホップカウントは1に設定されるのではなく、むしろh+1に設定されるべきです。
The binding received by the edge LSR may contain a hop count, which represents the number of hops a packet will take to cross the ATM-LSR domain when using this label. If there is a hop count associated with the binding, the ATM-LSR SHOULD adjust a data packet's TTL by this amount before transmitting the packet. In any event, it MUST adjust a data packet's TTL by at least one before transmitting it. The procedures for doing so (in the case of IP packets) are specified in section 10. The procedures for encapsulating the packets are specified in section 9.
縁のLSRによって受けられた結合はホップカウントを含むかもしれません。(それは、パケットがこのラベルを使用するとき、ATM-LSRドメインに交差するように取るホップの数を表します)。 結合に関連しているホップカウントがあれば、パケットを伝える前に、この量に応じて、ATM-LSR SHOULDはデータ・パケットのTTLを調整します。 とにかく、それを伝える前に、それは少なくとも1時までにデータ・パケットのTTLを調整しなければなりません。 そう(IPパケットのケースで)するための手順はセクション10で指定されます。 パケットをカプセルに入れるための手順はセクション9で指定されます。
When a member of the Edge Set of the ATM-LSR domain receives a label binding request from an ATM-LSR, it allocates a label, and returns (via LDP) a binding containing the allocated label back to the peer that originated the request. It sets the hop count in the binding to 1.
ATM-LSRドメインのEdge SetのメンバーがATM-LSRから要求を縛るラベルを受け取るとき、それは、ラベルを割り当てて、要求を溯源した同輩に割り当てられたラベルを含んで戻す結合を返します(自由民主党を通して)。 それは1との結合にホップカウントをはめ込みます。
When a routing calculation causes an Edge LSR to change the next hop for a particular FEC, and the former next hop was in the ATM-LSR domain, the Edge LSR SHOULD notify the former next hop (via LDP) that the label binding associated with the FEC is no longer needed.
Edge LSRが特定のFECのためにルーティング計算で次のホップを変えて、次の前のホップがATM-LSRドメインにあったとき、Edge LSR SHOULDは、FECに関連しているラベル結合はもう必要でないように次の前のホップ(自由民主党を通した)に通知します。
Davie Standards Track [Page 8] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
自由民主党を使用するデイビー標準化過程[8ページ]RFC3035MPLSと2001年1月に切り替わる気圧VC
8.2. Conventional ATM Switches (non-VC-merge)
8.2. 従来の気圧スイッチ(非VCのマージ)
When an ATM-LSR receives (via LDP) a label binding request for a certain FEC from a peer connected to the ATM-LSR over a LC-ATM interface, the ATM-LSR takes the following actions:
ATM-LSRがLC-ATMインタフェースの上のATM-LSRに接続された同輩からあるFECを求める要求を縛るラベルを受けるとき(自由民主党を通して)、ATM-LSRは以下の行動を取ります:
- it allocates a label,
- それはラベルを割り当てます。
- it requests (via LDP) a label binding from the next hop for
that FEC;
- それは次のホップからそのFECで固まるラベルを要求します(自由民主党を通して)。
- it returns (via LDP) a binding containing the allocated
incoming label back to the peer that originated the request.
- それは要求を溯源した同輩に割り当てられた入って来るラベルを含んで戻す結合を返します(自由民主党を通して)。
For purposes of this procedure, we define a maximum hop count value MAXHOP. MAXHOP has a default value of 255, but may be configured to a different value.
この手順の目的のために、私たちは最大のホップカウント値のMAXHOPを定義します。 MAXHOPは255のデフォルト値を持っていますが、異価に構成されるかもしれません。
The hop count field in the request that the ATM-LSR sends (to the next hop LSR) MUST be set to one more than the hop count field in the request that it received from the upstream LSR. If the resulting hop count exceeds MAXHOP, the request MUST NOT be sent to the next hop, and the ATM-LSR MUST notify the upstream neighbor that its binding request cannot be satisfied.
ATM-LSRが発信するという(次のホップLSRに)要求におけるホップカウント分野は1つへの上流のLSRから受信したという要求におけるホップカウント分野よりさらにセットであるに違いありません。 結果として起こるホップカウントがMAXHOPを超えているなら、次のホップに要求を送ってはいけません、そして、ATM-LSR MUSTは拘束力がある要求を満たすことができないように上流の隣人に通知します。
Otherwise, once the ATM-LSR receives the binding from the next hop, it begins using that label.
さもなければ、ATM-LSRが次のホップから結合をいったん受けると、それはそのラベルを使用し始めます。
The ATM-LSR MAY choose to wait for the request to be satisfied from downstream before returning the binding upstream. This is a form of "ordered control" (as defined in [1] and [2]), in particular "ingress-initiated ordered control". In this case, as long as the ATM-LSR receives from downstream a hop count which is greater than 0 and less than MAXHOP, it MUST increment the hop count it receives from downstream and MUST include the result in the binding it returns upstream. However, if the hop count exceeds MAXHOP, a label binding MUST NOT be passed upstream. Rather, the upstream LDP peer MUST be informed that the requested label binding cannot be satisfied. If the hop count received from downstream is 0, the hop count passed upstream should also be 0; this indicates that the actual hop count is unknown.
ATM-LSR MAYは、拘束力がある上流を返す前に川下から満たされるという要求を待つのを選びます。 これはフォームの「命令されたコントロール」です。([1]と[2])、特定の「イングレスで開始している命令されたコントロール」で定義されるように。 この場合、ATM-LSRが川下からMAXHOPより0以上と以下であるホップカウントを受ける限り、それは、それが川下から受けるホップカウントを増加しなければならなくて、上流へ返す結合に結果を含まなければなりません。 しかしながら、ホップカウントがMAXHOPを超えているなら、上流へラベル結合を通過してはいけません。 むしろ、要求されたラベル結合を満たすことができないと上流の自由民主党の同輩を知らさなければなりません。 また、川下から受けられたホップカウントが0であるなら、上流へ通過されたホップカウントは0であるべきです。 これは、実際のホップカウントが未知であることを示します。
Alternatively, the ATM-LSR MAY return the binding upstream without
waiting for a binding from downstream ("independent" control, as
defined in [1] and [2]). In this case, it specifies a hop count of 0
in the binding, indicating that the true hop count is unknown. The
correct value for hop count will be returned later, as described
below.
川下から結合を待たないで、あるいはまた、ATM-LSR MAYは拘束力がある上流を返します。([1]と[2])で定義されるような「独立している」コントロール。 この場合、結合における、0のホップカウントを指定します、本当のホップカウントが未知であることを示して。 後で以下で説明されるようにホップカウントのための正しい値を返すでしょう。
Davie Standards Track [Page 9] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
自由民主党を使用するデイビー標準化過程[9ページ]RFC3035MPLSと2001年1月に切り替わる気圧VC
Note that an ATM-LSR, or a member of the edge set of an ATM-LSR domain, may receive multiple binding requests for the same FEC from the same ATM-LSR. It MUST generate a new binding for each request (assuming adequate resources to do so), and retain any existing binding(s). For each request received, an ATM-LSR MUST also generate a new binding request toward the next hop for the FEC.
ATM-LSR、またはATM-LSRドメインの縁のセットのメンバーが同じATM-LSRから同じFECにおいて複数の拘束力がある要求を受け取るかもしれないことに注意してください。 それは、各要求(そうするために適切なリソースを仮定する)のための新しい結合を発生させて、どんな既存の結合も保有しなければなりません。 それぞれに関しては、受け取られた要求、ATM-LSR MUSTもFECのために新しい拘束力がある要求を次のホップに向かって発生させます。
When a routing calculation causes an ATM-LSR to change the next hop for a FEC, the ATM-LSR MUST notify the former next hop (via LDP) that the label binding associated with the FEC is no longer needed.
ATM-LSRがFECのためにルーティング計算で次のホップを変えると、ATM-LSR MUSTは、FECに関連しているラベル結合はもう必要でないように次の前のホップ(自由民主党を通した)に通知します。
When a LSR receives a notification that a particular label binding is no longer needed, the LSR MAY deallocate the label associated with the binding, and destroy the binding. In the case where an ATM-LSR receives such notification and destroys the binding, it MUST notify the next hop for the FEC that the label binding is no longer needed. If a LSR does not destroy the binding, it may re-use the binding only if it receives a request for the same FEC with the same hop count as the request that originally caused the binding to be created.
LSRが通知を受け取るとき、特定のラベル結合はもう必要でなく、LSR MAY deallocateがラベルであることは、結合と交際して、結合を破壊します。 ATM-LSRがそのような通知を受け取って、結合を破壊する場合では、それは、FECのためにラベル結合はもう必要でないように次のホップに通知しなければなりません。 同じFECを求める元々結合を作成した要求と同じホップカウントによる要求を受け取ってだけ、LSRが結合を破壊しないなら、それは結合を再使用するかもしれません。
When a route changes, the label bindings are re-established from the point where the route diverges from the previous route. LSRs upstream of that point are (with one exception, noted below) oblivious to the change.
ルートが変化するとき、ラベル結合はルートが前のルートからそれるポイントから復職します。 そのポイントのLSRs上流は変化に気づかない(ただ1つを例外として有名な下)です。
Whenever a LSR changes its next hop for a particular FEC, if the new next hop is reachable via an LC-ATM interface, then for each label that it has bound to that FEC, and distributed upstream, it MUST request a new label binding from the new next hop.
LSRが特定のFECのために次のホップを変えるときはいつも、次の新しいホップがLC-ATMインタフェースを通して届くなら、そのFECに縛って、上流へ分配した各ラベルに関して、それは次の新しいホップから固まる新しいラベルを要求しなければなりません。
When an ATM-LSR receives a label binding for a particular FEC from a downstream neighbor, it may already have provided a corresponding label binding for this FEC to an upstream neighbor, either because it is using independent control, or because the new binding from downstream is the result of a routing change. In this case, unless the hop count is 0, it MUST extract the hop count from the new binding and increment it by one. If the new hop count is different from that which was previously conveyed to the upstream neighbor (including the case where the upstream neighbor was given the value 'unknown') the ATM-LSR MUST notify the upstream neighbor of the change. Each ATM-LSR in turn MUST increment the hop count and pass it upstream until it reaches the ingress Edge LSR. If at any point the value of the hop count equals MAXHOP, the ATM-LSR SHOULD withdraw the binding from the upstream neighbor. A hop count of 0 MUST be passed upstream unchanged.
When an ATM-LSR receives a label binding for a particular FEC from a downstream neighbor, it may already have provided a corresponding label binding for this FEC to an upstream neighbor, either because it is using independent control, or because the new binding from downstream is the result of a routing change. In this case, unless the hop count is 0, it MUST extract the hop count from the new binding and increment it by one. If the new hop count is different from that which was previously conveyed to the upstream neighbor (including the case where the upstream neighbor was given the value 'unknown') the ATM-LSR MUST notify the upstream neighbor of the change. Each ATM-LSR in turn MUST increment the hop count and pass it upstream until it reaches the ingress Edge LSR. If at any point the value of the hop count equals MAXHOP, the ATM-LSR SHOULD withdraw the binding from the upstream neighbor. A hop count of 0 MUST be passed upstream unchanged.
Davie Standards Track [Page 10] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
Davie Standards Track [Page 10] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
Whenever an ATM-LSR originates a label binding request to its next hop LSR as a result of receiving a label binding request from another (upstream) LSR, and the request to the next hop LSR is not satisfied, the ATM-LSR SHOULD destroy the binding created in response to the received request, and notify the requester (via LDP).
Whenever an ATM-LSR originates a label binding request to its next hop LSR as a result of receiving a label binding request from another (upstream) LSR, and the request to the next hop LSR is not satisfied, the ATM-LSR SHOULD destroy the binding created in response to the received request, and notify the requester (via LDP).
If an ATM-LSR receives a binding request containing a hop count that exceeds MAXHOP, it MUST not establish a binding, and it MUST return an error to the requester.
If an ATM-LSR receives a binding request containing a hop count that exceeds MAXHOP, it MUST not establish a binding, and it MUST return an error to the requester.
When a LSR determines that it has lost its LDP session with another LSR, the following actions are taken. Any binding information learned via this connection MUST be discarded. For any label bindings that were created as a result of receiving label binding requests from the peer, the LSR MAY destroy these bindings (and deallocate labels associated with these binding).
When a LSR determines that it has lost its LDP session with another LSR, the following actions are taken. Any binding information learned via this connection MUST be discarded. For any label bindings that were created as a result of receiving label binding requests from the peer, the LSR MAY destroy these bindings (and deallocate labels associated with these binding).
An ATM-LSR SHOULD use 'split-horizon' when it satisfies binding requests from its neighbors. That is, if it receives a request for a binding to a particular FEC and the LSR making that request is, according to this ATM-LSR, the next hop for that FEC, it should not return a binding for that route.
An ATM-LSR SHOULD use 'split-horizon' when it satisfies binding requests from its neighbors. That is, if it receives a request for a binding to a particular FEC and the LSR making that request is, according to this ATM-LSR, the next hop for that FEC, it should not return a binding for that route.
It is expected that non-merging ATM-LSRs would generally use "conservative label retention mode" [1].
It is expected that non-merging ATM-LSRs would generally use "conservative label retention mode" [1].
8.3. VC-merge-capable ATM Switches
8.3. VC-merge-capable ATM Switches
Relatively minor changes are needed to accommodate ATM-LSRs which support VC-merge. The primary difference is that a VC-merge-capable ATM-LSR needs only one outgoing label per FEC, even if multiple requests for label bindings to that FEC are received from upstream neighbors.
Relatively minor changes are needed to accommodate ATM-LSRs which support VC-merge. The primary difference is that a VC-merge-capable ATM-LSR needs only one outgoing label per FEC, even if multiple requests for label bindings to that FEC are received from upstream neighbors.
When a VC-merge-capable ATM-LSR receives a binding request from an upstream LSR for a certain FEC, and it does not already have an outgoing label binding for that FEC (or an outstanding request for such a label binding), it MUST issue a bind request to its next hop just as it would do if it were not merge-capable. If, however, it already has an outgoing label binding for that FEC, it does not need to issue a downstream binding request. Instead, it may simply allocate an incoming label, and return that label in a binding to the upstream requester. When packets with that label as top label are received from the requester, the top label value will be replaced with the existing outgoing label value that corresponds to the same FEC.
When a VC-merge-capable ATM-LSR receives a binding request from an upstream LSR for a certain FEC, and it does not already have an outgoing label binding for that FEC (or an outstanding request for such a label binding), it MUST issue a bind request to its next hop just as it would do if it were not merge-capable. If, however, it already has an outgoing label binding for that FEC, it does not need to issue a downstream binding request. Instead, it may simply allocate an incoming label, and return that label in a binding to the upstream requester. When packets with that label as top label are received from the requester, the top label value will be replaced with the existing outgoing label value that corresponds to the same FEC.
Davie Standards Track [Page 11] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
Davie Standards Track [Page 11] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
If the ATM-LSR does not have an outgoing label binding for the FEC, but does have an outstanding request for one, it need not issue another request.
If the ATM-LSR does not have an outgoing label binding for the FEC, but does have an outstanding request for one, it need not issue another request.
When sending a label binding upstream, the hop count associated with the corresponding binding from downstream MUST be incremented by 1, and the result transmitted upstream as the hop count associated with the new binding. However, there are two exceptions: a hop count of 0 MUST be passed upstream unchanged, and if the hop count is already at MAXHOP, the ATM-LSR MUST NOT pass a binding upstream, but instead MUST send an error upstream.
When sending a label binding upstream, the hop count associated with the corresponding binding from downstream MUST be incremented by 1, and the result transmitted upstream as the hop count associated with the new binding. However, there are two exceptions: a hop count of 0 MUST be passed upstream unchanged, and if the hop count is already at MAXHOP, the ATM-LSR MUST NOT pass a binding upstream, but instead MUST send an error upstream.
Note that, just like conventional ATM-LSRs and members of the edge set of the ATM-LSR domain, a VC-merge-capable ATM-LSR MUST issue a new binding every time it receives a request from upstream, since there may be switches upstream which do not support VC-merge. However, it only needs to issue a corresponding binding request downstream if it does not already have a label binding for the appropriate route.
Note that, just like conventional ATM-LSRs and members of the edge set of the ATM-LSR domain, a VC-merge-capable ATM-LSR MUST issue a new binding every time it receives a request from upstream, since there may be switches upstream which do not support VC-merge. However, it only needs to issue a corresponding binding request downstream if it does not already have a label binding for the appropriate route.
When a change in the routing table of a VC-merge-capable ATM-LSR causes it to select a new next hop for one of its FECs, it MAY optionally release the binding for that route from the former next hop. If it doesn't already have a corresponding binding for the new next hop, it must request one. (The choice between conservative and liberal label retention mode [1] is an implementation option.)
When a change in the routing table of a VC-merge-capable ATM-LSR causes it to select a new next hop for one of its FECs, it MAY optionally release the binding for that route from the former next hop. If it doesn't already have a corresponding binding for the new next hop, it must request one. (The choice between conservative and liberal label retention mode [1] is an implementation option.)
If a new binding is obtained, which contains a hop count that differs from that which was received in the old binding, then the ATM-LSR must take the new hop count, increment it by one, and notify any upstream neighbors who have label bindings for this FEC of the new value. Just as with conventional ATM-LSRs, this enables the new hop count to propagate back towards the ingress of the ATM-LSR domain. If at any point the hop count exceeds MAXHOP, then the label bindings for this route must be withdrawn from all upstream neighbors to whom a binding was previously provided. This ensures that any loops caused by routing transients will be detected and broken.
If a new binding is obtained, which contains a hop count that differs from that which was received in the old binding, then the ATM-LSR must take the new hop count, increment it by one, and notify any upstream neighbors who have label bindings for this FEC of the new value. Just as with conventional ATM-LSRs, this enables the new hop count to propagate back towards the ingress of the ATM-LSR domain. If at any point the hop count exceeds MAXHOP, then the label bindings for this route must be withdrawn from all upstream neighbors to whom a binding was previously provided. This ensures that any loops caused by routing transients will be detected and broken.
9. Encapsulation
9. Encapsulation
The procedures described in this section affect only the Edge LSRs of the ATM-LSR domain. The ATM-LSRs themselves do not modify the encapsulation in any way.
The procedures described in this section affect only the Edge LSRs of the ATM-LSR domain. The ATM-LSRs themselves do not modify the encapsulation in any way.
Labeled packets MUST be transmitted using the null encapsulation of Section 6.1 of RFC 2684 [5].
Labeled packets MUST be transmitted using the null encapsulation of Section 6.1 of RFC 2684 [5].
Davie Standards Track [Page 12] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
Davie Standards Track [Page 12] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
Except in certain circumstances specified below, when a labeled packet is transmitted on an LC-ATM interface, where the VPI/VCI (or VCID) is interpreted as the top label in the label stack, the packet MUST also contain a "shim header" [3].
Except in certain circumstances specified below, when a labeled packet is transmitted on an LC-ATM interface, where the VPI/VCI (or VCID) is interpreted as the top label in the label stack, the packet MUST also contain a "shim header" [3].
If the packet has a label stack with n entries, it MUST carry a shim with n entries. The actual value of the top label is encoded in the VPI/VCI field. The label value of the top entry in the shim (which is just a "placeholder" entry) MUST be set to 0 upon transmission, and MUST be ignored upon reception. The packet's outgoing TTL, and its CoS, are carried in the TTL and CoS fields respectively of the top stack entry in the shim.
If the packet has a label stack with n entries, it MUST carry a shim with n entries. The actual value of the top label is encoded in the VPI/VCI field. The label value of the top entry in the shim (which is just a "placeholder" entry) MUST be set to 0 upon transmission, and MUST be ignored upon reception. The packet's outgoing TTL, and its CoS, are carried in the TTL and CoS fields respectively of the top stack entry in the shim.
Note that if a packet has a label stack with only one entry, this requires it to have a single-entry shim (4 bytes), even though the actual label value is encoded into the VPI/VCI field. This is done to ensure that the packet always has a shim. Otherwise, there would be no way to determine whether it had one or not, i.e., no way to determine whether there are additional label stack entries.
Note that if a packet has a label stack with only one entry, this requires it to have a single-entry shim (4 bytes), even though the actual label value is encoded into the VPI/VCI field. This is done to ensure that the packet always has a shim. Otherwise, there would be no way to determine whether it had one or not, i.e., no way to determine whether there are additional label stack entries.
The only ways to eliminate this extra overhead are:
The only ways to eliminate this extra overhead are:
- through apriori knowledge that packets have only a single label
(e.g., perhaps the network only supports one level of label)
- through apriori knowledge that packets have only a single label (e.g., perhaps the network only supports one level of label)
- by using two VCs per FEC, one for those packets which have only
a single label, and one for those packets which have more than
one label
- by using two VCs per FEC, one for those packets which have only a single label, and one for those packets which have more than one label
The second technique would require that there be some way of signalling via LDP that the VC is carrying only packets with a single label, and is not carrying a shim. When supporting VC merge, one would also have to take care not to merge a VC on which the shim is not used into a VC on which it is used, or vice versa.
The second technique would require that there be some way of signalling via LDP that the VC is carrying only packets with a single label, and is not carrying a shim. When supporting VC merge, one would also have to take care not to merge a VC on which the shim is not used into a VC on which it is used, or vice versa.
While either of these techniques is permitted, it is doubtful that they have any practical utility. Note that if the shim header is not present, the outgoing TTL is carried in the TTL field of the network layer header.
While either of these techniques is permitted, it is doubtful that they have any practical utility. Note that if the shim header is not present, the outgoing TTL is carried in the TTL field of the network layer header.
10. TTL Manipulation
10. TTL Manipulation
The procedures described in this section affect only the Edge LSRs of the ATM-LSR domain. The ATM-LSRs themselves do not modify the TTL in any way.
The procedures described in this section affect only the Edge LSRs of the ATM-LSR domain. The ATM-LSRs themselves do not modify the TTL in any way.
Davie Standards Track [Page 13] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
Davie Standards Track [Page 13] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
The details of the TTL adjustment procedure are as follows. If a packet was received by the Edge LSR as an unlabeled packet, the "incoming TTL" comes from the IP header. (Procedures for other network layer protocols are for further study.) If a packet was received by the Edge LSR as a labeled packet, using the encapsulation specified in [3], the "incoming TTL" comes from the entry at the top of the label stack.
The details of the TTL adjustment procedure are as follows. If a packet was received by the Edge LSR as an unlabeled packet, the "incoming TTL" comes from the IP header. (Procedures for other network layer protocols are for further study.) If a packet was received by the Edge LSR as a labeled packet, using the encapsulation specified in [3], the "incoming TTL" comes from the entry at the top of the label stack.
If a hop count has been associated with the label binding that is used when the packet is forwarded, the "outgoing TTL" is set to the larger of (a) 0 or (b) the difference between the incoming TTL and the hop count. If a hop count has not been associated with the label binding that is used when the packet is forwarded, the "outgoing TTL" is set to the larger of (a) 0 or (b) one less than the incoming TTL.
If a hop count has been associated with the label binding that is used when the packet is forwarded, the "outgoing TTL" is set to the larger of (a) 0 or (b) the difference between the incoming TTL and the hop count. If a hop count has not been associated with the label binding that is used when the packet is forwarded, the "outgoing TTL" is set to the larger of (a) 0 or (b) one less than the incoming TTL.
If this causes the outgoing TTL to become zero, the packet MUST NOT be transmitted as a labeled packet using the specified label. The packet can be treated in one of two ways:
If this causes the outgoing TTL to become zero, the packet MUST NOT be transmitted as a labeled packet using the specified label. The packet can be treated in one of two ways:
- it may be treated as having expired; this may cause an ICMP
message to be transmitted;
- it may be treated as having expired; this may cause an ICMP message to be transmitted;
- the packet may be forwarded, as an unlabeled packet, with a TTL
that is 1 less than the incoming TTL; such forwarding would
need to be done over a non-MPLS connection.
- the packet may be forwarded, as an unlabeled packet, with a TTL that is 1 less than the incoming TTL; such forwarding would need to be done over a non-MPLS connection.
Of course, if the incoming TTL is 1, only the first of these two options is applicable.
Of course, if the incoming TTL is 1, only the first of these two options is applicable.
If the packet is forwarded as a labeled packet, the outgoing TTL is carried as specified in section 9.
If the packet is forwarded as a labeled packet, the outgoing TTL is carried as specified in section 9.
When an Edge LSR receives a labeled packet over an LC-ATM interface, it obtains the incoming TTL from the top label stack entry of the generic encapsulation, or, if that encapsulation is not present, from the IP header.
When an Edge LSR receives a labeled packet over an LC-ATM interface, it obtains the incoming TTL from the top label stack entry of the generic encapsulation, or, if that encapsulation is not present, from the IP header.
If the packet's next hop is an ATM-LSR, the outgoing TTL is formed using the procedures described in this section. Otherwise the outgoing TTL is formed using the procedures described in [3].
If the packet's next hop is an ATM-LSR, the outgoing TTL is formed using the procedures described in this section. Otherwise the outgoing TTL is formed using the procedures described in [3].
The procedures in this section are intended to apply only to unicast packets.
The procedures in this section are intended to apply only to unicast packets.
Davie Standards Track [Page 14] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
Davie Standards Track [Page 14] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
11. Optional Loop Detection: Distributing Path Vectors
11. Optional Loop Detection: Distributing Path Vectors
Every ATM-LSR MUST implement, as a configurable option, the following procedure for detecting forwarding loops. We refer to this as the LDPV (Loop Detection via Path Vectors) procedure. This procedure does not prevent the formation of forwarding loops, but does ensure that any such loops are detected. If this option is not enabled, loops are detected by the hop count mechanism previously described. If this option is enabled, loops will be detected more quickly, but at a higher cost in overhead.
Every ATM-LSR MUST implement, as a configurable option, the following procedure for detecting forwarding loops. We refer to this as the LDPV (Loop Detection via Path Vectors) procedure. This procedure does not prevent the formation of forwarding loops, but does ensure that any such loops are detected. If this option is not enabled, loops are detected by the hop count mechanism previously described. If this option is enabled, loops will be detected more quickly, but at a higher cost in overhead.
11.1. When to Send Path Vectors Downstream
11.1. When to Send Path Vectors Downstream
Suppose an LSR R sends a request for a label binding, for a particular LSP, to its next hop. Then if R does not support VC- merging, and R is configured to use the LDPV procedure:
Suppose an LSR R sends a request for a label binding, for a particular LSP, to its next hop. Then if R does not support VC- merging, and R is configured to use the LDPV procedure:
- If R is sending the request because it is an ingress node for
that LSP, or because it has acquired a new next hop, then R
MUST include a path vector object with the request, and the
path vector object MUST contain only R's own address.
- If R is sending the request because it is an ingress node for that LSP, or because it has acquired a new next hop, then R MUST include a path vector object with the request, and the path vector object MUST contain only R's own address.
- If R is sending the request as a result of having received a
request from an upstream LSR, then:
- If R is sending the request as a result of having received a request from an upstream LSR, then:
* if the received request has a path vector object, R MUST add
its own address to the received path vector object, and MUST
pass the resulting path vector object to its next hop along
with the label binding request;
* if the received request has a path vector object, R MUST add its own address to the received path vector object, and MUST pass the resulting path vector object to its next hop along with the label binding request;
* if the received request does not have a path vector object,
R MUST include a path vector object with the request it
sends, and the path vector object MUST contain only R's own
address.
* if the received request does not have a path vector object, R MUST include a path vector object with the request it sends, and the path vector object MUST contain only R's own address.
An LSR which supports VC-merge SHOULD NOT include a path vector object in the requests that it sends to its next hop.
An LSR which supports VC-merge SHOULD NOT include a path vector object in the requests that it sends to its next hop.
If an LSR receives a label binding request whose path vector object contains the address of the node itself, the LSR concludes that the label binding requests have traveled in a loop. The LSR MUST act as it would in the case where the hop count exceeds MAXHOP (see section 8.2).
If an LSR receives a label binding request whose path vector object contains the address of the node itself, the LSR concludes that the label binding requests have traveled in a loop. The LSR MUST act as it would in the case where the hop count exceeds MAXHOP (see section 8.2).
This procedure detects the case where the request messages loop though a sequence of non-merging ATM-LSRs.
This procedure detects the case where the request messages loop though a sequence of non-merging ATM-LSRs.
Davie Standards Track [Page 15] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
Davie Standards Track [Page 15] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
11.2. When to Send Path Vectors Upstream
11.2. When to Send Path Vectors Upstream
As specified in section 8, there are circumstances in which an LSR R must inform its upstream neighbors, via a label binding response message, of a change in hop count for a particular LSP. If the following conditions all hold:
As specified in section 8, there are circumstances in which an LSR R must inform its upstream neighbors, via a label binding response message, of a change in hop count for a particular LSP. If the following conditions all hold:
- R is configured for the LDPV procedure,
- R is configured for the LDPV procedure,
- R supports VC-merge,
- R supports VC-merge,
- R is not the egress for that LSP, and
- R is not the egress for that LSP, and
- R is not informing its neighbors of a decrease in the hop
count,
- R is not informing its neighbors of a decrease in the hop count,
then R MUST include a path vector object in the response message.
then R MUST include a path vector object in the response message.
If the change in hop count is a result of R's having been informed by its next hop, S, of a change in hop count, and the message from S to R included a path vector object, then if the above conditions hold, R MUST add itself to this object and pass the result upstream. Otherwise, if the above conditions hold, R MUST create a new object with only its own address.
If the change in hop count is a result of R's having been informed by its next hop, S, of a change in hop count, and the message from S to R included a path vector object, then if the above conditions hold, R MUST add itself to this object and pass the result upstream. Otherwise, if the above conditions hold, R MUST create a new object with only its own address.
If R is configured for the LDPV procedure, and R supports VC merge, then it MAY include a path vector object in any label binding response message that it sends upstream. In particular, at any time that R receives a label binding response from its next hop, if that response contains a path vector, R MAY (if configured for the LDPV procedure) send a response to its upstream neighbors, containing the path vector object formed by adding its own address to the received path vector.
If R is configured for the LDPV procedure, and R supports VC merge, then it MAY include a path vector object in any label binding response message that it sends upstream. In particular, at any time that R receives a label binding response from its next hop, if that response contains a path vector, R MAY (if configured for the LDPV procedure) send a response to its upstream neighbors, containing the path vector object formed by adding its own address to the received path vector.
If R does not support VC merge, it SHOULD NOT send a path vector object upstream.
If R does not support VC merge, it SHOULD NOT send a path vector object upstream.
If an LSR receives a message from its next hop, with a path vector object containing its own address, then LSR MUST act as it would if it received a message with a hop count equal to MAXHOP.
If an LSR receives a message from its next hop, with a path vector object containing its own address, then LSR MUST act as it would if it received a message with a hop count equal to MAXHOP.
LSRs which are configured for the LDPV procedure SHOULD NOT store a path vector once the corresponding path vector object has been transmitted.
LSRs which are configured for the LDPV procedure SHOULD NOT store a path vector once the corresponding path vector object has been transmitted.
Davie Standards Track [Page 16] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
Davie Standards Track [Page 16] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
Note that if the ATM-LSR domain consists entirely of non-merging ATM-LSRs, path vectors need not ever be sent upstream, since any loops will be detected by means of the path vectors traveling downstream.
Note that if the ATM-LSR domain consists entirely of non-merging ATM-LSRs, path vectors need not ever be sent upstream, since any loops will be detected by means of the path vectors traveling downstream.
By not sending path vectors unless the hop count increases, one avoids sending them in many situations when there is no loop. The cost is that in some situations in which there is a loop, the time to detect the loop may be lengthened.
By not sending path vectors unless the hop count increases, one avoids sending them in many situations when there is no loop. The cost is that in some situations in which there is a loop, the time to detect the loop may be lengthened.
12. Security Considerations
12. Security Considerations
The encapsulation and procedures specified in this document do not interfere in any way with the application of authentication and/or encryption to network layer packets (such as the application of IPSEC to IP datagrams).
The encapsulation and procedures specified in this document do not interfere in any way with the application of authentication and/or encryption to network layer packets (such as the application of IPSEC to IP datagrams).
The procedures described in this document do not protect against the alteration (either accidental or malicious) of MPLS labels. Such alteration could cause misforwarding.
The procedures described in this document do not protect against the alteration (either accidental or malicious) of MPLS labels. Such alteration could cause misforwarding.
The procedures described in this document do not enable a receiving LSR to authenticate the transmitting LSR.
The procedures described in this document do not enable a receiving LSR to authenticate the transmitting LSR.
A discussion of the security considerations applicable to the label distribution mechanism can be found in [2].
A discussion of the security considerations applicable to the label distribution mechanism can be found in [2].
13. Intellectual Property Considerations
13. Intellectual Property Considerations
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
Davie Standards Track [Page 17] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
Davie Standards Track [Page 17] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
14. References
14. References
[1] Rosen, E., Viswanathan, A. and R. Callon "Multi-Protocol Label
Switching Architecture", RFC 3031, January 2001.
[1] Rosen, E., Viswanathan, A. and R. Callon "Multi-Protocol Label Switching Architecture", RFC 3031, January 2001.
[2] Andersson L., Doolan P., Feldman N., Fredette A. and R. Thomas,
"LDP Specification", RFC 3036, January 2001.
[2] Andersson L., Doolan P., Feldman N., Fredette A. and R. Thomas, "LDP Specification", RFC 3036, January 2001.
[3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G.,
Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
January 2001.
[3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[4] Nagami, K., Demizu N., Esaki H. and P. Doolan, "VCID Notification
over ATM Link for LDP", RFC 3038, January 2001.
[4] Nagami, K., Demizu N., Esaki H. and P. Doolan, "VCID Notification over ATM Link for LDP", RFC 3038, January 2001.
[5] Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over ATM
Adaptation Layer 5", RFC 2684, September 1999.
[5] Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
15. Acknowledgments
15. Acknowledgments
Significant contributions to this work have been made by Anthony Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan Littlewood and Dan Tappan. We thank Alex Conta for his comments.
Significant contributions to this work have been made by Anthony Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan Littlewood and Dan Tappan. We thank Alex Conta for his comments.
16. Authors' Addresses
16. Authors' Addresses
Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
EMail: bsd@cisco.com
EMail: bsd@cisco.com
Paul Doolan Ennovate Networks Inc. 60 Codman Hill Rd Boxborough, MA 01719
Paul Doolan Ennovate Networks Inc. 60 Codman Hill Rd Boxborough, MA 01719
EMail: pdoolan@ennovatenetworks.com
EMail: pdoolan@ennovatenetworks.com
Davie Standards Track [Page 18] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
Davie Standards Track [Page 18] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
Jeremy Lawrence Cisco Systems, Inc. 99 Walker St. North Sydney, NSW, Australia
Jeremy Lawrence Cisco Systems, Inc. 99 Walker St. North Sydney, NSW, Australia
EMail: jlawrenc@cisco.com
EMail: jlawrenc@cisco.com
Keith McCloghrie Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134
Keith McCloghrie Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134
EMail: kzm@cisco.com
EMail: kzm@cisco.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
EMail: erosen@cisco.com
EMail: erosen@cisco.com
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
EMail: swallow@cisco.com
EMail: swallow@cisco.com
Davie Standards Track [Page 19] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
Davie Standards Track [Page 19] RFC 3035 MPLS using LDP and ATM VC Switching January 2001
17. Full Copyright Statement
17. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright (C) The Internet Society (2001). 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.
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.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
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.
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
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Davie Standards Track [Page 20]
Davie Standards Track [Page 20]
一覧
スポンサーリンク
