RFC2209 日本語訳
2209 Resource ReSerVation Protocol (RSVP) -- Version 1 MessageProcessing Rules. R. Braden, L. Zhang. September 1997. (Format: TXT=51690 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Braden
Request For Comments: 2209 ISI
Category: Informational L. Zhang
UCLA
September 1997
コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 2209年のISIカテゴリ: 情報のL.チャンUCLA1997年9月
Resource ReSerVation Protocol (RSVP) --
Version 1 Message Processing Rules
資源予約プロトコル(RSVP)--バージョン1メッセージ処理規則
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo contains an algorithmic description of the rules used by an RSVP implementation for processing messages. It is intended to clarify the version 1 RSVP protocol specification.
このメモは処理メッセージのためのRSVP実現で使用される規則のアルゴリズムの記述を含んでいます。 バージョン1RSVPプロトコル仕様をはっきりさせるのは意図しています。
This memo provides a generic description of the rules for the operation of Version 1 of RSVP [RFC 2205]. It is intended to outline a set of algorithms that will accomplish the needed function, omitting many details.
このメモはRSVP[RFC2205]のバージョン1の操作のための規則の一般的な記述を提供します。 多くの詳細を省略して、必要な機能を達成する1セットのアルゴリズムを概説するのは意図しています。
1. GENERIC DATA STRUCTURES
1. 一般的なデータ構造
This memo assumes the generic interface calls defined in [RFC 2005] and the following data structures. An actual implementation may use additional or different data structures and interfaces. The data structure fields that are shown are required unless they are explicitly labelled as optional.
このメモは、ジェネリックが[RFC2005]で定義されたインタフェース呼び出しと以下のデータ構造であると仮定します。 実際の実現は追加しているか異なったデータ構造とインタフェースを使用するかもしれません。 それらが任意であるとして明らかにラベルされない場合、示されるデータ構造分野が必要です。
o PSB -- Path State Block
o PSB--経路州のブロック
Each PSB holds path state for a particular (session, sender)
pair, defined by SESSION and SENDER_TEMPLATE objects,
respectively, received in a PATH message.
各PSBはそれぞれSESSIONとSENDER_TEMPLATE物によって定義された(セッション、送付者)特定の組経路州を保持します、PATHメッセージでは、受け取られています。
Braden & Zhang Informational [Page 1] RFC 2209 RSVP-Message Processing September 1997
[1ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
PSB contents include the following values from a PATH message:
PSB内容はPATHメッセージから以下の値を含んでいます:
- Session
- セッション
- Sender_Template
- 送付者_テンプレート
- Sender_Tspec
- 送付者_Tspec
- The previous hop IP address and the Logical Interface
Handle (LIH) from a PHOP object
- 前のホップIPアドレスとPHOP物からのLogical Interface Handle(LIH)
- The remaining IP TTL
- 残っているIP TTL
- POLICY_DATA and/or ADSPEC objects (optional)
- POLICY_DATA、そして/または、ADSPEC物(任意)です。
- Non_RSVP flag
- 非_のRSVP旗
- E_Police flag
- E_警察の旗
- Local_Only flag
- ローカルの_Only旗
In addition, the PSB contains the following information provided
by routing: OutInterface_list, which is the list of outgoing
interfaces for this (sender, destination), and IncInterface,
which is the expected incoming interface. For a unicast
destination, OutInterface_list contains one entry and
IncInterface is undefined.
さらに、PSBはルーティングで提供された以下の情報を含んでいます: (それは、これ(送付者、目的地)のための外向的なインタフェースのリストです)。OutInterface_リスト、およびIncInterface。(IncInterfaceは予想された入って来るインタフェースです)。 ユニキャストの目的地に関しては、OutInterface_リストは1つのエントリーを含んでいます、そして、IncInterfaceは未定義です。
Note that there may be more than one PSB for the same (session,
sender) pair but different incoming interfaces. At most one of
these, which will have the Local_Only flag off, will be the PSB
used for forwarding PATH messages downstream; we will refer to
it as the "forwarding PSB" in the following. The other PSB's
will have the Local_Only flag on and an empty
OutInterface_list.h The Local_Only flag is needed to correctly
match PSB's against RSB's, by the rules of [RFC 2205].
同じ(セッション、送付者)組にもかかわらず、異なった入って来るインタフェースへの1PSBがあるかもしれないことに注意してください。 高々Local_Only旗を休みにするこれらの1つは川下でメッセージをPATHに転送するのに使用されるPSBになるでしょう。 私たちは以下の「推進PSB」とそれを呼ぶつもりです。 PSBのもう片方のものはLocal_Only旗をオンに持つでしょう、そして、Local_Onlyが旗を揚げさせる空のOutInterface_list.hが正しくRSBのものに対してPSBのものを合わせるのに必要です、[RFC2205]の規則で。
o RSB -- Reservation State Block
o RSB--予約州のブロック
Each RSB holds a reservation request that arrived in a
particular RESV message, corresponding to the triple: (session,
next hop, Filter_spec_list). Here "Filter_spec_list" may be a
list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF
style), or empty (WF style). We define the virtual object type
"FILTER_SPEC*" for such a data structure.
各RSBは三重に対応している、特定のRESVメッセージに到着した予約の要請を保持します: (セッション、次のホップ、Filter_仕様_リスト。) ここで、「フィルタ_仕様_リスト」は、FILTER_SPECsのリスト(SEスタイルのための)、独身のFILTER_SPEC(FFスタイル)であるか(WFスタイル)を空にするかもしれません。 私たちはそのようなデータ構造のための仮想のオブジェクト・タイプ「フィルタ_仕様*」を定義します。
Braden & Zhang Informational [Page 2] RFC 2209 RSVP-Message Processing September 1997
[2ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
RSB contents include:
RSBコンテンツは:
- Session specification
- セッション仕様
- Next hop IP address
- 次のホップIPアドレス
- Filter_spec_list
- フィルタ_仕様_リスト
- The outgoing (logical) interface OI on which the
reservation is to be made or has been made.
- 予約が作られているためにあるか、またはされた出発している(論理的な)インタフェースOI。
- Style
- 様式
- Flowspec
- Flowspec
- A SCOPE object (optional, depending upon style)
- SCOPE物(任意である、スタイルに依存します)
- RESV_CONFIRM object that was received (optional)
- 受け取られたRESV_CONFIRM物(任意)です。
o TCSB -- Traffic Control State Block
o TCSB--トラフィックコントロール州のブロック
Each TCSB holds the reservation specification that has been
handed to traffic control for a specific outgoing interface. In
general, TCSB information is derived from RSB's for the same
outgoing interface. Each TCSB defines a single reservation for
a particular triple: (session, OI, Filter_spec_list). TCSB
contents include:
各TCSBは特定の外向的なインタフェースのためにトラフィックコントロールに手渡された予約仕様を保持します。 一般に、RSBのものからTCSB情報を同じ外向的なインタフェースに得ます。 各TCSBは特定の三重のただ一つの予約を定義します: (セッション、OIは_仕様_リストをフィルターにかけます。) TCSBコンテンツは:
- Session
- セッション
- OI (Outgoing Interface)
- OI(外向的なインタフェース)
- Filter_spec_list
- フィルタ_仕様_リスト
- TC_Flowspec, the effective flowspec, i.e., the LUB over the
corresponding FLOWSPEC values from matching RSB's.
TC_Flowspec is passed to traffic control to make the actual
reservation.
- すなわち、TC_Flowspec、有効なflowspec、合っているRSBのものからの対応するFLOWSPEC値の上のLUB。 TC_Flowspecは、実際の予約をするようにトラフィックコントロールに渡されます。
- Fwd_Flowspec, the updated object to be forwarded
after merging.
- Fwd_Flowspec、合併した後に進められるアップデートされた物。
- TC_Tspec, equal to Path_Te, the effective sender Tspec.
- Path_Te、有効な送付者Tspecと等しいTC_Tspec。
- Police Flags
- 警察の旗
The flags are E_Police_Flag, M_Police_Flag, and
B_Police_Flag.
旗はE_警察_Flag、_M警察_Flag、および_B警察_Flagです。
Braden & Zhang Informational [Page 3] RFC 2209 RSVP-Message Processing September 1997
[3ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
- Rhandle, F_Handle_list
- Rhandle、F_は_リストを扱います。
Handles returned by the traffic control interface,
corresponding to a flowspec and perhaps a list of filter
specs.
フィルタ仕様のflowspecと恐らくリストに対応している、ハンドルはトラフィックコントロールインタフェースのそばで戻りました。
- A RESV_CONFIRM object to be forwarded.
- 進められるRESV_CONFIRM物。
o BSB -- Blockade State Block
o BSB--封鎖州のブロック
Each BSB contains an element of blockade state. Depending upon
the reservation style in use, the BSB's may be per (session,
sender_template) pair or per (session, PHOP) pair. In practice,
an implementation might embed a BSB within a PSB; however, for
clarity we describe BSB's independently.
各BSBは封鎖州の要素を含んでいます。 予約スタイルに使用中によって、BSBのものが(セッション、送付者_テンプレート)組か1(セッション、PHOP)組単位であるかもしれません。 習慣に、実現はPSBの中でBSBを埋め込むかもしれません。 しかしながら、明快ために、私たちは独自にBSBのものについて説明します。
The contents of a BSB include:
BSBのコンテンツは:
- Session
- セッション
- Sender_Template (which is also a filter spec)
- 送付者_テンプレート(また、フィルタ仕様です)
- PHOP
- PHOP
- FLOWSPEC Qb
- FLOWSPEC Qb
- Blockade timer Tb
- 封鎖タイマTb
The following Boolean Flag variables are used in this section:
Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed,
Need_Scope, B_Merge, and NeworMod. Refresh_PHOP_list is a
variable-length list of PHOPs to be refreshed.
以下のブールFlag変数はこのセクションで使用されます: 経路_は必要である_をリフレッシュして、Resv_は必要である_、_が必要とした裂け目、必要性_範囲、B_マージ、およびNeworModをリフレッシュします。 リフレッシュしてください。_PHOP_リストはリフレッシュされるべきPHOPsの可変長のリストです。
2. PROCESSING RULES
2. 処理規則
MESSAGE ARRIVES
メッセージは到着します。
Verify version number and RSVP checksum, and discard message if any mismatch is found.
バージョン番号とRSVPチェックサムについて確かめてください、そして、何かミスマッチが見つけられるなら、メッセージを捨ててください。
If the message type is not PATH or PTEAR or RACK and if the IP destination address does not match any of the addresses of the local interfaces, then forward the message to IP destination address and return.
メッセージタイプがPATHでなくて、またPTEARでなくて、またRACKでもなく、受信者IPアドレスが局所界面のアドレスのいずれにも合っていないなら、受信者IPアドレスとリターンにメッセージを転送してください。
Parse the sequence of objects in the message. If any required objects are missing or the length field of the common header does not match an object boundary, discard the message and return.
メッセージの物の系列を分析してください。 どんな必要な物もなくなるか、または一般的なヘッダーの長さの分野が物の限界に合っていないなら、メッセージとリターンを捨ててください。
Braden & Zhang Informational [Page 4] RFC 2209 RSVP-Message Processing September 1997
[4ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
Verify the INTEGRITY object, if any. If the check fails, discard the message and return.
もしあればINTEGRITY物について確かめてください。 チェックが失敗するなら、メッセージとリターンを捨ててください。
Verify the consistent use of port fields. If the DstPort in the SESSION object is zero but the SrcPort in a SENDER_TEMPLATE or FILTER_SPEC object is non-zero, then the message has a "conflicting source port" error; silently discard the message and return.
ポート分野の一貫した使用について確かめてください。 SESSION物のDstPortがゼロですが、SENDER_TEMPLATEかFILTER_SPEC物のSrcPortが非ゼロであるなら、メッセージには、「闘争しているソース港」誤りがあります。 静かにメッセージとリターンを捨ててください。
Processing of POLICY_DATA objects will be specified in the future.
POLICY_DATA物の処理は将来、指定されるでしょう。
Further processing depends upon message type.
さらなる処理はメッセージタイプに頼っています。
PATH MESSAGE ARRIVES
経路メッセージは到着します。
Assume the PATH message arrives on interface InIf.
PATHメッセージがインタフェースInIfで到着すると仮定してください。
Process the sender descriptor object sequence in the message as follows. The Path_Refresh_Needed and Resv_Refresh_Needed flags are initially off.
以下のメッセージの送付者記述子物の系列を処理してください。 Refresh_が必要としたPath_と初めは、必要な旗があるResv_Refresh_。
o Search for a path state block (PSB) whose (session,
sender_template) pair matches the corresponding objects in the
message, and whose IncInterface matches InIf.
o (セッション、送付者_テンプレート)組がメッセージで対応するオブジェクトに合っていて、IncInterfaceがInIfに合っている経路州のブロック(PSB)を検索してください。
During this search:
これの間、探してください:
1. If a PSB is found whose session matches the
DestAddress and Protocol Id fields of the received
SESSION object, but the DstPorts differ and one is
zero, then build and send a "Conflicting Dst Port"
PERR message, drop the PATH message, and return.
1. セッションが容認されたSESSION物のDestAddressとプロトコルId分野に合っているPSBが見つけられますが、DstPortsが異なって、1つがゼロであるなら、「闘争しているDstポート」PERRメッセージを築き上げて、送ってください、そして、PATHメッセージを落としてください、そして、戻ってください。
2. If a PSB is found with a matching sender host but the
Src Ports differ and one of the SrcPorts is zero, then
build and send an "Ambiguous Path" PERR message, drop
the PATH message, and return.
2. PSBが合っている送付者ホストと共に見つけられますが、Src Portsが異なって、SrcPortsの1つがゼロであるなら、「あいまいな経路」PERRメッセージを築き上げて、送ってください、そして、PATHメッセージを落としてください、そして、戻ってください。
3. If a forwarding PSB is found, i.e., a PSB that matches
the (session, sender_template) pair and whose
Local_Only flag is off, save a pointer to it in the
variable fPSB. If none is found, set fPSB to NULL.
3. 推進PSBが見つけられるなら、すなわち、(セッション、送付者_テンプレート)組を合わせて、Local_Onlyが弛むPSBはオフであり、可変fPSBにそれへポインタを取っておいてください。 なにも見つけられないなら、NULLにfPSBを設定してください。
o If there was no matching PSB, then:
o 次に、合っているPSBが全くなかったなら:
1. Create a new PSB.
1. 新しいPSBを作成してください。
2. Copy contents of the SESSION, SENDER_TEMPLATE,
SENDER_TSPEC, and PHOP (IP address and LIH) objects
2. SESSIONのコピーコンテンツ、SENDER_TEMPLATE、SENDER_TSPEC、およびPHOP(IPアドレスとLIH)物
Braden & Zhang Informational [Page 5] RFC 2209 RSVP-Message Processing September 1997
[5ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
into the PSB.
PSBに。
3. If the sender is from the local API, set
OutInterface_List to the single interface whose
address matches the sender address, and make
IncInterface undefined. Otherwise, turn on the
Local_Only flag.
3. 送付者が地方のAPIから来ているなら、アドレスが送付者アドレスに合っている単一のインタフェースにOutInterface_Listを設定してください、そして、IncInterfaceを未定義にしてください。 さもなければ、Local_Only旗をつけてください。
4. Turn on the Path_Refresh_Needed flag.
4. Path_Refresh_における回転は旗を必要としました。
o Otherwise (there is a matching PSB):
o そうでなければ(合っているPSBがあります):
- If the PHOP IP address, the LIH, or Sender_Tspec
differs between the message and the PSB, copy the new
value into the PSB and turn on the Path_Refresh_Needed
flag. If the PHOP IP address or the LIH differ, also
turn on the Resv_Refresh_Needed flag.
- PHOP IPアドレス、LIH、またはSender_TspecがメッセージとPSBの間で異なって、コピーがPSBへの新しい値であり、回転が進行中なら、_が必要としたPath_Refreshは弛みます。 PHOP IPアドレスかLIHが異なって、また、つくなら、_が必要としたResv_Refreshは弛みます。
o Call the resulting PSB the "current PSB" (cPSB). Update
the cPSB, as follows:
o 結果として起こるPSBを「現在のPSB」(cPSB)と呼んでください。 以下の通りcPSBをアップデートしてください:
- Start or Restart the cleanup timer for the PSB.
- 始まってください。さもないと、RestartはPSBのためのクリーンアップタイマを始めます。
- If the message contains an ADSPEC object, copy it into
the PSB.
- メッセージがADSPEC物を含むなら、PSBにそれをコピーしてください。
- Copy E_Police flag from SESSION object into PSB.
- 警察がSESSIONから旗を揚げさせるコピーE_はPSBに反対します。
- Store the received TTL into the PSB.
If the received TTL differs from Send_TTL in the RSVP
common header, set the Non_RSVP flag on in the PSB.
- 容認されたTTLをPSBに格納してください。 容認されたTTLがRSVPの一般的なヘッダーでSend_TTLと異なっているなら、PSBでオンなNon_RSVP旗を設定してください。
o If the PSB is new or if there is no route change
notification in place, then perform the following routing
manipulations, but not if the cPSB is from the local API.
o PSBが新しいか、cPSBが地方のAPIから来ていなくて、またまたはルート変更届出書が全く適所になければ、以下のルーティング操作を実行してください。
1. Invoke the appropriate Route_Query routine using
DestAddress from SESSION and (for multicast routing)
SrcAddress from Sender_Template.
1. SESSIONと(マルチキャストルーティングのための)SrcAddressからSender_TemplateからDestAddressを使用して、適切なRoute_Queryルーチンを呼び出してください。
Call the results (Rt_OutL, Rt_InIf).
(Rt_OutL、Rt_InIf)に結果に電話をしてください。
2. If the destination is multicast and Rt_InIf differs
from IncInterface in the cPSB, but fPSB points to the
cPSB, then do the following.
2. 目的地がマルチキャストであり、Rt_InIfがcPSBでIncInterfaceと異なっていますが、fPSBがcPSBを示すなら、以下をしてください。
- Turn on the Local_Only flag and clear the
OutInterface_list of the fPSB. Set the fPSB
- Local_Only旗をつけてください、そして、OutInterface_リストからfPSBを取り除いてください。 fPSBを設定してください。
Braden & Zhang Informational [Page 6] RFC 2209 RSVP-Message Processing September 1997
[6ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
pointer to NULL.
NULLへのポインタ。
- Search for a PSB for the same (session,
sender_template) pair whose IncInterface matches
Rt_InIf. If one is found, set fPSB to point to
it.
- IncInterfaceがRt_InIfに合っているのと同じ(セッション、送付者_テンプレート)組のためにPSBを捜し求めてください。 1つが見つけられるなら、fPSBにそれを示すように設定してください。
3. If the destination is multicast and Rt_InIf is the
same as IncInterface in the cPSB, but fPSB does not
point to the cPSB, then do the following.
3. 目的地がマルチキャストであり、Rt_InIfがcPSBでIncInterfaceと同じですが、fPSBがcPSBを示さないなら、以下をしてください。
- Copy into the cPSB the OutInterface_list from the
PSB, if any, pointed to by fPSB. Clear
OutInterface_list and turn on the Local_Only flag
in the PSB pointed to by fPSB, if any.
- もしあればfPSBによって示されたPSBからのOutInterface_リストをcPSBにコピーしてください。 もしあればOutInterface_リストをきれいにしてください、そして、fPSBによって示されたPSBのLocal_Only旗をつけてください。
- Turn off the Local_Only flag in the cPSB and set
fPSB to point to cPSB.
- cPSBのLocal_Only旗をオフにしてください、そして、fPSBにcPSBを示すように設定してください。
4. If Rt_OutL differs from OutInterface_list of the PSB
pointed to by fPSB, then:
4. Rt_OutLが次にfPSBが示されたPSBのOutInterface_リストと異なっているなら:
- Update the OutInterface_list of the PSB from
Rt_OutL, and then execute the PATH LOCAL REPAIR
event sequence below.
- Rt_OutLからPSBのOutInterface_リストをアップデートしてください、そして、次に、以下のPATH LOCAL REPAIRイベント系列を実行してください。
o If the Path_Refresh_Needed flag is now off, drop the PATH
message and return.
o 現在、必要な旗があるPath_Refresh_であるなら、PATHメッセージとリターンを落としてください。
Otherwise (the path state is new or modified), do
refreshes, upcalls, and state updates as follows.
さもなければ(経路州は、新しいか変更されている)、以下のアップデートをリフレッシュして、upcallsして、述べてください。
1. If this PATH message came from a network interface and
not from a local application, make a Path Event upcall
for each local application for this session:
1. このPATHメッセージが局所塗布から来たのではなく、ネットワーク・インターフェースから来たなら、このセッションのための各局所塗布のためにPath Event upcallを作ってください:
Call: <Upcall_Proc>( session-id, PATH_EVENT,
flags, sender_tspec, sender_template
[ , ADSPEC] [ , POLICY_DATA] )
以下に電話をしてください。 <Upcall_Proc>。(セッションイド(PATH_EVENT)が弛んで、_tspec送付者送付者_がテンプレートである、[ADSPEC]、[POLICY_DATA])
2. If OutInterface_list is not empty, execute the PATH
REFRESH event sequence (below) for the sender defined
by the PSB.
2. OutInterface_リストが空でないなら、PSBによって定義された送付者のためにPATH REFRESHイベント系列(below)を実行してください。
3. Search for any matching reservation state, i.e., an
RSB whose Filter_spec_list includes a FILTER_SPEC
matching the SENDER_TEMPLATE and whose OI appears in
the OutInterface_list, and make this the `active RSB'.
3. どんな合っている予約状態の検索、すなわち、Filter_仕様_リストがSENDER_TEMPLATEに合っているFILTER_SPECを含んで、OIがOutInterface_に現れるRSBはこの'アクティブなRSB'を記載して、作ります。
Braden & Zhang Informational [Page 7] RFC 2209 RSVP-Message Processing September 1997
[7ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
If none is found, drop the PATH message and return.
なにも見つけられないなら、PATHメッセージとリターンを落としてください。
4. Execute the RESV REFRESH sequence (below) for the PHOP
in the PSB.
4. PSBのPHOPのためにRESV REFRESH系列(below)を実行してください。
5. Execute the event sequence UPDATE TRAFFIC CONTROL to
update the local traffic control state if necessary.
This sequence will turn on the Resv_Refresh_Needed
flag if the traffic control state has been modified in
a manner that should trigger a reservation refresh.
If so, execute the RESV REFRESH sequence for the PHOP
in the PSB.
5. イベント系列UPDATE TRAFFIC CONTROLを実行して、必要なら、地方のトラフィックコントロール状態をアップデートしてください。 トラフィックコントロール状態がそれが引き金となるべきである方法で変更されて、予約がリフレッシュするということであるなら、この系列は_必要な旗をResv_Refreshに変えるでしょう。 そうだとすれば、PSBのPHOPのためにRESV REFRESH系列を実行してください。
o Drop the PATH message and return.
o PATHメッセージとリターンを落としてください。
PTEAR MESSAGE ARRIVES
PTEARメッセージは到着します。
o Search for a PSB whose (Session, Sender_Template) pair
matches the corresponding objects in the message. If no
matching PSB is found, drop the PTEAR message and return.
o (セッション、Sender_Template)組がメッセージで対応するオブジェクトに合っているPSBを捜し求めてください。 合っているPSBが全く見つけられないなら、PTEARメッセージとリターンを落としてください。
o Forward a copy of the PTEAR message to each outgoing
interface listed in OutInterface_list of the PSB.
o 前方に、それぞれの外向的なインタフェースへのPTEARメッセージのコピーはPSBのOutInterface_リストに記載しました。
o Find each RSB that matches this PSB, i.e., whose
Filter_spec_list matches Sender_Template in the PSB and
whose OI is included in OutInterface_list.
o このPSBを合わせて、すなわち、Filter_仕様_リストがPSBでSender_Templateに合っていて、OIがOutInterface_リストに含まれている各RSBを見つけてください。
1. If the RSB style is explicit, then:
- Delete from Filter_spec_list the FILTER_SPEC that
matches the PSB.
1. 次に、RSBスタイルが明白であるなら: - Filter_仕様_リストから、PSBに合っているFILTER_SPECを削除してください。
- if Filter_spec_list is now empty, delete the RSB.
- Filter_仕様_リストが現在空であるなら、RSBを削除してください。
2. Otherwise (RSB style is wildcard) then:
2. (RSBスタイルはワイルドカードです) そうでなければ、その時:
- If this RSB matches no other PSB, then delete the
RSB.
- このRSBが他のPSBに全く合っていないなら、RSBを削除してください。
3. If an RSB was found, execute the event sequence UPDATE
TRAFFIC CONTROL (below) to update the traffic control
state to be consistent with the current reservation
and path state.
3. RSBが見つけられたなら、イベント系列UPDATE TRAFFIC CONTROL (below)を実行して、現在の予約と経路州と一致しているようにトラフィックコントロール状態をアップデートしてください。
o Delete the PSB.
o PSBを削除してください。
o Drop the PTEAR message and return.
o PTEARメッセージとリターンを落としてください。
Braden & Zhang Informational [Page 8] RFC 2209 RSVP-Message Processing September 1997
[8ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
PERR MESSAGE ARRIVES
PERRメッセージは到着します。
o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
matches the corresponding objects in the message. If no
matching PSB is found, drop the PERR message and return.
o (SESSION、SENDER_TEMPLATE)組がメッセージで対応するオブジェクトに合っているPSBを捜し求めてください。 合っているPSBが全く見つけられないなら、PERRメッセージとリターンを落としてください。
o If the previous hop address in the PSB is the local API,
make an error upcall to the application:
o PSBの前のホップアドレスが地方のAPIであるなら、誤りをアプリケーションへのupcallにしてください:
Call: <Upcall_Proc>( session-id, PATH_ERROR,
Error_code, Error_value, Node_Addr,
Sender_Template [ , Policy_Data] )
以下に電話をしてください。 <Upcall_Proc>。(セッションイド、PATH_ERROR、Error_コード、Error_価値、Node_Addr、Sender_Template[Policy_Data])
Any SENDER_TSPEC or ADSPEC object in the message is
ignored.
メッセージのどんなSENDER_TSPECやADSPEC物も無視されます。
Otherwise, send a copy of the PERR message to the PHOP IP
address.
さもなければ、PERRメッセージのコピーをPHOP IPアドレスに送ってください。
o Drop the PERR message and return.
o PERRメッセージとリターンを落としてください。
RESV MESSAGE ARRIVES
RESVメッセージは到着します。
Initially, Refresh_PHOP_list is empty and the
Resv_Refresh_Needed and NeworMod flags are off. These variables
are used to control immediate reservation refreshes.
初めは、Refresh_PHOP_リストは空です、そして、_が必要であり、NeworModが旗を揚げさせるResv_Refreshはオフです。 これらの変数は即座の予約がリフレッシュするコントロールに使用されます。
o Determine the Outgoing Interface OI
o 出発しているインタフェースOIを決定してください。
The logical outgoing interface OI is taken from the LIH in
the NHOP object. (If the physical interface is not implied
by the LIH, it can be learned from the interface matching
the IP destination address).
NHOP物でLIHから論理的な出発しているインタフェースOIを取ります。 (物理インターフェースがLIHによって含意されないなら、受信者IPアドレスに合っているインタフェースからそれについて学習できます。)
o Check the path state
o 経路州をチェックしてください。
1. If there are no existing PSB's for SESSION then build
and send a RERR message (as described later)
specifying "No path information", drop the RESV
message, and return.
1. SESSIONのための既存のPSBのどんなものもなければ、建ててください、そして、RERRメッセージ(後述のようである)に「経路情報がありません」を指定させてください、そして、RESVメッセージを落としてください、そして、戻ってください。
2. If a PSB is found with a matching sender host but the
SrcPorts differ and one of the SrcPorts is zero, then
build and send an "Ambiguous Path" PERR message, drop
the RESV message, and return.
2. PSBが合っている送付者ホストと共に見つけられますが、SrcPortsが異なって、SrcPortsの1つがゼロであるなら、「あいまいな経路」PERRメッセージを築き上げて、送ってください、そして、RESVメッセージを落としてください、そして、戻ってください。
Braden & Zhang Informational [Page 9] RFC 2209 RSVP-Message Processing September 1997
[9ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
o Check for incompatible styles.
o 両立しないスタイルがないかどうかチェックしてください。
If any existing RSB for the session has a style that is
incompatible with the style of the message, build and send
a RERR message specifying "Conflicting Style", drop the
RESV message, and return.
セッションのためのどんな既存のRSBにもメッセージのスタイルと両立しないスタイルがあるなら、建ててください、そして、RERRメッセージに「闘争様式」を指定させてください、そして、RESVメッセージを落としてください、そして、戻ってください。
Process the flow descriptor list to make reservations, as
follows, depending upon the style. The following uses a filter
spec list struct Filtss of type FILTER_SPEC* (defined earlier).
流れ記述子リストを処理して、スタイルによって、以下の通り予約をしてください。 フィルタ仕様がstruct Filtssを記載する以下の用途はFILTER_SPEC*(より早く定義されます)をタイプします。
For FF style: execute the following steps independently for each
flow descriptor in the message, i.e., for each (FLOWSPEC,
Filtss) pair. Here the structure Filtss consists of the
FILTER_SPEC from the flow descriptor.
FFに関しては、以下を流行に合わせてください。 すなわち、メッセージのそれぞれの流れ記述子、それぞれの(FLOWSPEC、Filtss)組のために独自に以下のステップを実行してください。 ここで、構造Filtssは流れ記述子からのFILTER_SPECから成ります。
For SE style, execute the following steps once for (FLOWSPEC,
Filtss), with Filtss consisting of the list of FILTER_SPEC
objects from the flow descriptor.
SEスタイルには、(FLOWSPEC、Filtss)のための一度以下のステップを実行してください、Filtssが流れ記述子からのFILTER_SPEC物のリストから成っていて。
For WF style, execute the following steps once for (FLOWSPEC,
Filtss), with Filtss an empty list.
WFスタイルのために、Filtssと共に以下のステップをかつて(FLOWSPEC、Filtss)のために実行してください。空のリスト。
o Check the path state, as follows.
o 以下の経路州をチェックしてください。
1. Locate the set of PSBs (senders) that route to OI and
whose SENDER_TEMPLATEs match a FILTER_SPEC in Filtss.
1. FiltssでOIとSENDER_TEMPLATEsがだれのものに合っているかにFILTER_SPECを発送するPSBs(送付者)のセットの場所を見つけてください。
If this set is empty, build and send an error message
specifying "No sender information", and continue with
the next flow descriptor in the RESV message.
このセットが空であるなら、建ててください、そして、エラーメッセージに「送付者情報がありません」を指定させてください、そして、RESVメッセージの次の流れ記述子を続行してください。
2. If the style has explicit sender selection (e.g., FF
or SE) and if any FILTER_SPEC included in Filtss
matches more than one PSB, build and send a RERR
message specifying "Ambiguous filter spec" and
continue with the next flow descriptor in the RESV
message.
2. スタイルで明白な送付者選択(例えば、FFかSE)があって、どれかFILTER_SPECがFiltssマッチに1PSBを含んでいたなら、建ててください、そして、RERRメッセージに「あいまいなフィルタ仕様」を指定させてください、そして、RESVメッセージの次の流れ記述子を続行してください。
3. If the style is SE and if some FILTER_SPEC included in
Filtss matches no PSB, delete that FILTER_SPEC from
Filtss.
3. スタイルがSEであり、いくらかのFILTER_SPECがFiltssマッチにPSBを全く含んでいなかったなら、FiltssからそのFILTER_SPECを削除してください。
4. Add the PHOP from the PSB to Refresh_PHOP_list, if the
PHOP is not already on the list.
4. PHOPがリストに既にないなら、PSBからRefresh_PHOP_までのPHOPが記載すると言い足してください。
Braden & Zhang Informational [Page 10] RFC 2209 RSVP-Message Processing September 1997
[10ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
o Find or create a reservation state block (RSB) for
(SESSION, NHOP). If the style is distinct, Filtss is also
used in the selection. Call this the "active RSB".
o (SESSION、NHOP)のために予約州のブロック(RSB)を見つけるか、または作成してください。 また、スタイルが異なるなら、Filtssは選択に使用されます。 この「アクティブなRSB」に電話をしてください。
o If the active RSB is new:
o アクティブなRSBが新しいなら:
1. Set the session, NHOP, OI and style of the RSB from
the message.
1. メッセージからRSBのセッション、NHOP、OI、およびスタイルを設定してください。
2. Copy Filtss into the Filter_spec_list of the RSB.
2. RSBのフィルタ_仕様_リストの中にFiltssをコピーしてください。
3. Copy the FLOWSPEC and any SCOPE object from the
message into the RSB.
3. メッセージからRSBにFLOWSPECとあらゆるSCOPE物をコピーしてください。
4. Set NeworMod flag on.
4. NeworModが弛むセット。
o If the active RSB is not new, check whether Filtss from the
message contains FILTER_SPECs that are not in the RSB; if
so, add the new FILTER_SPECs and turn on the NeworMod flag.
o アクティブなRSBが新しくないなら、メッセージからのFiltssがRSBにないFILTER_SPECsを含むかどうかチェックしてください。 そうだとすれば、新しいFILTER_SPECsを加えてください、そして、NeworMod旗をつけてください。
o Start or restart the cleanup timer on the active RSB, or,
in the case of SE style, on each FILTER_SPEC of the RSB
that also appears in Filtss.
o 始まるか、またはまたは、また、Filtssに現れるRSBの各FILTER_SPECの上のSEスタイルの場合でアクティブなRSBの上のクリーンアップタイマを再開してください。
o If the active RSB is not new, check whether STYLE, FLOWSPEC
or SCOPE objects have changed; if so, copy changed object
into RSB and turn on the NeworMod flag.
o アクティブなRSBが新しくないなら、様式、FLOWSPECまたはSCOPE物が変化したかどうかチェックしてください。 そうだとすれば、コピーはNeworMod旗で物をRSBと回転に変えました。
o If the message contained a RESV_CONFIRM object, copy it
into the RSB and turn on NeworMod flag.
o メッセージがRESV_CONFIRM物を含んだなら、RSBにそれをコピーしてください、そして、NeworMod旗をつけてください。
o If the NeworMod flag is off, continue with the next flow
descriptor in the RESV message, if any.
o NeworMod旗がオフであるなら、もしあればRESVメッセージの次の流れ記述子を続行してください。
o Otherwise (the NeworMod flag is on, i.e., the active RSB is
new or modified), execute the UPDATE TRAFFIC CONTROL event
sequence (below). If the result is to modify the traffic
control state, this sequence will turn on the
Resv_Refresh_Needed flag and make a RESV_EVENT upcall to
any local application.
o さもなければ(NeworMod旗がオンである、すなわち、アクティブなRSBは新しいか変更されている)、UPDATE TRAFFIC CONTROLイベント系列(below)を実行してください。 結果がトラフィックコントロール状態、この系列を変更するために、ターンするということであるなら、_が必要としたResv_Refreshでは、RESV_EVENT upcallのあらゆる局所塗布に旗を揚げて、してください。
If the UPDATE TRAFFIC CONTROL sequence fails with an error,
then delete a new RSB but restore the original reservation
in an old RSB.
誤りに応じてUPDATE TRAFFIC CONTROL系列が失敗するなら、新しいRSBを削除しなさい、ただし、古いRSBで当初の予約を復元してください。
o Continue with the next flow descriptor.
o 次の流れ記述子を続行してください。
Braden & Zhang Informational [Page 11] RFC 2209 RSVP-Message Processing September 1997
[11ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
o When all flow descriptors have been processed, check the
Resv_Refresh_Needed flag. If it is now on, execute the
RESV REFRESH sequence (below) for each PHOP in
Refresh_PHOP_list.
o すべての流れ記述子を処理してあるとき、Resv_Refresh_が必要としたチェックは弛みます。 それが現在オンであるなら、Refresh_PHOP_リストの各PHOPのためにRESV REFRESH系列(below)を実行してください。
o Drop the RESV message and return.
o RESVメッセージとリターンを落としてください。
If processing a RESV message finds an error, a RERR message
is created containing flow descriptor and an ERRORS object.
The Error Node field of the ERRORS object is set to the IP
address of OI, and the message is sent unicast to NHOP.
処理するなら、RESVメッセージは間違いを見つけます、そして、流れ記述子を含んでいて、RERRメッセージは作成されます、そして、ERRORSは反対します。 ERRORS物のError Node分野をOIのIPアドレスに設定します、そして、メッセージはユニキャストをNHOPに送ります。
RTEAR MESSAGE ARRIVES
RTEARメッセージは到着します。
Processing of a RTEAR message roughly parallels the processing
of the corresponding RESV message
RTEARメッセージの処理はおよそ対応するRESVメッセージの処理に沿います。
A RTEAR message arrives with an IP destination address matching
outgoing interface OI. Flag Resv_Refresh_Needed is initially
off and Refresh_PHOP_list is empty.
受信者IPアドレスが出発しているインタフェースOIに合っていて、RTEARメッセージは到着します。 Refresh_が必要とした旗のResv_は初めはオフです、そして、Refresh_PHOP_リストは空です。
o Determine the Outgoing Interface OI
o 出発しているインタフェースOIを決定してください。
The logical outgoing interface OI is taken from the LIH in
the NHOP object. (If the physical interface is not implied
by the LIH, it can be learned from the interface matching
the IP destination address).
NHOP物でLIHから論理的な出発しているインタフェースOIを取ります。 (物理インターフェースがLIHによって含意されないなら、受信者IPアドレスに合っているインタフェースからそれについて学習できます。)
o Process the flow descriptor list in the RTEAR message to
tear down local reservation state, as follows, depending
upon the style. The following uses a filter spec list
struct Filtss of type FILTER_SPEC* (defined earlier).
o 地方の予約状態を取りこわすRTEARメッセージの流れ記述子リストを処理してください、以下の通りです、スタイルによって。 フィルタ仕様がstruct Filtssを記載する以下の用途はFILTER_SPEC*(より早く定義されます)をタイプします。
For FF style: execute the following steps independently for
each flow descriptor in the message, i.e., for each
(FLOWSPEC, Filtss) pair. Here the structure Filtss
consists of the FILTER_SPEC from the flow descriptor.
FFに関しては、以下を流行に合わせてください。 すなわち、メッセージのそれぞれの流れ記述子、それぞれの(FLOWSPEC、Filtss)組のために独自に以下のステップを実行してください。 ここで、構造Filtssは流れ記述子からのFILTER_SPECから成ります。
For SE style, execute the following steps once for
(FLOWSPEC, Filtss), with Filtss consisting of the list of
FILTER_SPEC objects from the flow descriptor.
SEスタイルには、(FLOWSPEC、Filtss)のための一度以下のステップを実行してください、Filtssが流れ記述子からのFILTER_SPEC物のリストから成っていて。
For WF style, execute the following steps once for
(FLOWSPEC, Filtss), with Filtss an empty list.
WFスタイルのために、Filtssと共に以下のステップをかつて(FLOWSPEC、Filtss)のために実行してください。空のリスト。
Braden & Zhang Informational [Page 12] RFC 2209 RSVP-Message Processing September 1997
[12ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
1. Find an RSB matching (SESSION, NHOP). If the style is
distinct, Filtss is also used in the selection. Call
this the "active RSB". If no active RSB is found,
continue with next flow descriptor.
1. RSBが(SESSION、NHOP)に合っていると確かめてください。 また、スタイルが異なるなら、Filtssは選択に使用されます。 この「アクティブなRSB」に電話をしてください。 どんなアクティブなRSBも見つけられないなら、次の流れ記述子を続行してください。
2. Check the style
2. スタイルをチェックしてください。
If the active RSB has a style that is incompatible
with the style of the message, drop the RTEAR message
and return.
アクティブなRSBにメッセージのスタイルと両立しないスタイルがあるなら、RTEARメッセージとリターンを落としてください。
3. Delete from the active RSB each FILTER_SPEC that
matches a FILTER_SPEC in Filtss.
3. アクティブなRSBから、FiltssでFILTER_SPECに合っている各FILTER_SPECを削除してください。
4. If all FILTER_SPECs have now been deleted from the
active RSB, delete the active RSB.
4. すべてのFILTER_SPECsが現在アクティブなRSBから削除されたなら、アクティブなRSBを削除してください。
5. Execute the UPDATE TRAFFIC CONTROL event sequence
(below) to update the traffic control state to be
consistent with the reservation state. If the result
is to modify the traffic control state, the
Resv_Refresh_Needed flag will be turned on and a
RESV_EVENT upcall will be made to any local
application.
5. UPDATE TRAFFIC CONTROLイベント系列(below)を実行して、予約状態と一致しているようにトラフィックコントロール状態をアップデートしてください。 結果がトラフィックコントロール状態を変更することであるなら、必要な旗が回されるResv_Refresh_とRESV_EVENT upcallをどんな局所塗布にもするでしょう。
6. Continue with the next flow descriptor.
6. 次の流れ記述子を続行してください。
o All flow descriptors have been processed.
o すべての流れ記述子を処理してあります。
Build and send any RTEAR messages to be forwarded, in the
following manner.
以下の方法で建ててください、そして、あらゆる進められるべきRTEARメッセージを送ってください。
1. Select each PSB that routes to the outgoing interface
OI, and, for distinct style, that has a
SENDER_TEMPLATE matching Filtss.
1. 外向的なインタフェースにOIを発送する各PSBを選択してください。そうすれば、異なったスタイルのために、SENDER_TEMPLATEはそれでFiltssに合っています。
2. Select a flow descriptor (Qj,Fj) (where Fj may be a
list) in the RTEAR message whose FILTER_SPEC matches
the SENDER_TEMPLATE in the PSB. If not match is
found, return for next PSB.
2. FILTER_SPECがPSBでSENDER_TEMPLATEに合っているRTEARメッセージの流れ記述子(Qj、Fj)(Fjがリストであるかもしれないところ)を選択してください。 どれかマッチが見つけられないなら、次のPSBには、戻ってください。
- Search for an RSB (for any outgoing interface) to
which the PSB routes and whose Filter_spec_list
includes the SENDER_TEMPLATE from the PSB.
- PSBからPSBがどれを発送するか、そして、だれのFilter_仕様_リストがSENDER_TEMPLATEを含んでいるかにRSB(どんな外向的なインタフェースへのも)を捜し求めてください。
- If an RSB is found, add the PHOP of the PSB to
the Refresh_PHOP_list.
- RSBが見つけられるなら、Refresh_PHOP_リストにPSBのPHOPを追加してください。
Braden & Zhang Informational [Page 13] RFC 2209 RSVP-Message Processing September 1997
[13ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
- Otherwise (no RSB is found), add the flow
descriptor (Qj,Fj) to the new RTEAR message being
built, in a manner appropriate to the style.
- さもなければ(RSBは全く見つけられない)、流れ記述子(Qj、Fj)を築き上げられる新しいRTEARメッセージに追加してください、スタイルに適切な方法で。
- Continue with the next PSB.
- 次のPSBを続行してください。
3. If the next PSB is for a different PHOP or the last
PSB has been processed, forward any RTEAR message that
has been built.
3. 次のPSBが異なったPHOPのためのものであるか最後のPSBが処理されたなら、築き上げられたあらゆるRTEARメッセージを転送してください。
o If any PSB's were found in the preceding step, and if the
Resv_Refresh_Needed flag is now on, execute the RESV
REFRESH sequence (below) for each PHOP in
Refresh_PHOP_list.
o _PSBのどんなものも前のステップで見つけられて、必要な旗がResv_Refreshであるなら今オンであるなら、Refresh_PHOP_リストの各PHOPのためにRESV REFRESH系列(below)を実行してください。
o Drop the RTEAR message and return.
o RTEARメッセージとリターンを落としてください。
RERR MESSAGE ARRIVES
RERRメッセージは到着します。
A RERR message arrives through the (real) incoming interface
In_If.
RERRメッセージは(本当)の入って来るインタフェースIn_Ifを通して到着します。
o If there is no path state for SESSION, drop the RERR
message and return.
o SESSIONのための経路州が全くなければ、RERRメッセージとリターンを落としてください。
o If the Error Code = 01 (Admission Control failure), do
special processing as follows:
o Error Code=01である(入場Controlの故障)なら、以下の特別な処理をしてください:
1. Find or create a Blockade State Block (BSB), in the
following style-dependent manner.
1. 以下のスタイル依存する方法でBlockade州Block(BSB)を見つけるか、または作成してください。
For WF (wildcard) style, there will be one BSB per
(session, PHOP) pair.
WF(ワイルドカード)スタイルのために、(セッション、PHOP)組あたり1BSBがあるでしょう。
For FF style, there will be one BSB per (session,
filter_spec) pair. Note that an FF style RERR message
carries only one flow descriptor.
FFスタイルのために、(セッション、フィルタ_仕様)組あたり1BSBがあるでしょう。 FFスタイルRERRメッセージが1つの流れ記述子だけを運ぶことに注意してください。
For SE style, there will be one BSB per (session,
filter_spec), for each filter_spec contained in the
filter spec list of the flow descriptor.
SEスタイルのために、(セッション、フィルタ_仕様)あたり1BSBがあるでしょう、流れ記述子のフィルタ仕様リストに含まれた各フィルタ_仕様のために。
2. For each BSB in the preceding step, set (or replace)
its FLOWSPEC Qb with FLOWSPEC from the message, and
set (or reset) its timer Tb to Kb*R seconds. If the
BSB is new, set its PHOP value, and set its
Sender_Template equal to the appropriate filter_spec
from the message.
2. 前のステップにおける各BSBに関して、セットしてください、(取り替え、)、メッセージからのFLOWSPECとFLOWSPEC Qb、およびKB*RへのタイマTbが後援するセット(または、リセット)。 BSBが新しいなら、PHOP値を設定してください、そして、メッセージからの適切なフィルタ_仕様と等しいSender_Templateを設定してください。
Braden & Zhang Informational [Page 14] RFC 2209 RSVP-Message Processing September 1997
[14ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
3. Execute the RESV REFRESH event sequence (shown below)
for the previous hop PHOP, but only with the B_Merge
flag off. That is, if processing in the RESV REFRESH
sequence reaches the point of turning the B_Merge flag
on (because all matching reservations are blockaded),
do not turn it on but instead exit the REFRESH
sequence and return here.
3. 前のホップPHOPのために、RESV REFRESHイベント系列(以下では、目立つ)を実行しますが、B_Merge旗だけがオフな状態で実行してください。 すなわち、RESV REFRESH系列における処理がB_Merge旗をつける意味に達するなら(すべての合っている予約が封鎖されるので)、見事に見せるな、ただし、代わりにここでREFRESH系列とリターンを出てください。
o Execute the following for each RSB for this session whose
OI differs from In_If and whose Filter_spec_list has at
least one filter spec in common with the FILTER_SPEC* in
the RERR message. For WF style, empty FILTER_SPEC*
structures are assumed to match.
o OIがIn_Ifと異なっていて、Filter_仕様_リストが少なくとも1つのフィルタ仕様を持っているこのセッションのための各RSBのためにRERRメッセージのFILTER_SPEC*と共用して以下を実行してください。 WFスタイルにおいて、空のFILTER_SPEC*構造が合っていると思われます。
1. If Error_Code = 01 and the InPlace flag in the
ERROR_SPEC is 1 and one or more of the BSB's
found/created above has a Qb that is strictly greater
than Flowspec in the RSB, then continue with the next
matching RSB, if any.
1. Error_Codeが01と等しく、ERROR_SPECのInPlace旗が1と1であるか一層のBSBが、上に作成された/がRSBでは、Flowspecより厳密にすばらしいQbを持っているのがわかったなら、もしあれば次の合っているRSBを続行してください。
2. If NHOP in the RSB is the local API, then:
2. 次に、RSBのNHOPが地方のAPIであるなら:
- If the FLOWSPEC in the RERR message is strictly
greater than the RSB Flowspec, then turn on the
NotGuilty flag in the ERROR_SPEC.
- RERRメッセージのFLOWSPECがRSB Flowspecより厳密に大きいなら、ERROR_SPECのNotGuilty旗をつけてください。
- Deliver an error upcall to application:
- 誤りupcallをアプリケーションに届けてください:
Call: <Upcall_Proc>( session-id, RESV_ERROR,
Error_code, Error_value,
Node_Addr, Error_flags,
Flowspec, Filter_Spec_List
[ , Policy_data] )
以下に電話をしてください。 <Upcall_Proc>。(_セッションイド、RESV_ERROR、Error_コード、Error_価値、Node_Addr、Flowspec、Error_は弛んで、Filter_SpecはList[Policy_データ]です)
and continue with the next RSB.
そして、次のRSBを続行してください。
3. If the style has wildcard sender selection, use the
SCOPE object SC.In from the RERR message to construct
a SCOPE object SC.Out to be forwarded. SC.Out should
contain those sender addresses that appeared in SC.In
and that route to OI, as determined by scanning the
PSB's. If SC.Out is empty, continue with the next
RSB.
3. スタイルにワイルドカード送付者選択があるなら、進めるためにSCOPE物のSC.Outを組み立てるRERRメッセージからSCOPE物のSC.Inを使用してください。 SC.OutはSC.Inに現れたそれらの送付者アドレスとそのルートをOIに含むはずです、PSBをスキャンすることによって決定するように。 SC.Outが空であるなら、次のRSBを続行してください。
4. Create a new RERR message containing the error flow
descriptor and send to the NHOP address specified by
the RSB. Include SC.Out if the style has wildcard
sender selection.
4. 誤り流れ記述子を含む新しいRERRメッセージを作成してください、そして、RSBによって指定されたNHOPアドレスに発信してください。 スタイルにワイルドカード送付者選択があるなら、SC.Outを含めてください。
Braden & Zhang Informational [Page 15] RFC 2209 RSVP-Message Processing September 1997
[15ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
5. Continue with the next RSB.
5. 次のRSBを続行してください。
o Drop the RERR message and return.
o RERRメッセージとリターンを落としてください。
RESV CONFIRM ARRIVES
到着しますRESVが、確認する。
o If the (unicast) IP address found in the RESV_CONFIRM
object in the RACK message matches an interface of the
node, a confirmation upcall is made to the matching
application:
o RACKメッセージのRESV_CONFIRM物で見つけられた(ユニキャスト)IPアドレスがノードのインタフェースに合っているなら、確認upcallを合っているアプリケーションにします:
Call: <Upcall_Proc>( session-id, RESV_CONFIRM,
Error_code, Error_value, Node_Addr,
LUB-Used, nlist, Flowspec,
Filter_Spec_List, NULL, NULL )
以下に電話をしてください。 <Upcall_Proc>。(セッションイド、CONFIRM(Error_コード、Error_価値、Node_Addr)がLUB使用したRESV_、nlist、Flowspec、Filter_Spec_List、NULL、NULL)
o Otherwise, forward the RACK message to the IP address in
its RESV_CONFIRM object.
o さもなければ、RESV_CONFIRM物のIPアドレスにRACKメッセージを転送してください。
Drop the RACK message and return.
RACKメッセージとリターンを落としてください。
UPDATE TRAFFIC CONTROL
アップデートトラフィックコントロール
The sequence is invoked by many of the message arrival sequences
to set or adjust the local traffic control state in accordance
with the current reservation and path state. An implicit
parameter of this sequence is the `active' RSB.
現在の予約と経路州に応じて、地方のトラフィックコントロール状態を系列はメッセージ到着順の多くによって呼び出されて、設定するか、または調整します。 この系列の暗黙のパラメタは'アクティブな'RSBです。
If the result is to modify the traffic control state, this
sequence notifies any matching local applications with a
RESV_EVENT upcall. If the state change is such that it should
trigger immediate RESV refresh messages, it also turns on the
Resv_Refresh_Needed flag.
結果がトラフィックコントロール状態を変更することであるなら、この系列はRESV_EVENT upcallとのどんな合っている局所塗布にも通知します。 州の変化がそれが引き金となるべきであるそのようなものであるなら、即座のRESVはメッセージをリフレッシュします、また、それが_必要な旗をResv_Refreshに変えます。
o Compute the traffic control parameters using the following
steps.
o 以下のステップを使用して、トラフィックコントロールパラメタを計算してください。
1. Initially the local flag Is_Biggest is off.
1. 初めは、地方の旗のIs_Biggestはオフです。
2. Consider the set of RSB's matching SESSION and OI from
the active RSB. If the style of the active RSB is
distinct, then the Filter_spec_list must also be
matched.
2. アクティブなRSBからRSBの合っているSESSIONとOIのセットを考えてください。 また、アクティブなRSBのスタイルが異なるなら、Filter_仕様_リストを合わせなければなりません。
- Compute the effective kernel flowspec,
TC_Flowspec, as the LUB of the FLOWSPEC values in
these RSB's.
- FLOWSPEC値のLUBとしてRSBのこれらのところで有効なカーネルflowspec、TC_Flowspecを計算してください。
Braden & Zhang Informational [Page 16] RFC 2209 RSVP-Message Processing September 1997
[16ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
- Compute the effective traffic control filter spec
(list) TC_Filter_Spec* as the union of the
Filter_spec_lists from these RSB's.
- Filter_仕様_の組合がRSBのこれらのものから記載するように有効なトラフィックコントロールの仕様(リスト)TC_Filter_Specフィルタ*を計算してください。
- If the active RSB has a FLOWSPEC larger than all
the others, turn on the Is_Biggest flag.
- アクティブなRSBがFLOWSPECをすべての他のものより大きくするなら、Is_Biggest旗をつけてください。
3. Scan all RSB's matching session and Filtss, for all
OI. Set TC_B_Police_flag on if TC_Flowspec is smaller
than, or incomparable to, any FLOWSPEC in those RSB's.
3. すべてのOIのためにすべてのRSBの合っているセッションとFiltssをスキャンしてください。 TC_Flowspecが、より小さいなら警察の_が弛むTC_B_を設定してください、比較にならないほど、RSBのそれらのところのどんなFLOWSPEC。
4. Locate the set of PSBs (senders) whose
SENDER_TEMPLATEs match Filter_spec_list in the active
RSB and whose OutInterface_list includes OI.
4. SENDER_TEMPLATEsがアクティブなRSBのFilter_仕様_リストに合っていて、OutInterface_リストがOIを含んでいるPSBs(送付者)のセットの場所を見つけてください。
5. Set TC_E_Police_flag on if any of these PSBs have
their E_Police flag on. Set TC_M_Police_flag on if it
is a shared style and there is more than one PSB in
the set.
5. これらのPSBsのどれかが彼らのE_警察の旗をオンに持っているなら、警察の_が弛むTC_E_を設定してください。 それが共有されたスタイルであり、セットに1PSBがあれば、M_警察の_が弛むTC_を設定してください。
6. Compute Path_Te as the sum of the SENDER_TSPEC objects
in this set of PSBs.
6. SENDER_TSPECの合計がPSBsのこのセットで反対するようにPath_Teを計算してください。
o Search for a TCSB matching SESSION and OI; for distinct
style (FF), it must also match Filter_spec_list.
o TCSBの合っているSESSIONとOIを捜し求めてください。 また、異なったスタイル(FF)のために、それはFilter_仕様_リストに合わなければなりません。
If none is found, create a new TCSB.
なにも見つけられないなら、新しいTCSBを作成してください。
o If TCSB is new:
o TCSBが新しいなら:
1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the
police flags into TCSB.
1. TC_Flowspec、TC_Filter_Spec*、Path_Te、および警察の旗をTCSBに収納してください。
2. Turn the Resv_Refresh_Needed flag on and make the
traffic control call:
2. _が旗を必要としたResv_Refreshをターンしてください、そして、トラフィックコントロールを呼ばせてください:
TC_AddFlowspec( OI, TC_Flowspec,
Path_Te, police_flags)
-> Rhandle, Fwd_Flowspec
TC_AddFlowspec(OI、TC_Flowspec、Path_Teは_旗を取り締まる)->Rhandle、Fwd_Flowspec
3. If this call fails, build and send a RERR message
specifying "Admission control failed" and with the
InPlace flag off. Delete the TCSB, delete any
RESV_CONFIRM object from the active RSB, and return.
3. この呼び出しが失敗するなら、建ててください、そして、「入場コントロールは失敗し」てInPlace旗がオフな状態でRERRメッセージを指定させてください。 TCSBを削除してください、そして、アクティブなRSBからあらゆるRESV_CONFIRM物を削除してください、そして、戻ってください。
Braden & Zhang Informational [Page 17] RFC 2209 RSVP-Message Processing September 1997
[17ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
4. Otherwise (call succeeds), record Rhandle and
Fwd_Flowspec in the TCSB. For each filter_spec F in
TC_Filter_Spec*, call:
4. さもなければ(呼び出しは成功する)、RhandleとFwd_FlowspecをTCSBに記録してください。 TC_Filter_Spec*の各フィルタ_仕様Fに関しては、電話をしてください:
TC_AddFilter( OI, Rhandle, Session, F)
-> Fhandle
Tc_AddFilter(OI、Rhandle、セッション、F)->Fhandle
and record the returned Fhandle in the TCSB.
そして、返されたFhandleをTCSBに記録してください。
o Otherwise, if TCSB is not new but no effective kernel
flowspec TC_Flowspec was computed earlier, then:
o さもなければ、次に、TCSBが新しくないか、しかし、有効なカーネルがないflowspec TC_Flowspecは、より早く計算されました:
1. Turn on the Resv_Refresh_Needed flag.
1. Resv_Refresh_における回転は旗を必要としました。
2. Call traffic control to delete the reservation:
2. トラフィックコントロールに電話をして、予約を削除してください:
TC_DelFlowspec( OI, Rhandle )
Tc_DelFlowspec(OI、Rhandle)
3. Delete the TCSB and return.
3. TCSBとリターンを削除してください。
o Otherwise, if TCSB is not new but the TC_Flowspec, Path_Te,
and/or police flags just computed differ from corresponding
values in the TCSB, then:
o さもなければ、TCSBが新しくないか、しかし、TC_Flowspec、Path_Te、そして/または、ただ計算された警察の旗はTCSBで換算値と異なっています、そして:
1. If the TC_Flowspec and/or Path_Te values differ, turn
the Resv_Refresh_Needed flag on.
1. TC_Flowspec、そして/または、Path_Te値が異なるなら、_が旗を必要としたResv_Refreshをターンしてください。
2. Call traffic control to modify the reservation:
2. トラフィックコントロールに電話をして、予約を変更してください:
TC_ModFlowspec( OI, Rhandle, TC_Flowspec,
Path_Te, police_flags )
-> Fwd_Flowspec
TC_ModFlowspec(OI(Rhandle、TC_Flowspec、Path_Te)は_旗を取り締まる)->Fwd_Flowspec
3. If this call fails, build and send a RERR message
specifying "Admission control failed" and with the
InPlace bit on. Delete any RESV_CONFIRM object from
the active RSB and return.
3. この呼び出しが失敗するなら、建ててください、そして、「入場コントロールは失敗し」てInPlaceビットがオンな状態でRERRメッセージを指定させてください。 アクティブなRSBとリターンからあらゆるRESV_CONFIRM物を削除してください。
4. Otherwise (the call succeeds), update the TCSB with
the new values and save Fwd_Flowspec in the TCSB.
4. さもなければ(呼び出しは成功する)、新しい値でTCSBをアップデートしてください、そして、TCSBにFwd_Flowspecを取っておいてください。
o If the TCSB is not new but the TC_Filter_Spec* just
computed differs from the FILTER_SPEC* in the TCSB, then:
o 次に、TCSBが新しくないか、しかし、ただ計算されたTC_Filter_Spec*はTCSBでFILTER_SPEC*と異なっています:
1. Make an appropriate set of TC_DelFilter and
TC_AddFilter calls to transform the Filter_spec_list
in the TCSB into the new TC_Filter_Spec*.
1. TC_の適切なセットをDelFilterにしてください。そうすれば、TC_AddFilterは、TCSBのFilter_仕様_リストを新しいTC_Filter_Spec*に変えるために呼びます。
Braden & Zhang Informational [Page 18] RFC 2209 RSVP-Message Processing September 1997
[18ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
2. Turn on the Resv_Refresh_Needed flag.
2. Resv_Refresh_における回転は旗を必要としました。
o If the active RSB contains a RESV_CONFIRM object, then:
o 次に、アクティブなRSBがRESV_CONFIRM物を含んでいるなら:
1. If the Is_Biggest flag is on, move the RESV_CONFIRM
object into the TCSB and turn on the
Resv_Refresh_Needed flag. (This will later cause the
RESV REFRESH sequence to be invoked, which will either
forward or return the RESV_CONFIRM object, deleting it
from the TCSB in either case).
1. Is_Biggest旗がオンであるなら、RESV_CONFIRMがResv_Refresh_におけるTCSBと回転に反対させる移動は旗を必要としました。 (後でこれでRESV REFRESH系列を呼び出すでしょう(RESV_CONFIRM物を進めるか、または返すでしょう)、TCSBからどちらの場合でもそれを削除して。)
2. Otherwise, create and send a RACK message to the
address in the RESV_CONFIRM object. Include the
RESV_CONFIRM object in the RACK message. The RACK
message should also include an ERROR_SPEC object whose
Error_Node parameter is IP address of OI from the TCSB
and that specifies "No Error".
2. さもなければ、RESV_CONFIRM物のアドレスにRACKメッセージを作成して、送ってください。 RACKメッセージでRESV_CONFIRM物を含めてください。 また、RACKメッセージはError_NodeパラメタがTCSBからのOIのIPアドレスであり、「誤りがありません」を指定するERROR_SPEC物を含むべきです。
o If the Resv_Refresh_Needed flag is on and the RSB is not
from the API, make a RESV_EVENT upcall to any matching
application:
o _の必要な旗があるResv_RefreshとRSBがAPIから来ていないなら、RESV_EVENT upcallをあらゆる合っているアプリケーションにしてください:
Call: <Upcall_Proc>( session-id, RESV_EVENT,
style, Flowspec, Filter_spec_list [ ,
POLICY_DATA] )
以下に電話をしてください。 <Upcall_Proc>。(セッションイド、RESV_EVENT、スタイル、Flowspec、Filter_仕様_リスト[POLICY_DATA])
where Flowspec and Filter_spec_list come from the TCSB and
the style comes from the active RSB.
FlowspecとFilter_仕様_リストがTCSBからどこに来るか、そして、スタイルはアクティブなRSBから来ます。
o Return to the event sequence that invoked this one.
o これを呼び出したイベント系列に戻ってください。
PATH REFRESH
経路はリフレッシュします。
This sequence sends a path refresh for a particular sender,
i.e., a PSB. This sequence may be entered by either the
expiration of a refresh timer or directly as the result of the
Path_Refresh_Needed flag being turned on during the processing
of a received PATH message.
系列が経路を送るこれはすなわち、特定の送付者、PSBのためにリフレッシュします。 この系列はaの満了が受信されたPATHメッセージの処理の間にタイマをリフレッシュしたか、または直接Path_Refresh_の結果として回される旗を必要としたどちらかによって入れられるかもしれません。
o Insert TIME_VALUES object into the PATH message being
built. Compute the IP TTL for the PATH message as one less
than the TTL value received in the message. However, if
the result is zero, return without sending the PATH
message.
o VALUESが築き上げられるPATHメッセージに反対させるタイム誌_を挿入してください。 TTL値より少ない1つがメッセージで受信されたので、PATHメッセージのためにIP TTLを計算してください。 しかしながら、結果がゼロであるなら、PATHメッセージを送らないで、戻ってください。
o Create a sender descriptor containing the SENDER_TEMPLATE,
SENDER_TSPEC, and POLICY_DATA objects, if present in the
PSB, and pack it into the PATH message being built.
o PSBに存在しているならSENDER_TEMPLATE、SENDER_TSPEC、およびPOLICY_DATA物を含む送付者記述子を作成してください、そして、築き上げられるPATHメッセージにそれに詰め込んでください。
Braden & Zhang Informational [Page 19] RFC 2209 RSVP-Message Processing September 1997
[19ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
o Send a copy of the PATH message to each interface OI in
OutInterface_list. Before sending each copy:
o OutInterface_リストのそれぞれのインタフェースOIにPATHメッセージのコピーを送ってください。 それぞれを送る前に、コピーしてください:
1. If the PSB has the E_Police flag on and if interface
OI is not capable of policing, turn the E_Police flag
on in the PATH message being built.
1. PSBがE_警察の旗をオンに持って、インタフェースOIが取り締まることができないなら、築き上げられるPATHメッセージでE_警察の旗をつけてください。
2. Pass the ADSPEC object and Non_RSVP flag present in
the PSB to the traffic control call TC_Advertise.
Insert the modified ADSPEC object that is returned
into the PATH message being built.
2. ADSPEC物を渡してください。そうすれば、PSBのトラフィックコントロールへの現在のNon_RSVP旗は、TCに_広告と呼びます。 築き上げられるPATHメッセージに返される変更されたADSPEC物を挿入してください。
3. Insert into its PHOP object the interface address and
the LIH for the interface.
3. インタフェースのためにインターフェース・アドレスとLIHをPHOP物に挿入してください。
RESV REFRESH
RESVはリフレッシュします。
This sequence sends a reservation refresh towards a particular
previous hop with IP address PH. This sequence may be entered
by the expiration of a refresh timer, or invoked from the PATH
MESSAGE ARRIVES, RESV MESSAGE ARRIVES, RTEAR MESSAGE ARRIVES, or
RERR MESSAGE ARRIVES sequence.
系列が予約を送るこれはIPアドレスPHと共に前の特定のホップに向かってリフレッシュします。 この系列はPATH MESSAGE ARRIVES、RESV MESSAGE ARRIVES、RTEAR MESSAGE ARRIVES、またはRERR MESSAGE ARRIVES系列からタイマをリフレッシュするか、または呼び出されたaの満了で入れられるかもしれません。
In general, this sequence considers each of the PSB's with PHOP
address PH. For a given PSB, it scans the TCSBs for matching
reservations and merges the styles, FLOWSPECs and
Filter_spec_list's appropriately. It then builds a RESV message
and sends it to PH. The details depend upon the attributes of
the style(s) included in the reservations.
一般に、この系列はPHOPアドレスPHがあるそれぞれのPSBのものを考えます。 与えられたPSBに関しては、それは、適切に合っている予約のためにTCSBsをスキャンして、スタイル、FLOWSPECs、および_リストのFilter_仕様ものを合併します。 それは、次に、RESVメッセージを築き上げて、それをPHに送ります。 詳細は予約にスタイルを含む属性に依存します。
Initially the Need_Scope flag is off and the new_SCOPE object is
empty.
初めは、Scope旗がある_とSCOPEが空であることを反対させる新しい_はそうしなければなりません。
o Create an output message containing INTEGRITY (if
configured), SESSION, RSVP_HOP, and TIME_VALUES objects.
o INTEGRITY(構成されるなら)、SESSION、RSVP_HOP、およびタイム誌_VALUES物を含む出力メッセージを作成してください。
o Determine the style for these reservations from the first
RSB for the session, and move the STYLE object into the
proto-message. (Note that the present set of styles are
never themselves merged; if future styles can be merged,
these rules will become more complex).
o 最初のRSBからのセッションのこれらの予約のためにスタイルを決定してください、そして、様式物体をproto-メッセージに動かしてください。 (現在のスタイルが決して自分たちでそうでないというメモは合併しました; 将来のスタイルを合併できると、これらの規則は、より複雑になるでしょう。)
o If style is wildcard and if there are PSB's from more than
one PHOP and if the multicast routing protocol does not use
shared trees, set the Need_Scope flag on.
o スタイルがワイルドカードであり、1PHOPからのPSBのものがあって、マルチキャストルーティング・プロトコルが共有された木を使用しないなら、セットしてください、Scopeが弛む_はそうしなければなりません。
Braden & Zhang Informational [Page 20] RFC 2209 RSVP-Message Processing September 1997
[20ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
o Select each sender PSB whose PHOP has address PH. Set the
local flag B_Merge off and execute the following steps.
o PHOPにはアドレスPHがあるそれぞれの送付者PSBを選択してください。 地方の旗のB_Mergeを始めてください、そして、以下のステップを実行してください。
1. Select all TCSB's whose Filter_spec_list's match the
SENDER_TEMPLATE object in the PSB and whose OI appears
in the OutInterface_list of the PSB.
1. リストのFilter_仕様_ものがPSBのSENDER_TEMPLATE物に合っているTCSBのものとだれのすべてのOIがPSBのOutInterface_リストに現れるかを選択してください。
2. If the PSB is from the API, then:
2. 次に、PSBがAPIから来ているなら:
- If TCSB contains a CONFIRM object, then create
and send a RACK message containing the object and
delete the CONFIRM object from the TCSB.
- TCSBがCONFIRM物を含むなら、物を含むRACKメッセージを、作成して、送ってください、そして、TCSBからCONFIRM物を削除してください。
- Continue with next PSB.
- 次のPSBを続行してください。
3. If B_Merge flag is off then ignore a blockaded TCSB,
as follows.
3. Mergeが旗を揚げさせるB_がオフであるなら、以下の封鎖されたTCSBを無視してください。
- Select BSB's that match this TCSB. If a selected
BSB is expired, delete it. If any of the
unexpired BSB's has a Qb that is not strictly
larger than TC_Flowspec, then continue processing
with the next TCSB.
- このTCSBに合っているBSBのものを選択してください。 選択されたBSBが満期であるなら、それを削除してください。 満期になっていないBSBのもののどれかにTC_Flowspecより厳密に大きくないQbがあるなら、次のTCSBと共に処理し続けてください。
However, if steps 1 and 2 result in finding that all
TCSB's matching this PSB are blockaded, then:
しかしながら、ステップであるなら、次に、すべてのTCSBがこのPSBに合っているのがわかる際に1と2結果は封鎖されます:
- If this RESV REFRESH sequence was invoked from
RESV ERROR RECEIVED, then return to the latter.
- このRESV REFRESH系列がRESV ERROR RECEIVEDから呼び出されたなら、後者に戻ってください。
- Otherwise, turn on the B_Merge flag and restart
at step 1, immediately above.
- すぐに上でさもなければ、B_Merge旗をつけてください、そして、ステップ1で再開してください。
4. Merge the flowspecs from this set of TCSB's, as
follows:
4. 以下の通りTCSBのこのセットからflowspecsを合併してください:
- If B_Merge flag is off, compute the LUB over the
flowspec objects. From each TCSB, use the
Fwd_Flowspec object if present, else use the
normal Flowspec object.
- Mergeが旗を揚げさせるB_がオフであるなら、flowspec物の上にLUBを計算してください。 現在であってほかなら、各TCSB、使用からのFwd_Flowspec物は正常なFlowspec物を使用します。
Braden & Zhang Informational [Page 21] RFC 2209 RSVP-Message Processing September 1997
[21ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
While computing the LUB, check for a RESV_CONFIRM
object in each TCSB. If a RESV_CONFIRM object is
found:
LUBを計算している間、各TCSBのRESV_CONFIRM物がないかどうかチェックしてください。 RESV_CONFIRM物が見つけられるなら:
- If the flowspec (Fwd_Flowspec or Flowspec)
in that TCSB is larger than all other (non-
blockaded) flowspecs being compared, then
save this RESV_CONFIRM object for forwarding
and delete from the TCSB.
- TCSBが比較される他のすべての(非封鎖される)のflowspecsより大きいそして、推進のためのこのRESV_CONFIRM物を除いて、flowspecして(Fwd_FlowspecかFlowspec)、TCSBから削除します。
- Otherwise (the corresponding flowspec is not
the largest), create and send a RACK message
to the address in the RESV_CONFIRM object.
Include the RESV_CONFIRM object in the RACK
message. The RACK message should also
include an ERROR_SPEC object whose
Error_Node parameter is IP address of OI
from the TCSB and specifying "No Error".
- さもなければ(対応するflowspecは最も大きくない)、RESV_CONFIRM物のアドレスにRACKメッセージを作成して、送ってください。 RACKメッセージでRESV_CONFIRM物を含めてください。 また、RACKメッセージはError_NodeパラメタがTCSBと「誤りがありません」を指定するのからのOIのIPアドレスであるERROR_SPEC物を含むべきです。
- Delete the RESV_CONFIRM object from the
TCSB.
- TCSBからRESV_CONFIRM物を削除してください。
- Otherwise (B_Merge flag is on), compute the GLB
over the Flowspec objects of this set of TCSB's.
- さもなければ(Mergeが旗を揚げさせるB_はオンである)、TCSBのこのセットのFlowspec物の上にGLBを計算してください。
While computing the GLB, delete any RESV_CONFIRM
object object in any of these TCSB's.
GLBを計算している間、これらのTCSBのどれかのあらゆるRESV_CONFIRM物の物を削除してください。
5. (All matching TCSB's have been processed). The next
step depends upon the style attributes.
5. (合っているTCSBのすべてのものを処理してあります。) 次のステップはスタイル属性に依存します。
Distinct reservation (FF) style
異なった条件(FF)スタイル
Use the Sender_Template as the merged
FILTER_SPEC. Pack the merged (FLOWSPEC,
FILTER_SPEC, F_POLICY_DATA) triplet into the
message as a flow descriptor.
合併しているFILTER_SPECとしてSender_Templateを使用してください。 流れ記述子として合併している(_FLOWSPEC、FILTER_SPEC、F POLICY_DATA)三つ子をメッセージに梱包してください。
Shared wildcard reservation (WF) style
共有されたワイルドカード条件(WF)スタイル
There is no merged FILTER_SPEC. Merge (compute
the LUB of) the merged FLOWSPECS from the TCSB's,
across all PSB's for PH.
FILTER_SPECは合併されていません。 マージ、(LUBを計算する、)、PHのためのPSBのすべてのところの向こう側のTCSBのものからの合併しているFLOWSPECS。
Braden & Zhang Informational [Page 22] RFC 2209 RSVP-Message Processing September 1997
[22ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
Shared distinct reservation (SE) style
共有された異なった条件(SE)スタイル
Using the Sender_Template as the merged
FILTER_SPEC, form the union of the FILTER_SPECS
obtained from the TCSB's. Merge (compute the LUB
of) the merged FLOWSPECS from the TCSB's, across
all PSB's for PH.
合併しているFILTER_SPECとしてSender_Templateを使用して、TCSBのものから入手されたFILTER_SPECSの組合を形成してください。 マージ、(LUBを計算する、)、PHのためのPSBのすべてのところの向こう側のTCSBのものからの合併しているFLOWSPECS。
6. If the Need_Scope flag is on and the sender specified
by the PSB is not the local API:
6. Scopeが旗を揚げさせる_はオンです、そして、PSBによって指定された送付者は地方のAPIではありません:でなければならない
- Find each RSB that matches this PSB, i.e., whose
Filter_spec_list matches Sender_Template in the
PSB and whose OI is included in
OutInterface_list.
- このPSBを合わせて、すなわち、Filter_仕様_リストがPSBでSender_Templateに合っていて、OIがOutInterface_リストに含まれている各RSBを見つけてください。
- If the RSB either has no SCOPE list or its SCOPE
list includes the sender IP address from the PSB,
insert the sender IP address into new_SCOPE.
- RSBにはSCOPEリストが全くないか、またはSCOPEリストがPSBからの送付者IPアドレスを含んでいるなら、送付者IPアドレスを新しい_SCOPEに挿入してください。
o (All PSB's for PH have been processed). Finish the RESV
message.
o (PHのためのすべてのPSBが処理されました。) RESVメッセージを終えてください。
1. If Need_Scope flag is on but new_SCOPE is empty, no
RESV message should be sent; return. Otherwise, if
Need_Scope is on, move new_SCOPE into the message.
1. 新しい_SCOPEが空である、Scopeが旗を揚げさせる_はオンですが、RESVメッセージを全く送るべきではありません;でなければならない 戻ってください。 そうでなければ、_Scopeはオンであり、新しい_SCOPEをメッセージに動かさなければなりませんか?
2. If a shared reservation style is being built, move the
final merged FLOWSPEC object and filter spec list into
the message.
2. 共有された予約スタイルが築き上げられているなら、最終的な合併しているFLOWSPEC物体とフィルタ仕様リストをメッセージに動かしてください。
3. If a RESV_CONFIRM object was saved earlier, move it
into the new RESV message.
3. RESV_CONFIRM物が、より早く保存されたなら、それを新しいRESVメッセージに動かしてください。
4. Set the RSVP_HOP object in the message to contain the
IncInterface address through which it will be sent and
the LIH from (one of) the PSB's.
4. それが送られるIncInterfaceアドレスとLIHを含むメッセージにRSVP_HOP物をはめ込んでください、(1つ、)、PSBのもの
o Send the message to the address PH.
o アドレスPHにメッセージを送ってください。
ROUTE CHANGE NOTIFICATION
ルート変更届出書
This sequence is triggered when routing sends a route change
notification to RSVP.
ルーティングがルート変更届出書をRSVPに送ると、この系列は引き起こされます。
o Each PSB is located whose SESSION matches the destination
address and whose SENDER_TEMPLATE matches the source
address (for multicast).
o SESSIONが送付先アドレスに合っていて、SENDER_TEMPLATEがソースアドレスに合っている各PSBは見つけられています(マルチキャストのために)。
Braden & Zhang Informational [Page 23] RFC 2209 RSVP-Message Processing September 1997
[23ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
1. If the OutInterface_list from the notification differs
from that in the PSB, execute the PATH LOCAL REPAIR
sequence.
1. 通知からのOutInterface_リストがPSBでそれと異なっているなら、PATH LOCAL REPAIR系列を実行してください。
2. If the IncInterface from the notification differs from
that in the PSB, update the PSB.
2. 通知からのIncInterfaceがPSBでそれと異なっているなら、PSBをアップデートしてください。
PATH LOCAL REPAIR
経路局部的修繕
The sequence is entered to effect local repair after a route
change for a given PSB.
系列は、与えられたPSBのためのルート変化の後に局部的修繕に作用するように入れられます。
o Wait for a delay time of W seconds.
o W秒の遅延時間の間、待ってください。
o Execute the PATH REFRESH event sequence (above) for the
PSB.
o PSBのためにPATH REFRESHイベント系列(above)を実行してください。
References
参照
[Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in
Progress.
[Baker96] ベイカー、F.、「RSVPの暗号の認証」が進行中で働いています。
[RFC 2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
FunctionalSpecification", RFC 2205, September 1997.
[RFC2205] ブレーデン、R.(エド)、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1FunctionalSpecification」、RFC2205、1997年9月。
[RFC 2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
IPv4 Data Flows", RFC 2207, September 1997.
[RFC2207] バーガーとL.とT.オマリー、「IPSEC IPv4データフローのためのRSVP拡張子」、RFC2207、1997年9月。
[RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.
Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE
Network, September 1993.
[RSVP93] チャン、L.、デアリング、S.、Estrin、D.、Shenker、S.、およびD.Zappala、「RSVP:」 IEEEは、1993年9月に「新しい資源予約プロトコル」とネットワークでつなぎます。
Security Considerations
セキュリティ問題
Processing the RSVP INTEGRITY object [Baker96] is only mentioned in this memo, because the processing rules are described here only in general terms. The RSVP support for IPSEC [RFC 2207] will imply modifications that have not yet been incorporated into these processing rules.
RSVP INTEGRITY物[Baker96]を処理するのがこのメモで言及されるだけであり、処理規則がここで一般にだけ説明されるので、用語IPSEC[RFC2207]のRSVPサポートはこれらの処理規則にまだ法人組織でない変更を含意するでしょう。
Braden & Zhang Informational [Page 24] RFC 2209 RSVP-Message Processing September 1997
[24ページ]RFC2209RSVP-メッセージ処理1997年9月の情報のブレーデンとチャン
Authors' Addresses
作者のアドレス
Bob Braden USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ボブブレーデンUSC情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: (310) 822-1511 EMail: Braden@ISI.EDU
以下に電話をしてください。 (310) 822-1511 メールしてください: Braden@ISI.EDU
Lixia Zhang UCLA Computer Science Department 4531G Boelter Hall Los Angeles, CA 90095-1596 USA
LixiaチャンUCLAコンピュータ理学部4531G Boelter Hallロサンゼルス、カリフォルニア90095-1596米国
Phone: 310-825-2695 EMail: lixia@cs.ucla.edu
以下に電話をしてください。 310-825-2695 メールしてください: lixia@cs.ucla.edu
Braden & Zhang Informational [Page 25]
ブレーデンとチャンInformationalです。[25ページ]
一覧
スポンサーリンク
