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
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
このドキュメントでは、ラベルスイッチングルータ（LSR）はLSRがその隣接LSRの上流ラベル割り当てをサポートしているかどうかを宣伝するために使用できることをLDPの拡張機能について説明します。
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.
LAN LDPのためのポイント・ツー・マルチポイント（P2MP）ラベルのブランチLSRトラフィックの複製を避けるために、LDPを使用してMPLS上流ラベル割り当ての使用量がスイッチパス（LSP）[RFC6388]も記載されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
下流のLSRがそれらをサポートしていることが知られていない限り、[RFC5331]によると、上流割り当てられたラベルバインディングを使用してはいけません。これは、LDPネイバーLSR（S）上流割り当てられたラベルのその支持体にアドバタイズする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].
RFC 5036のセクション3.4.2.1 [RFC5036]で指定されるように[RFC3032]で指定されるようにラベルフィールドが20ビットのラベル値である、4オクテットフィールドに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.
隣接LSRが以前にそのLDP初期化メッセージの上流ラベル割り当て能力を広告していない場合、LDP LSRは、隣接LSRに上流割り当てられたラベルTLVを配布してはなりません。隣接LSRが以前にそのLDP初期化メッセージの上流ラベル割り当て能力を広告していない場合、LDP LSRは、隣接LSRに上流割り当てられたラベル要求TLVを送ってはいけません。
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.
Label Mappingメッセージに分布ラベルが上流割り当てられたラベルである場合、上流割り当てられたラベルTLVはLabel Mappingメッセージに含まれなければなりません。 LSRは上流割り当てられたラベルTLVとLabel Mappingメッセージを受信し、TLVを認識しない場合、それは「不明TLV」[RFC5036]のステータスコードと、通知メッセージを生成しなければなりません。それはTLVを認識しませんが、上流のラベルを処理することができない場合は、「いいえラベルリソース」のステータスコードを持つ通知メッセージを発生させなければなりません。ラベルマッピングメッセージをラベル要求メッセージに応答して生成された場合は、ラベル要求メッセージは、上流割り当てられたラベル要求TLVを含まなければなりません。それが結合上流割り当てられたラベルを撤回しない限り、隣接LSRに上流割り当てられたラベル要求を生成するLSRは、与えられたFECのために、そのFECのための隣接LSRの下流ラベルマッピングを送信してはいけません。 LSRは、隣接LSRの下流に割り当てられたラベル要求を生成する場合、それは下流割り当てられたラベル要求を中止しない限り、同様に、与えられたFECのために、それは、その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によって決定されます。 RDにruから特定のトンネルが上流割り当てられたMPLSラベルを用いてMPLSパケットを送信するためのRuによって使用されること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がRDに上流の割り当てられたラベルでMPLSパケットを伝送するIPまたはMPLSトンネルを使用する場合、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の次/前のホップアドレスとインターフェイスID TLVで、論理インターフェイスのIDフィールドは、送信者によって0に設定され、受信機によって無視されるべきです。 Lengthフィールドは、4 +、即ち、オクテットで値フィールドの長さをTLVの長さの合計を示しています。 TLVは4オクテット整列されるように、その長さが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を運びます。四つの新しいインタフェースIDサブTLVのは、RSVPをサポートするために導入されている - トラフィックエンジニアリング（RSVP-TE）P2MP LSPを、LDP P2MP LSPを、IPマルチキャストトンネル、およびコンテキストラベル。サブTLVにおけるサブTLV値がトンネル識別子として働きます。
The following sub-TLVs are introduced:
以下のサブのTLVが導入されています。
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を識別します。これは、「内側」LDP P2MP LSP、上流の「外側」RSVP-TE P2MP LSP葉<Rd1を... Rdnの>を持っている上に、割り当てられているラベルトンネルにルテニウムを可能にします。 RSVP-TE P2MP LSP IF_ID TLVは、Ruが<Rd1を...のRdn>アウターRSVP-TE P2MP LSPに内側LDP P2MP LSPの結合に知らせることを可能にします。内側P2MP LSPのためにRu及び<Rd1を...のRdn>との間の制御プレーンシグナリングは、LDPシグナリングメッセージをターゲット使用します。
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を識別する。これは、内側LDP P2MP LSP、葉<Rd1を... Rdnの>を有する外側LDP P2MP LSP上上流割り当てられているラベル、トンネルにルテニウムを可能にします。 LDP P2MP LSP IF_ID TLVは、Ruが<Rd1を...のRdn>アウターLDP-P2MP LSPに内側LDP P2MP LSPの結合に知らせることを可能にします。内側P2MP LSPのためにRu及び<Rd1を...のRdn>との間の制御プレーンシグナリングは、LDPシグナリングメッセージをターゲット使用します。
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アドレスでなければなりません。
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、上流の外側のホップLSPは、以下の性質を有する外側のホップ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ラベル検索を実行すると、このラベルや着信インターフェイスの組み合わせは一意にルックアップするためのRuのコンテキスト固有のラベルスペースを決定するために、<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は、それは、ルテニウム（Ruを言う）、それはLAN上の下流のLSR（たとえば<Rd1をそれぞれにP2MP LSP上で受信パケットの別々のコピーを送信P2MP LSPのための分岐LSRです... P2MP LSPでそれに隣接しているRDN>）。
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 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上の複数のダウンストリームルータが存在するときRuは、LAN上のLDP P2MP LSPのためのパケットの単一のコピーを送信することが望ましいです。これは、各の<Rd1を...のRdn>はそのP2MP LSPと、LAN上のP2MP LSPのためのパケットを送信するためにルテニウムが使用するラベルLを、関連付けることができなければならないことを要求しています。次の手順を使用してこの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）の次ホップであるLANインターフェースリチウム（Li）であり、RdとRuをサポートラベルを上流割り当てたLSRのRuに到達することを考えます。この場合には、代わりに[RFC6388]に記載されているようにLabel Mappingメッセージを送信する、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にLabel Mappingメッセージを返送します。 [RFC5331]で指定されるように界面のLi上のRuによって割り当てられた値に設定するMPLSラベルの値と、前のセクションで説明したように、このメッセージはまた、MPLSコンテキストラベルサブTLVとのインタフェースID TLVを含んでいます。 4.1節で説明したようにLDP上流に割り当てられたラベルのラベル要求とラベルマッピングメッセージの処理があります。 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パケットを送信します。ルテニウムが送信したMPLSパケットのトップラベルとしてLANインタフェース、李上のRuによって割り当てられたコンテキストラベルが含まれています。底ラベルはLDP P2MP LSPへのRuによって割り当てられた上流のラベルです。トップラベルは、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が>のPrに到達するために、LAN上の複数の等価コストネクストホップを持っている場合があります。それらのすべてが同じ上流のLSRにラベル要求を送信することが望ましいであろうと、彼らは、次の手順を使用して1つのアップストリームLSRを選択することがあります。
1. The candidate upstream LSRs are numbered from lower to higher IP address.
1.候補上流のLSRは、より高い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.次のハッシュが実行される：N候補上流のLSRの数であり、H =（合計不透明値）モジュロN、。不透明値は[RFC6388]で定義されており、P2MP LSPの識別子を備えています。
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.
LANインタフェースに、単一のアップストリームLSRが選択されていることを保証しながらこれは、候補上流のLSRのセットの中のLSPのセットのロードバランシングを可能にします。また、LAN上の他のLSRが上流のラベルの割り当てをサポートしていない場合は、このセクションの手順は、まだRdとのRuで使用することができることに留意すべきです。イングレス複製および下流ラベル割り当ては、上流のラベルの割り当てをサポートしていない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タイプ名前空間」と呼ばれるサブレジストリでレジストリ「ラベル配布プロトコル」で、自民党の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は、「タイプInterface_ID」レジストリ内のGMPLSで使用する「一般化マルチプロトコルラベルスイッチング（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.
彼の貢献のためのヤコフ・レックターに感謝します。彼らのコメントのための伊那Mineiとトーマス・モリンに感謝します。 LANインターフェイスで使用されるハッシュアルゴリズムは[RFC6388]から取られます。彼らのコメントやレビューのためのLoaアンデション、エードリアンファレル、そしてエリック・ローゼンに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "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]アガルワルは、R.、エド、Papadimitriou、D.、エド、およびS.安川、エド、「リソース予約プロトコルへの拡張 - 。。。は、ポイント・ツー・マルチポイントTEラベルのためのトラフィックエンジニアリング（RSVP-TE）は、スイッチパス（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]アガルワル、R.、Rekhter、Y.、およびE.ローゼン、 "MPLS上流ラベルの割り当てとコンテキスト固有のラベルスペース"、RFC 5331、2008年8月。
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332]エッカート、T.、ローゼン、E.、編、アガルワル、R.、およびY. Rekhter、 "MPLSマルチキャストカプセル化"、RFC 5332、2008年8月。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5561]トーマス、B.、ラザ、K.、アガルワル、S.、アガルワル、R.、およびJL。ル・ルー、 "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。、エド。、Minei、I.、エド。、Kompella、K.、およびB.トーマス、「ポイントツーマルチポイントのラベル配布プロトコルの拡張機能と多対多ラベルは、パスの交換しました」 、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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、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]アッシュウッド・スミス、P.、エド。、およびL.バーガー、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング制約ベースルーティングのラベル配布プロトコル（CR-LDP）の拡張"、RFC 3472、 2003年1月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]牙、L.、エド。、 "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
ラウール・アガーウォールジュニパーネットワークスの1194北マチルダアベニュー。サニーベール、CA 94089電話：+ 1-408-936-2720 Eメール：raggarwa_1@yahoo.com
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: jeanlouis.leroux@orange-ftgroup.com
ジャン=ルイ・ルーフランステレコム2、大通りピエールMarzin 22307ラニオンCedexのフランス電子メール：jeanlouis.leroux@orange-ftgroup.com