GMPLS Signaling Procedures for Egress Control
イグレスコントロールに向けた GMPLS シグナリング手順
Status of This Memo(http://srgia.com/docs/rfc4291j.html より引用)
この文書はインターネットコミュニティのためのインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案とを求めている。この プロトコルの標準化の状態と状況に付いては "Internet
Official Protocol Standards"(STD 1) を参照してほしい。この文書の配布に制限はない。
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract:
本書類はイグレスノードの出力ダウンストリームインタフェースで，Label Switched Path（LSP）が使うラベルを制御するための手順を明らかにする。この制御は「イグレスコントロール」と呼ばれる。
イグレスコントロールのサポートは GMPLS のシグナリングにおいて暗に定められている。この書類はその GMPLS シグナリングの仕様を明らかにするだけであり，シグナリングメカニズムや手順を変えない。
1. Background
イグレスノードの出力ダウンストリームインタフェースで使うラベルを制御する機能は，早期から GMPLS へと要求されていた。早期の GMPLSに関する書類では、これは「イグレスコントロール」と呼ばれた。
GMPLS の書類が更新されるたび、イグレスインタフェースのラベルを制御する機能は一般化され，いかなるインタフェースのラベルでも制御されるようにサポートされた。この一般化は[RFC3471]の section6 および[RFC3473]の section5.1 に見られる。これらは一般化される際に、イグレスノードでラベル制御をサポートする手順も一般化した。その結果はイグレスコントロールを明らかにする目的だったにもかかわらず、目的がはっきりと分からなくなっている。そのため，本書類はイグレスノードの出力・ダウンストリームインタフェースで使うラベルの制御を明らかにする手順を繰り返し明らかにする。
補足のため、以下に 2000 年 6 月のイグレスコントロールのための ERO（Explicit Route Object）についての GMPLS シグナリング書類を参照する。

6. Egress Control
LSP の先頭にある LSR は，LSP の終点を ERO で制御できる。
あるイグレス LSR の出力インタフェースを，特定の LSP の終点とするために、先頭の LSR はそのインタフェースの IP アドレスを ERO の最後の要素として指定することができる。これはもちろん、そのインタフェースに付属した IP アドレスがあればの話だが。
IP アドレスの使用は，イグレスの終点を特別に指定するためには不十分な場合がある。その一つは，イグレス LSR の出力インタフェースが，リンクバンドルのコンポーネントリンクだという場合である。そしてまた別の場合として，二つの LSP を「splice」したい場合である。つまり、第一の LSP の tailを第二の LSP の head に接続する場合だ。後者の場合は nonPSC リンク分類に起るだろう。
6.2 Procedures
Egress Label という subobject は ERO/ER の最後のsubobject として出力されなければならない。
この subobject が ERO/ER の別の場所に出現する場合は「Bad strict node」エラーとして処理される。
LSP を確立する際、ERO/RR を処理しているノードが Next
Hop を選択し，第二 subobject が Egress Label
Subobject だと気づく場合、この subobject の情報に基づいて，その LSP から受け取ったデータの処理を決定する。もっと具体的にいうと、subobject の Link ID 値がゼロでない場合、この値が，LSP で受け取ったデータを送信するべき出力リンクを指定している。Subobject の Label 値が「Implicit NULL label」ではない場合、この値が LSP で受け取ったデータの使うべき出力ラベルを指定している。
LSP の先頭にある LSR が Egress Label subobject を作るための情報を得る手順はこの書類の範囲ではない。
2. Egress Control Procedures
本 section は[RFC3473]の 5.1.1 と 5.2.1 を補足することを目的とする。その sections で記述された手順は変わっていない。本section はイグレスノードの出力・ダウンストリームインタフェースで使うラベルについての手順を明らかにする section だ。
本書類に出るキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は[RFC2119]で記述された通り分かるべきだ。
2.1 ERO Procedures
ある ERO を処理しているノードがイグレスで、その ERO が出力・ダウンストリームインタフェースと関係ある subobject を一つ以上含む場合、イグレスコントロールが起きる。この場合では、出力・ダウンストリームインタフェースは，ERO のリストの最後の local インタフェースとして示される。インタフェースは番号がある場合もない場合もあるため、注意しなければならない。
イグレスコントロールをサポートするために、イグレスは受け取ったERO に出力・ダウンストリームインタフェースが含まれるかどうかをチェックする。

もし含まれていた場合、インタフェース後の subobject のタイプが調べられる。関係された LSP が片方向であれば、一つの subobject が調べられる。双方向であれば、二つの subobject が調べられる。調べられた
subobject の U-bit が clear(0)ならば、ラベルの値は示された出力・ダウンストリームインタフェースで LSP と関連したトラフィックに使わなければならない(MUST)。
調べられているsubobjectのU-bitがset(1)ならば、ラベルの値は双方向LSPと関連したupstreamトラフィックに使われている。特に、ラベルの値は示された出力・ダウンストリームインタフェースで受け取るLSPと関連したトラフィックに使われる。
[RFC3473]によると、EROの処理をしている際に、ラベルのリストを受け入れることができなかった場合，もしくはフォアーディングにサポートできない場合，エラーが発生し，PathErrメッセージが生成されるべき(SHOULD)だ。そのメッセージのerror codeは「Routing Error」であり，error valueは「Bad Explicit Route Object」である。

2.2 RRO Procedures
Label recordingがLSPには指定されており、またEROの一つがイグレスの出力インタフェースの情報を指すために使われている場合、イグレスは該当するRRO（Route Record Object）へと，示されたインタフェース情報や示されたラベルを含むべきだ。
3. Security Considerations
本書類は[RFC3473]で定義された手順を明らかにする(clarify)が、新たな手順は定義しない。そのため、セキュリティに関する新たな検討は導入しない。
4. Acknowledgements
有益なコメントや情報提供はAdrian FarrelとAlan KullbergとDimitri Papadimitriouから受け取った。
5. Normative References[RFC2119] Bradner, S., "Key words for use in RFCs toIndicate Requirement Levels", BCP 14, RFC 2119, March
1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol
Label Switching(GMPLS) Signaling Functional
Description", RFC 3471, January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol
Label Switching(GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
Author’s Address
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com

Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses andrestrictions contained in BCP 78, and except as set
forth therein, the authors retain all their rights.
This document and the information contained herein areprovided on an "AS IS" basis and THE CONTRIBUTOR, THEORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IFANY), THE INTERNET SOCIETY AND THE INTERNETENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANYWARRANTY THAT THE USE OF THE INFORMATION HEREIN WILLNOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or
scope of any Intellectual Property Rights or otherrights that might be claimed to pertain to theimplementation or use of the technology described inthis document or the extent to which any license undersuch rights might or might not be available; nor does
it represent that it has made any independent effort
to identify any such rights. Information on the IETF’s
procedures with respect to rights in IETF Documents
can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat
and any assurances of licenses to be made available,or the result of an attempt made to obtain a generallicense or permission for the use of such proprietary
rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patentapplications, or other proprietary rights that may
cover technology that may be required to implement
this standard. Please address the information to theIETF at ietf-ipr@ietf.org.

Acknowledgement
RFC Editor の活動への資金は Internet Society によって提供されている。