[要約] RFC 6389は、LDPにおけるMPLSの上流ラベル割り当てに関する規格です。その目的は、LDPによるMPLSネットワークでの効率的なラベル割り当てを実現することです。
Internet Engineering Task Force (IETF) R. Aggarwal
Request for Comments: 6389 Juniper Networks
Category: Standards Track JL. Le Roux
ISSN: 2070-1721 Orange
November 2011
MPLS Upstream Label Assignment for LDP
LDPのMPLSアップストリームラベル割り当て
Abstract
概要
This document describes procedures for distributing upstream-assigned labels for the Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch Label Switching Router (LSR) traffic replication on a LAN for LDP point-to-multipoint (P2MP) Label Switched Paths (LSPs).
このドキュメントでは、ラベル分布プロトコル（LDP）の上流で割り当てられたラベルを配布する手順について説明します。また、LDPポイントツーマルチポイント（P2MP）ラベルスイッチ付きパス（LSP）のLANでのブランチラベルスイッチングルーター（LSR）トラフィックレプリケーションを回避するために、これらの手順を使用する方法についても説明します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6389.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6389で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. Specification of Requirements ...................................3
3. LDP Upstream Label Assignment Capability ........................3
4. Distributing Upstream-Assigned Labels in LDP ....................4
4.1. Procedures .................................................4
5. LDP Tunnel Identifier Exchange ..................................5
6. LDP Point-to-Multipoint LSPs on a LAN ...........................9
7. IANA Considerations ............................................11
7.1. LDP TLVs ..................................................11
7.2. Interface Type Identifiers ................................11
8. Security Considerations ........................................12
9. Acknowledgements ...............................................12
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................13
This document describes procedures for distributing upstream-assigned labels [RFC5331] for Label Distribution Protocol (LDP) [RFC5036]. These procedures follow the architecture for MPLS upstream label assignment described in [RFC5331].
このドキュメントでは、ラベル分布プロトコル（LDP）[RFC5036]の上流で割り当てられたラベル[RFC5331]を分配する手順について説明します。これらの手順は、[RFC5331]で説明されているMPLS上流のラベル割り当てのアーキテクチャに従います。
This document describes extensions to LDP that a Label Switching Router (LSR) can use to advertise whether the LSR supports upstream label assignment to its neighboring LSRs.
このドキュメントでは、LDPへの拡張機能が、LSRが隣接するLSRへの上流のラベル割り当てをサポートするかどうかを宣伝するためにラベルスイッチングルーター（LSR）が使用できることを説明しています。
This document also describes extensions to LDP to distribute upstream-assigned labels.
また、このドキュメントでは、上流で割り当てられたラベルを配布するためのLDPへの拡張機能についても説明しています。
The usage of MPLS upstream label assignment using LDP to avoid branch LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP) Label Switched Paths (LSPs) [RFC6388] is also described.
LDPを使用してLDPを使用したMPLS上流ラベル割り当ての使用法は、LDPポイントツーマルチポイント（P2MP）ラベルスイッチ付きパス（LSP）[RFC6388]のLAN上のブランチLSRトラフィックレプリケーションを回避します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
According to [RFC5331], upstream-assigned label bindings MUST NOT be used unless it is known that a downstream LSR supports them. This implies that there MUST be a mechanism to enable an LSR to advertise to its LDP neighbor LSR(s) its support of upstream-assigned labels.
[RFC5331]によると、下流のLSRがそれらをサポートしていることがわかっていない限り、上流のラベルバインディングを使用してはなりません。これは、LSRがLDP Neighbor LSRにアップストリーム割り当てのラベルのサポートを宣伝できるようにするメカニズムがなければならないことを意味します。
A new Capability Parameter, the LDP Upstream Label Assignment Capability, is introduced to allow an LDP peer to exchange with its peers, its support of upstream label assignment. This parameter follows the format and procedures for exchanging Capability Parameters defined in [RFC5561].
LDP上流のラベル割り当て機能である新しい機能パラメーターが導入され、LDPピアがピアと交換できるようになりました。これは、上流のラベル割り当てのサポートです。このパラメーターは、[RFC5561]で定義されている機能パラメーターを交換するための形式と手順に従います。
Following is the format of the LDP Upstream Label Assignment Capability Parameter:
以下は、LDP上流のラベル割り当て機能パラメーターの形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Upstrm Lbl Ass Cap(0x0507)| Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved |
+-+-+-+-+-+-+-+-+
If an LSR includes the Upstream Label Assignment Capability in LDP Initialization messages, it implies that the LSR is capable of both distributing upstream-assigned label bindings and receiving upstream-assigned label bindings. The reserved bits MUST be set to zero on transmission and ignored on receipt. The Upstream Label Assignment Capability Parameter MUST be carried only in LDP Initialization messages and MUST be ignored if received in LDP Capability messages.
LSRがLDP初期化メッセージにアップストリームラベル割り当て機能を含む場合、LSRは上流のラベルバインディングを配布し、アップストリーム割り当てのラベルバインディングを受信できることを意味します。予約されたビットは、送信時にゼロに設定し、受領時に無視する必要があります。上流のラベル割り当て機能パラメーターは、LDP初期化メッセージでのみ運ばれ、LDP機能メッセージで受信した場合は無視する必要があります。
An optional LDP TLV, Upstream-Assigned Label Request TLV, is introduced. To request an upstream-assigned label, an LDP peer MUST include this TLV in a Label Request message.
オプションのLDP TLV、アップストリーム割り当てラベルリクエストTLVが導入されています。アップストリーム割り当てのラベルをリクエストするには、LDPピアはこのTLVをラベル要求メッセージに含める必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|Upstrm-Ass Lbl Req (0x0205)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An optional LDP TLV, Upstream-Assigned Label TLV, is introduced to signal an upstream-assigned label. Upstream-Assigned Label TLVs are carried by the messages used to advertise, release, and withdraw upstream-assigned label mappings.
オプションのLDP TLV、アップストリームが割り当てられたラベルTLVが、アップストリーム割り当てのラベルを知らせるために導入されます。アップストリーム割り当てのラベルTLVは、上流で割り当てられたラベルマッピングを宣伝、リリース、撤回するために使用されるメッセージによって運ばれます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Upstrm-Ass Label (0x0204) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Label field is a 20-bit label value as specified in [RFC3032], represented as a 20-bit number in a 4-octet field as specified in Section 3.4.2.1 of RFC 5036 [RFC5036].
ラベルフィールドは、[RFC3032]で指定されている20ビットラベル値であり、RFC 5036 [RFC5036]のセクション3.4.2.1で指定されているように、4-OCTETフィールドの20ビット数として表されます。
Procedures for Label Mapping, Label Request, Label Abort, Label Withdraw, and Label Release follow [RFC5036] other than the modifications pointed out in this section.
このセクションで指摘されている変更以外に、ラベルマッピング、ラベルリクエスト、ラベルアボート、ラベルの撤回、ラベルリリース、ラベルリリースのフォロー[RFC5036]の手順。
An LDP LSR MUST NOT distribute the Upstream-Assigned Label TLV to a neighboring LSR if the neighboring LSR has not previously advertised the Upstream Label Assignment Capability in its LDP Initialization messages. An LDP LSR MUST NOT send the Upstream-Assigned Label Request TLV to a neighboring LSR if the neighboring LSR has not previously advertised the Upstream Label Assignment Capability in its LDP Initialization messages.
LDP LSRは、近隣のLSRが以前に上流のラベル割り当て機能をLDP初期化メッセージに宣伝していなかった場合、上流で割り当てられたラベルTLVを隣接するLSRに配布してはなりません。LDP LSRは、近隣のLSRが以前にLDP初期化メッセージで上流のラベル割り当て機能を宣伝していない場合、アップストリーム割り当てのラベル要求TLVを隣接するLSRに送信してはなりません。
As described in [RFC5331], the distribution of upstream-assigned labels is similar to either ordered LSP control or independent LSP control of the downstream-assigned labels.
[RFC5331]で説明されているように、上流で割り当てられたラベルの分布は、順序付けられたLSP制御またはダウンストリーム割り当てラベルの独立したLSP制御のいずれかに似ています。
When the label distributed in a Label Mapping message is an upstream-assigned label, the Upstream-Assigned Label TLV MUST be included in the Label Mapping message. When an LSR receives a Label Mapping message with an Upstream-Assigned Label TLV and it does not recognize the TLV, it MUST generate a Notification message with a status code of "Unknown TLV" [RFC5036]. If it does recognize the TLV but is unable to process the upstream label, it MUST generate a Notification message with a status code of "No Label Resources". If the Label Mapping message was generated in response to a Label Request message, the Label Request message MUST contain an Upstream-Assigned Label Request TLV. An LSR that generates an upstream-assigned label request to a neighbor LSR, for a given FEC, MUST NOT send a downstream label mapping to the neighbor LSR for that FEC unless it withdraws the upstream-assigned label binding. Similarly, if an LSR generates a downstream-assigned label request to a neighbor LSR, for a given FEC, it MUST NOT send an upstream label mapping to that LSR for that FEC, unless it aborts the downstream-assigned label request.
ラベルマッピングメッセージに配布されたラベルがアップストリーム割り当てのラベルである場合、上流のラベルTLVをラベルマッピングメッセージに含める必要があります。 LSRが上流のラベルTLVを使用してラベルマッピングメッセージを受信し、TLVを認識しない場合、「不明なTLV」[RFC5036]のステータスコードで通知メッセージを生成する必要があります。 TLVを認識しているが、アップストリームラベルを処理できない場合は、「ラベルなしリソースなし」のステータスコードで通知メッセージを生成する必要があります。ラベルマッピングメッセージがラベルリクエストメッセージに応じて生成された場合、ラベルリクエストメッセージには上流のラベルリクエストTLVを含める必要があります。特定のFECに対して、近隣LSRに上流に割り当てられたラベル要求を隣接LSRに生成するLSRは、アップストリーム割り当てのラベル結合を撤回しない限り、そのFECの近隣LSRにダウンストリームラベルマッピングを送信してはなりません。同様に、LSRが特定のFECに対して近隣LSRに対して下流に割り当てられたラベル要求をネイバーLSRに生成した場合、下流で割り当てられたラベルリクエストを中止しない限り、そのFECのLSRに上流のラベルマッピングを送信してはなりません。
The Upstream-Assigned Label TLV may be optionally included in Label Withdraw and Label Release messages that withdraw/release a particular upstream-assigned label binding.
アップストリーム割り当てのラベルTLVは、特定のアップストリーム割り当てのラベルバインディングを撤回/リリースするラベル引き出しおよびラベルのリリースメッセージにオプションに含まれる場合があります。
As described in [RFC5331], a specific upstream LSR (Ru) MAY transmit an MPLS packet, the top label of which (L) is upstream assigned, to its downstream neighbor LSR (Rd). In this case, the fact that L is upstream assigned is determined by Rd by the tunnel on which the packet is received. There must be a mechanism for Ru to inform Rd that a particular tunnel from Ru to Rd will be used by Ru for transmitting MPLS packets with upstream-assigned MPLS labels.
[RFC5331]で説明されているように、特定のアップストリームLSR（RU）がMPLSパケットを送信する場合があり、そのトップラベル（L）は上流の隣接LSR（RD）に割り当てられます。この場合、Lが上流に割り当てられているという事実は、パケットが受信されるトンネルによってRDによって決定されます。RUがRDからRDへの特定のトンネルが、上流で割り当てられたMPLSラベルを使用してMPLSパケットを送信するためにRUによって使用されることをRDに通知するメカニズムが必要です。
When LDP is used for upstream label assignment, the Interface ID TLV [RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an IP or MPLS tunnel to transmit MPLS packets with upstream assigned labels to Rd, Ru MUST include the Interface ID TLV in the Label
上流のラベル割り当てにLDPが使用される場合、インターフェイスID TLV [RFC3472]がトンネル識別子のシグナリングに使用されます。RUがIPまたはMPLSトンネルを使用して、上流の割り当てられたラベルを備えたMPLSパケットをRDに送信する場合、RUはラベルにインターフェイスID TLVを含める必要があります
Mapping messages along with the Upstream-Assigned Label TLV. The IPv4/IPv6 Next/Previous Hop Address and the Logical Interface ID fields in the Interface ID TLV SHOULD be set to 0 by the sender and ignored by the receiver. The Length field indicates the total length of the TLV, i.e., 4 + the length of the Value field in octets. A Value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four-octet aligned.
上流のラベルTLVとともにメッセージをマッピングします。IPv4/IPv6 Next/前のホップアドレスとインターフェイスID TLVの論理インターフェイスIDフィールドは、送信者によって0に設定され、受信機によって無視される必要があります。長さフィールドは、TLVの総長さ、つまり、オクテットの値フィールドの長さを示します。長さが4つの倍数ではない値フィールドは、TLVが4オクテットに並べられるように、ゼロパッドをゼロにする必要があります。
Hence the IPv4 Interface ID TLV has the following format:
したがって、IPv4インターフェイスID TLVには次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (0x082d) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 Interface ID TLV has the following format:
IPv6インターフェイスID TLVには、次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (0x082e) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Next/Previous Hop Address (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As shown in the above figures, the Interface ID TLV carries sub-TLVs. Four new Interface ID sub-TLVs are introduced to support RSVP - Traffic Engineering (RSVP-TE) P2MP LSPs, LDP P2MP LSPs, IP Multicast Tunnels, and context labels. The sub-TLV value in the sub-TLV acts as the tunnel identifier.
上記の図に示すように、インターフェイスID TLVにはサブTLVが含まれています。RSVP-トラフィックエンジニアリング（RSVP-TE）P2MP LSP、LDP P2MP LSP、IPマルチキャストトンネル、およびコンテキストラベルをサポートするために、4つの新しいインターフェイスIDサブTLVが導入されています。サブTLVのサブTLV値は、トンネル識別子として機能します。
The following sub-TLVs are introduced:
次のサブTLVが導入されています。
1. RSVP-TE P2MP LSP TLV (Type = 28)
1. RSVP-TE P2MP LSP TLV（タイプ= 28）
The value of the TLV is the RSVP-TE P2MP LSP SESSION Object [RFC4875].
TLVの値は、RSVP-TE P2MP LSPセッションオブジェクト[RFC4875]です。
Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv4 Interface ID TLV:
以下は、IPv4インターフェイスID TLVで運ばれた場合のRSVP-TE P2MP LSP TLV形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x1c) | 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv6 Interface ID TLV:
以下は、IPv6インターフェイスID TLVで運ばれた場合のRSVP-TE P2MP LSP TLV形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x1c) | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV identifies the RSVP-TE P2MP LSP. It allows Ru to tunnel an "inner" LDP P2MP LSP, the label for which is upstream assigned, over an "outer" RSVP-TE P2MP LSP that has leaves <Rd1...Rdn>. The RSVP-TE P2MP LSP IF_ID TLV allows Ru to signal to <Rd1...Rdn> the binding of the inner LDP P2MP LSP to the outer RSVP-TE P2MP LSP. The control-plane signaling between Ru and <Rd1...Rdn> for the inner P2MP LSP uses targeted LDP signaling messages.
このTLVは、RSVP-TE P2MP LSPを識別します。RUは、上流の「内側」のLDP P2MP LSPをトンネルできます。このラベルは、<rd1 ... rdn>を去る「外側」RSVP-TE P2MP LSPを介して割り当てられています。RSVP-TE P2MP LSP IF_ID TLVにより、RUは<rd1 ... rdn>内側のLDP P2MP LSPの外側RSVP-TE P2MP LSPへの結合を信号することができます。内側のP2MP LSPのRuと<rd1 ... rdn>の間のコントロールプレーンシグナル伝達は、ターゲットを絞ったLDPシグナリングメッセージを使用します。
2. LDP P2MP LSP TLV (Type = 29)
2. LDP P2MP LSP TLV（タイプ= 29）
The value of the TLV is the LDP P2MP FEC as defined in [RFC6388] and has to be set as per the procedures in [RFC6388]. Here is the format of the LDP P2MP FEC as defined in [RFC6388]:
TLVの値は、[RFC6388]で定義されているLDP P2MP FECであり、[RFC6388]の手順に従って設定する必要があります。[RFC6388]で定義されているLDP P2MP FECの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P2MP Type | Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Address Family MUST be set to IPv4, the Address Length MUST be set to 4, and the Root Node Address MUST be set to an IPv4 address when the LDP P2MP LSP TLV is carried in the IPv4 Interface ID TLV. The Address Family MUST be set to IPv6, the Address Length MUST be set to 16, and the Root Node Address MUST be set to an IPv6 address when the LDP P2MP LSP TLV is carried in the IPv6 Interface ID TLV.
アドレスファミリはIPv4に設定する必要があり、アドレスの長さは4に設定する必要があり、LDP P2MP LSP TLVがIPv4インターフェイスID TLVで運ばれる場合、ルートノードアドレスをIPv4アドレスに設定する必要があります。アドレスファミリはIPv6に設定する必要があり、アドレスの長さは16に設定する必要があり、LDP P2MP LSP TLVがIPv6インターフェイスID TLVで運ばれる場合、ルートノードアドレスをIPv6アドレスに設定する必要があります。
The TLV value identifies the LDP P2MP LSP. It allows Ru to tunnel an inner LDP P2MP LSP, the label for which is upstream assigned, over an outer LDP P2MP LSP that has leaves <Rd1...Rdn>. The LDP P2MP LSP IF_ID TLV allows Ru to signal to <Rd1...Rdn> the binding of the inner LDP P2MP LSP to the outer LDP-P2MP LSP. The control-plane signaling between Ru and <Rd1...Rdn> for the inner P2MP LSP uses targeted LDP signaling messages.
TLV値は、LDP P2MP LSPを識別します。RUは、上流のLDP P2MP LSPの内側LDP P2MP LSPをトンネルできます。LDP P2MP LSP IF_ID TLVにより、RUは<rd1 ... rdn>内側LDP P2MP LSPの外側LDP-P2MP LSPへの結合を信号することができます。内側のP2MP LSPのRuと<rd1 ... rdn>の間のコントロールプレーンシグナル伝達は、ターゲットを絞ったLDPシグナリングメッセージを使用します。
3. IP Multicast Tunnel TLV (Type = 30)
3. IPマルチキャストトンネルTLV（タイプ= 30）
In this case, the TLV value is a <Source Address, Multicast Group Address> tuple. Source Address is the IP address of the root of the tunnel (i.e., Ru), and Multicast Group Address is the Multicast Group Address used by the tunnel. The addresses MUST be IPv4 addresses when the IP Multicast Tunnel TLV is included in the IPv4 Interface ID TLV. The addresses MUST be IPv6 addresses when the IP Multicast Tunnel TLV is included in the IPv6 Interface ID TLV.
この場合、TLV値は<ソースアドレス、マルチキャストグループアドレス>タプルです。ソースアドレスは、トンネルのルート（つまりRU）のIPアドレスであり、マルチキャストグループアドレスは、トンネルで使用されるマルチキャストグループアドレスです。アドレスは、IPマルチキャストトンネルTLVがIPv4インターフェイスID TLVに含まれている場合、IPv4アドレスでなければなりません。アドレスは、IPマルチキャストトンネルTLVがIPv6インターフェイスID TLVに含まれている場合、IPv6アドレスでなければなりません。
4. MPLS Context Label TLV (Type = 31)
4. MPLSコンテキストラベルTLV（タイプ= 31）
In this case, the TLV value is a <Source Address, MPLS Context Label> tuple. The Source Address belongs to Ru and the MPLS Context Label is an upstream-assigned label, assigned by Ru. The Source Address MUST be set to an IPv4 address when the MPLS Context Label TLV is carried in the IPv4 Interface ID TLV. The Source Address MUST be set to an IPv6 address when the MPLS Context Label TLV is carried in the IPv6 Interface ID TLV. This allows Ru to tunnel an inner LDP P2MP LSP, the label of which is upstream assigned, over an outer one-hop MPLS LSP, where the outer one-hop LSP has the following property:
この場合、TLV値は<ソースアドレス、MPLSコンテキストラベル>タプルです。ソースアドレスはRUに属し、MPLSコンテキストラベルはRUによって割り当てられた上流の割り当てラベルです。MPLSコンテキストラベルTLVがIPv4インターフェイスID TLVで運ばれる場合、ソースアドレスはIPv4アドレスに設定する必要があります。MPLSコンテキストラベルTLVがIPv6インターフェイスID TLVで運ばれる場合、ソースアドレスはIPv6アドレスに設定する必要があります。これにより、RUは内側のLDP P2MP LSPをトンネルできます。そのラベルは上流で割り当てられており、外側の1ホップMPLS LSPの上にあります。
o The label pushed by Ru for the outer MPLS LSP is an upstream-assigned context label, assigned by Ru. When <Rd1...Rdn> perform an MPLS label lookup on this label, a combination of this label and the incoming interface MUST be sufficient for <Rd1...Rdn> to uniquely determine Ru's context-specific label space to look up the next label on the stack. <Rd1...Rdn> MUST receive the data sent by Ru with the context-specific label assigned by Ru being the top label on the label stack.
o 外側のMPLS LSPのRUによってプッシュされたラベルは、RUによって割り当てられた上流で割り当てられたコンテキストラベルです。<rd1 ... rdn>このラベルでMPLSラベルルックアップを実行する場合、このラベルと着信インターフェイスの組み合わせが<rd1 ... rdn>に十分でなければなりません。スタックの次のラベル。<rd1 ... rdn> ruが送信したデータを、RUによって割り当てられたコンテキスト固有のラベルがラベルスタックのトップラベルに割り当てられている必要があります。
Currently, the usage of the Context Label TLV is limited only to LDP P2MP LSPs on a LAN as specified in the next section. The Context Label TLV MUST NOT be used for any other purpose.
現在、コンテキストラベルTLVの使用は、次のセクションで指定されているLAN上のLDP P2MP LSPにのみ制限されています。コンテキストラベルTLVは、他の目的に使用してはなりません。
Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP, the above procedures assume that Ru has a priori knowledge of all the <Rd1, ... Rdn>. In the scenario where the outer P2MP LSP is signaled using RSVP-TE, Ru can obtain this information from RSVP-TE. However, in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP does not provide this information to Ru. In this scenario, the procedures by which Ru could acquire this information are outside the scope of this document.
外側のP2MP LSPがRSVP-TEまたはMLDPでシグナルにされている場合、上記の手順では、RUがすべての<RD1、... RDN>の先験的な知識があると仮定することに注意してください。外側のP2MP LSPがRSVP-TEを使用してシグナル伝達されるシナリオでは、RUはRSVP-TEからこの情報を取得できます。ただし、外側のP2MP LSPがMLDPを使用してシグナル伝達されるシナリオでは、MLDPはこの情報をRUに提供しません。このシナリオでは、RUがこの情報を取得できる手順は、このドキュメントの範囲外にあります。
This section describes one application of upstream label assignment using LDP. Further applications are to be described in separate documents.
このセクションでは、LDPを使用した上流のラベル割り当ての1つのアプリケーションについて説明します。さらなるアプリケーションは、個別のドキュメントで説明されます。
[RFC6388] describes how to setup P2MP LSPs using LDP. On a LAN the solution relies on "ingress replication". An LSR on a LAN, that is a branch LSR for a P2MP LSP (say Ru), sends a separate copy of a packet that it receives on the P2MP LSP to each of the downstream LSRs on the LAN (say <Rd1...Rdn>) that are adjacent to it in the P2MP LSP.
[RFC6388]は、LDPを使用してP2MP LSPをセットアップする方法について説明します。LANでは、ソリューションは「レプリケーションのイングレス」に依存しています。LAN上のLSR、つまりP2MP LSP（たとえばRu）のブランチLSRであるLSRは、P2MP LSPで受信するパケットの個別のコピーをLANの下流LSRのそれぞれに送信します（たとえば<RD1 ...rdn>）は、p2mp lspで隣接しています。
It is desirable for Ru to send a single copy of the packet for the LDP P2MP LSP on the LAN, when there are multiple downstream routers
RUがLAN上のLDP P2MP LSPのパケットのコピーを1つのコピーで送信することが望ましいです。
on the LAN that are adjacent to Ru in that LDP P2MP LSP. This requires that each of <Rd1...Rdn> must be able to associate the label L, used by Ru to transmit packets for the P2MP LSP on the LAN, with that P2MP LSP. It is possible to achieve this using LDP upstream-assigned labels with the following procedures.
そのLDP P2MP LSPのRUに隣接するLANで。これには、<rd1 ... rdn>のそれぞれが、ruが使用するラベルLを関連付けて、LAN上のP2MP LSPのパケットをそのP2MP LSPで送信できる必要があります。次の手順を使用して、LDPアップストリーム割り当てラベルを使用してこれを達成することができます。
Consider an LSR Rd that receives the LDP P2MP FEC [RFC6388] from its downstream LDP peer. Additionally, consider that the upstream interface to reach LSR Ru that is the next hop to the P2MP LSP root address (Pr) in the LDP P2MP FEC is a LAN interface (Li) and that Rd and Ru support upstream-assigned labels. In this case, instead of sending a Label Mapping message as described in [RFC6388], Rd sends a Label Request message to Ru. This Label Request message MUST contain an Upstream-Assigned Label Request TLV.
下流のLDPピアからLDP P2MP FEC [RFC6388]を受け取るLSR RDを考えてみましょう。さらに、LDP P2MP FECのP2MP LSPルートアドレス（PR）への次のホップであるLSR RUに到達する上流インターフェイスは、LANインターフェイス（LI）であり、RDとRUがアップストリーム割り当てラベルをサポートしていることを考えてください。この場合、[RFC6388]で説明されているようにラベルマッピングメッセージを送信する代わりに、RDはRUにラベル要求メッセージを送信します。このラベルリクエストメッセージには、上流に割り当てられたラベルリクエストTLVが含まれている必要があります。
On receiving this message, Ru sends back a Label Mapping message to Rd with an upstream-assigned label. This message also contains an Interface ID TLV with an MPLS Context Label sub-TLV, as described in the previous section, with the value of the MPLS label set to a value assigned by Ru on interface Li as specified in [RFC5331]. Processing of the Label Request and Label Mapping messages for LDP upstream-assigned labels is as described in Section 4.1. If Ru receives a Label Request for an upstream-assigned label for the same P2MP FEC from multiple downstream LSRs on the LAN, <Rd1...Rdn>, it MUST send the same upstream-assigned label to each of <Rd1...Rdn>.
このメッセージを受信すると、Ruは上流のラベルを使用してRDにラベルマッピングメッセージを送り返します。このメッセージには、前のセクションで説明されているように、MPLSコンテキストラベルSub-TLVを備えたインターフェイスID TLVも含まれています。MPLSラベルの値は、[RFC5331]で指定されているInterface LIのRUによって割り当てられた値に設定されています。LDPアップストリーム割り当てラベルのラベル要求とラベルマッピングメッセージの処理は、セクション4.1で説明されています。ruがLAN上の複数の下流LSRから同じP2MP FECの上流割り当てラベルのラベル要求を受信した場合、<rd1 ... rdn>、同じアップストリーム割り当てラベルを各<rd1に送信する必要があります...rdn>。
Ru transmits the MPLS packet using the procedures defined in [RFC5331] and [RFC5332]. The MPLS packet transmitted by Ru contains as the top label the context label assigned by Ru on the LAN interface, Li. The bottom label is the upstream label assigned by Ru to the LDP P2MP LSP. The top label is looked up in the context of the LAN interface (Li) by a downstream LSR on the LAN. This lookup enables the downstream LSR to determine the context-specific label space in which to look up the inner label.
RUは、[RFC5331]および[RFC5332]で定義された手順を使用して、MPLSパケットを送信します。RUによって送信されたMPLSパケットには、LANインターフェイスであるRUによって割り当てられたコンテキストラベル、Liが含まれています。下のラベルは、RUによってLDP P2MP LSPに割り当てられた上流のラベルです。トップラベルは、LAN上の下流LSRによってLANインターフェイス（LI）のコンテキストで見上げられます。このルックアップにより、下流のLSRは、内側のラベルを検索するコンテキスト固有のラベル空間を決定できます。
Note that <Rd1...Rdn> may have more than one equal-cost next hop on the LAN to reach Pr. It MAY be desirable for all of them to send the label request to the same upstream LSR and they MAY select one upstream LSR using the following procedure:
<rd1 ... rdn>は、LANに次の複数の等しいコストがPRに到達するために複数の等しいコストを持っている可能性があることに注意してください。すべての人が同じ上流のLSRにラベル要求を送信することが望ましい場合があり、次の手順を使用して1つのアップストリームLSRを選択できます。
1. The candidate upstream LSRs are numbered from lower to higher IP address.
1. 候補の上流のLSRは、低いIPアドレスから上位のIPアドレスから番号が付けられています。
2. The following hash is performed: H = (Sum Opaque value) modulo N, where N is the number of candidate upstream LSRs. The Opaque value is defined in [RFC6388] and comprises the P2MP LSP identifier.
2. 次のハッシュが実行されます：h =（sum opaque value）modulo n。ここで、nは候補の上流LSRの数です。不透明な値は[RFC6388]で定義され、P2MP LSP識別子を含む。
3. The selected upstream LSR U is the LSR that has the number H.
3. 選択されたアップストリームLSR uは、数hを持つLSRです。
This allows for load balancing of a set of LSPs among a set of candidate upstream LSRs, while ensuring that on a LAN interface, a single upstream LSR is selected. It is also to be noted that the procedures in this section can still be used by Rd and Ru if other LSRs on the LAN do not support upstream label assignment. Ingress replication and downstream label assignment will continue to be used for LSRs that do not support upstream label assignment.
これにより、候補の上流LSRのセット間のLSPのセットの負荷分散が可能になり、LANインターフェイスで単一の上流LSRが選択されるようにします。また、LAN上の他のLSRが上流のラベルの割り当てをサポートしていない場合、このセクションの手順はRDとRUがまだ使用できることにも注意してください。Ingress Replicationと下流のラベル割り当ては、上流のラベル割り当てをサポートしていないLSRに引き続き使用されます。
IANA maintains a registry of LDP TLVs at the registry "Label Distribution Protocol" in the sub-registry called "TLV Type Name Space".
IANAは、「TLVタイプ名スペース」と呼ばれるサブレジストリのレジストリ「ラベル分布プロトコル」でLDP TLVのレジストリを維持しています。
This document defines a new LDP Upstream Label Assignment Capability TLV (Section 3). IANA has assigned the value 0x0507 to this TLV.
このドキュメントでは、新しいLDPアップストリームラベル割り当て機能TLV（セクション3）を定義します。IANAはこのTLVに値0x0507を割り当てました。
This document defines a new LDP Upstream-Assigned Label TLV (Section 4). IANA has assigned the type value of 0x204 to this TLV.
このドキュメントでは、新しいLDPアップストリーム割り当てラベルTLV（セクション4）を定義します。IANAは、このTLVに0x204のタイプ値を割り当てました。
This document defines a new LDP Upstream-Assigned Label Request TLV (Section 4). IANA has assigned the type value of 0x205 to this TLV.
このドキュメントでは、新しいLDPアップストリーム割り当てラベルリクエストTLV（セクション4）を定義します。IANAは、このTLVに0x205のタイプ値を割り当てました。
[RFC3472] defines the LDP Interface ID IPv4 and IPv6 TLV. These top-level TLVs can carry sub-TLVs dependent on the interface type. These sub-TLVs are assigned "Interface ID Types". IANA maintains a registry of Interface ID Types for use in GMPLS in the registry "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" and sub-registry "Interface_ID Types". IANA has made the corresponding allocations from this registry as follows:
[RFC3472]は、LDPインターフェイスID IPv4およびIPv6 TLVを定義します。これらのトップレベルのTLVは、インターフェイスタイプに応じてサブTLVを運ぶことができます。これらのサブTLVには、「インターフェイスIDタイプ」が割り当てられます。IANAは、レジストリ「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングパラメーター」およびサブレジストリ「インターフェイス_IDタイプ」でGMPLSで使用するインターフェイスIDタイプのレジストリを維持しています。IANAは、次のようにこのレジストリから対応する割り当てを行いました。
- RSVP-TE P2MP LSP TLV (value 28)
- RSVP-TE P2MP LSP TLV（値28）
- LDP P2MP LSP TLV (value 29)
- LDP P2MP LSP TLV（値29）
- IP Multicast Tunnel TLV (value 30)
- IPマルチキャストトンネルTLV（値30）
- MPLS Context Label TLV (value 31)
- MPLSコンテキストラベルTLV（値31）
The security considerations discussed in [RFC5036], [RFC5331], and [RFC5332] apply to this document.
[RFC5036]、[RFC5331]、および[RFC5332]で説明されているセキュリティ上の考慮事項は、このドキュメントに適用されます。
More detailed discussion of security issues that are relevant in the context of MPLS and GMPLS, including security threats, related defensive techniques, and the mechanisms for detection and reporting, are discussed in "Security Framework for MPLS and GMPLS Networks" [RFC5920].
セキュリティの脅威、関連する防御技術、検出および報告のメカニズムなど、MPLSおよびGMPLSのコンテキストで関連するセキュリティ問題のより詳細な議論は、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」[RFC5920]で説明されています。
Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and Thomas Morin for their comments. The hashing algorithm used on LAN interfaces is taken from [RFC6388]. Thanks to Loa Andersson, Adrian Farrel, and Eric Rosen for their comments and review.
Yakov Rekhterの貢献に感謝します。イナ・ミネイとトーマス・モリンのコメントに感謝します。LANインターフェイスで使用されるハッシュアルゴリズムは[RFC6388]から取得されます。ロア・アンダーソン、エイドリアン・ファレル、エリック・ローゼンのコメントとレビューに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「LDP仕様」、RFC 5036、2007年10月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875] Aggarwal、R.、ed。、ed。、Papadimitriou、D.、ed。、およびS. Yasukawa、ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルの交通工学（RSVP-TE）スイッチPaths（LSP） "、RFC 4875、2007年5月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLS Upstream Labelの割り当てとコンテキスト固有のラベルスペース」、RFC 5331、2008年8月。
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332] Eckert、T.、Rosen、E.、Ed。、Aggarwal、R.、Y.Rekhter、「MPLS Multicast Capsulations」、RFC 5332、2008年8月。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5561] Thomas、B.、Raza、K.、Aggarwal、S.、Aggarwal、R。、およびJl。Le Roux、「LDP機能」、RFC 5561、2009年7月。
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011.
[RFC6388] Wijnands、IJ。、ed。、Misei、I.、ed。、Kompella、K。、およびB. Thomas、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチされたパスのラベル分布プロトコル拡張」、RFC 6388、2011年11月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
[RFC3472] Ashwood-Smith, P., Ed., and L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
[RFC3472] Ashwood-Smith、P.、ed。、およびL. Berger、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング制約ベースのルーティングラベル分布プロトコル（CR-LDP）拡張機能」、RFC 3472、2003年1月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
Author's Address
著者の連絡先
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Phone: +1-408-936-2720 EMail: raggarwa_1@yahoo.com
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089電話：1-408-936-2720メール：raggarwa_1@yahoo.com
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Louis Le Roux France Telecom 2、Avenue Pierre-Marzin 22307 Lannion Cedex Franceメール：jeanlouis.leroux@orange-ftgroup.com