[要約] RFC 2622は、ルーティングポリシーの仕様言語（RPSL）に関する規格です。このRFCの目的は、インターネットルーティングポリシーの表現と共有を容易にすることです。
Network Working Group C. Alaettinoglu
Request for Comments: 2622 USC/Information Sciences Institute
Obsoletes: 2280 C. Villamizar
Category: Standards Track Avici Systems
E. Gerich
At Home Network
D. Kessens
Qwest Communications
D. Meyer
University of Oregon
T. Bates
Cisco Systems
D. Karrenberg
RIPE NCC
M. Terpstra
Bay Networks
June 1999
Routing Policy Specification Language (RPSL)
ルーティングポリシー仕様言語（RPSL）
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time.
RPSLを使用すると、ネットワークオペレーターは、インターネット階層のさまざまなレベルでルーティングポリシーを指定できます。たとえば、自律システム（AS）レベルで。同時に、ポリシーをRPSLに十分な詳細で指定できるため、低レベルのルーター構成をそれらから生成できます。RPSLは拡張可能です。新しいルーティングプロトコルと新しいプロトコル機能をいつでも紹介できます。
Table of Contents
目次
1 Introduction 3
2 RPSL Names, Reserved Words, and Representation 4
3 Contact Information 7
3.1 mntner Class . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 person Class . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 role Class . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 route Class 12
5 Set Classes 13
5.1 as-set Class . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 route-set Class. . . . . . . . . . . . . . . . . . . . . . . 15
5.3 Predefined Set Objects . . . . . . . . . . . . . . . . . . . 17
5.4 Filters and filter-set Class . . . . . . . . . . . . . . . . 17
5.5 rtr-set Class. . . . . . . . . . . . . . . . . . . . . . . . 22
5.6 Peerings and peering-set Class . . . . . . . . . . . . . . . 24
6 aut-num Class 27
6.1 import Attribute: Import Policy Specification . . . . . . . 27
6.1.1 Action Specification . . . . . . . . . . . . . . . . . . 28
6.2 export Attribute: Export Policy Specification . . . . . . . 29
6.3 Other Routing Protocols, Multi-Protocol Routing Protocols,
and Injecting Routes Between Protocols . . . . . . . . . . . . 29
6.4 Ambiguity Resolution . . . . . . . . . . . . . . . . . . . . 31
6.5 default Attribute: Default Policy Specification . . . . . . 33
6.6 Structured Policy Specification. . . . . . . . . . . . . . . 33
7 dictionary Class 37
7.1 Initial RPSL Dictionary and Example Policy Actions and
Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8 Advanced route Class 45
8.1 Specifying Aggregate Routes. . . . . . . . . . . . . . . . . 45
8.1.1Interaction with policies in aut-num class. . . . . . . . 49
8.1.2Ambiguity resolution with overlapping aggregates. . . . . 50
8.2 Specifying Static Routes . . . . . . . . . . . . . . . . . . 52
9 inet-rtr Class 52
10 Extending RPSL 54
10.1 Extensions by changing the dictionary class . . . . . . . . 54
10.2 Extensions by adding new attributes to existing classes . . 55
10.3 Extensions by adding new classes . . . . . . . . . . . . . 55
10.4 Extensions by changing the syntax of existing RPSL
attributes. . . . . . . . . . . . . . . . . . . . . . . . . . 55
11 Security Considerations 56
12 Acknowledgements 56
References 56
A Routing Registry Sites 59
B Grammar Rules 59
C Changes from RFC 2280 67
D Authors' Addresses 68
Full Copyright Statement 69
1 Introduction
1はじめに
This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time.
このメモは、ルーティングポリシー仕様言語（RPSL）の参照ドキュメントです。RPSLを使用すると、ネットワークオペレーターは、インターネット階層のさまざまなレベルでルーティングポリシーを指定できます。たとえば、自律システム（AS）レベルで。同時に、ポリシーをRPSLに十分な詳細で指定できるため、低レベルのルーター構成をそれらから生成できます。RPSLは拡張可能です。新しいルーティングプロトコルと新しいプロトコル機能をいつでも紹介できます。
RPSL is a replacement for the current Internet policy specification language known as RIPE-181 [6] or RFC-1786 [7]. RIPE-81 [8] was the first language deployed in the Internet for specifying routing policies. It was later replaced by RIPE-181 [6]. Through operational use of RIPE-181 it has become apparent that certain policies cannot be specified and a need for an enhanced and more generalized language is needed. RPSL addresses RIPE-181's limitations.
RPSLは、Ripe-181 [6]またはRFC-1786 [7]として知られる現在のインターネットポリシー仕様言語の代替品です。Ripe-81 [8]は、ルーティングポリシーを指定するためにインターネットに展開された第一言語でした。後に熟した181 [6]に置き換えられました。Ripe-181の運用上の使用を通じて、特定のポリシーを指定できず、強化され、より一般化された言語の必要性が必要であることが明らかになりました。RPSLは、Ripe-181の制限に対処します。
RPSL was designed so that a view of the global routing policy can be contained in a single cooperatively maintained distributed database to improve the integrity of Internet's routing. RPSL is not designed to be a router configuration language. RPSL is designed so that router configurations can be generated from the description of the policy for one autonomous system (aut-num class) combined with the description of a router (inet-rtr class), mainly providing router ID, autonomous system number of the router, interfaces and peers of the router, and combined with a global database mappings from AS sets to ASes (as-set class), and from origin ASes and route sets to route prefixes (route and route-set classes). The accurate population of the RPSL database can help contribute toward such goals as router configurations that protect against accidental (or malicious) distribution of inaccurate routing information, verification of Internet's routing, and aggregation boundaries beyond a single AS.
RPSLは、インターネットのルーティングの完全性を改善するために、グローバルルーティングポリシーのビューを単一の協力的にメンテナンスした分散データベースに含めることができるように設計されました。RPSLは、ルーター構成言語になるようには設計されていません。RPSLは、1つの自律システム（Aut-Numクラス）のポリシーの説明からルーター構成を生成できるように設計されており、ルーター（INET-RTRクラス）の説明を組み合わせて、主にルーターID、自律システム番号の数を提供します。ルーターのルーター、インターフェイス、およびピア、およびAs Sets to ASES（As-Setクラス）からのグローバルデータベースマッピング、およびOrigin ASESおよびルートセットからルートプレフィックス（ルートおよびルートセットクラス）へのルートセットと組み合わされます。RPSLデータベースの正確な母集団は、不正確なルーティング情報の偶発的（または悪意のある）分布、インターネットのルーティングの検証、および単一のASを超えた集約境界を保護するルーター構成などの目標に貢献するのに役立ちます。
RPSL is object oriented; that is, objects contain pieces of policy and administrative information. These objects are registered in the Internet Routing Registry (IRR) by the authorized organizations. The registration process is beyond the scope of this document. Please refer to [1, 17, 4] for more details on the IRR.
RPSLはオブジェクト指向です。つまり、オブジェクトにはポリシーおよび管理情報が含まれています。これらのオブジェクトは、認定組織によってインターネットルーティングレジストリ（IRR）に登録されています。登録プロセスは、このドキュメントの範囲を超えています。IRRの詳細については、[1、17、4]を参照してください。
In the following sections, we present the classes that are used to define various policy and administrative objects. The "mntner" class defines entities authorized to add, delete and modify a set of objects. The "person" and "role" classes describes technical and administrative contact personnel. Autonomous systems (ASes) are specified using the "aut-num" class. Routes are specified using the
次のセクションでは、さまざまなポリシーおよび管理オブジェクトを定義するために使用されるクラスを紹介します。「MNTNER」クラスは、オブジェクトのセットを追加、削除、変更することが許可されたエンティティを定義します。「人」と「役割」クラスは、技術的および管理上の連絡先要員を説明しています。自律システム（ASE）は、「Aut-Num」クラスを使用して指定されています。ルートは、を使用して指定されています
"route" class. Sets of objects can be defined using the "as-set", "route-set", "filter-set", "peering-set", and "rtr-set" classes. The "dictionary" class provides the extensibility to the language. The "inet-rtr" class is used to specify routers. Many of these classes were originally defined in earlier documents [6, 13, 16, 12, 5] and have all been enhanced.
「ルート」クラス。オブジェクトのセットは、「as-set」、「ルートセット」、「フィルターセット」、「ピアリングセット」、および「RTRセット」クラスを使用して定義できます。「辞書」クラスは、言語の拡張性を提供します。「INET-RTR」クラスは、ルーターを指定するために使用されます。これらのクラスの多くは、もともと以前の文書[6、13、16、12、5]で定義されており、すべて強化されています。
This document is self-contained. However, the reader is encouraged to read RIPE-181 [7] and the associated documents [13, 16, 12, 5] as they provide significant background as to the motivation and underlying principles behind RIPE-181 and consequently, RPSL. For a tutorial on RPSL, the reader should read the RPSL applications document [4].
このドキュメントは自己完結型です。しかし、読者は、Ripe-181 [7]と関連するドキュメント[13、16、12、5]を読むことをお勧めします。RPSLに関するチュートリアルについては、読者はRPSLアプリケーションドキュメント[4]を読む必要があります。
2 RPSL Names, Reserved Words, and Representation
2 RPSL名、予約された単語、および表現
Each class has a set of attributes which store a piece of information about the objects of the class. Attributes can be mandatory or optional: A mandatory attribute has to be defined for all objects of the class; optional attributes can be skipped. Attributes can also be single or multiple valued. Each object is uniquely identified by a set of attributes, referred to as the class "key".
各クラスには、クラスのオブジェクトに関する情報を保存する属性のセットがあります。属性は必須またはオプションです。クラスのすべてのオブジェクトに対して必須属性を定義する必要があります。オプションの属性をスキップできます。属性は、単一または複数の価値を持つこともできます。各オブジェクトは、クラス「キー」と呼ばれる一連の属性によって一意に識別されます。
The value of an attribute has a type. The following types are most widely used. Note that RPSL is case insensitive and only the characters from the ASCII character set can be used.
属性の値にはタイプがあります。次のタイプは最も広く使用されています。RPSLは症例鈍感であり、ASCII文字セットの文字のみを使用できることに注意してください。
<object-name> Many objects in RPSL have a name. An <object-name> is made up of letters, digits, the character underscore "_", and the character hyphen "-"; the first character of a name must be a letter, and the last character of a name must be a letter or a digit. The following words are reserved by RPSL, and they can not be used as names:
<Object-Name> RPSLの多くのオブジェクトには名前があります。<Object-name>は、文字、数字、文字が「_」を強調し、キャラクターハイフン " - "で構成されています。名前の最初の文字は文字でなければならず、名前の最後の文字は文字または数字でなければなりません。次の単語はRPSLによって予約されており、名前として使用することはできません。
any as-any rs-any peeras and or not atomic from to at action accept announce except refine networks into inbound outbound
あらゆるrs-any-Any PeerasおよびATOMICからAT AT AT AT AT ACTACT ACCEPTアナウンスを除外して、ネットワークをインバウンドアウトバウンドに洗練させます
Names starting with certain prefixes are reserved for certain object types. Names starting with "as-" are reserved for as set names. Names starting with "rs-" are reserved for route set names. Names starting with "rtrs-" are reserved for router set names. Names starting with "fltr-" are reserved for filter set names. Names starting with "prng-" are reserved for peering set names.
特定のプレフィックスから始まる名前は、特定のオブジェクトタイプに予約されています。「As-」から始まる名前は、設定名として予約されています。「rs」から始まる名前は、ルートセット名用に予約されています。「rtrs-」から始まる名前は、ルーターセット名用に予約されています。「FLTR」から始まる名前は、フィルターセット名用に予約されています。「PRNG」から始まる名前は、セット名のピアリング用に予約されています。
<as-number> An AS number x is represented as the string "ASx". That is, the AS 226 is represented as AS226.
<as-number> as番号xは、文字列「asx」として表されます。つまり、AS 226はAS226として表されます。
<ipv4-address> An IPv4 address is represented as a sequence of four integers in the range from 0 to 255 separated by the character dot ".". For example, 128.9.128.5 represents a valid IPv4 address. In the rest of this document, we may refer to IPv4 addresses as IP addresses.
<IPv4-Address> IPv4アドレスは、文字DOTで分離された0〜255の範囲の4つの整数のシーケンスとして表されます。たとえば、128.9.128.5は有効なIPv4アドレスを表します。このドキュメントの残りの部分では、IPv4アドレスをIPアドレスと呼ぶことができます。
<address-prefix> An address prefix is represented as an IPv4 address followed by the character slash "/" followed by an integer in the range from 0 to 32. The following are valid address prefixes: 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address prefixes are invalid: 0/0, 128.9/16 since 0 or 128.9 are not strings containing four integers.
<Address-Prefix>アドレスプレフィックスは、IPv4アドレスとして表され、その後の文字スラッシュ "/"に続いて0から32の範囲の整数が続きます。/16、0.0.0.0/0;また、次のアドレスのプレフィックスは無効です：0/0、128.9/16は0または128.9が4つの整数を含む文字列ではないためです。
<address-prefix-range> An address prefix range is an address prefix followed by an optional range operator. The range operators are:
<Address-Prefix-Range>アドレスプレフィックス範囲は、オプションの範囲演算子が続くアドレスプレフィックスです。範囲演算子は次のとおりです。
^- is the exclusive more specifics operator; it stands for the more specifics of the address prefix excluding the address prefix itself. For example, 128.9.0.0/16^- contains all the more specifics of 128.9.0.0/16 excluding 128.9.0.0/16.
^ - 排他的な詳細オペレーターです。アドレスプレフィックス自体を除くアドレスプレフィックスのより多くの詳細を表します。たとえば、128.9.0.0/16^-は、128.9.0.0.0.0/16を除く128.9.0.0.0/16のすべての詳細を含みます。
^+ is the inclusive more specifics operator; it stands for the more specifics of the address prefix including the address prefix itself. For example, 5.0.0.0/8^+ contains all the more specifics of 5.0.0.0/8 including 5.0.0.0/8.
^は、より多くの詳細オペレーターです。アドレスプレフィックス自体を含むアドレスプレフィックスのより多くの詳細を表します。たとえば、5.0.0.0/8^には、5.0.0.0/8を含む5.0.0.0/8のすべての詳細が含まれています。
^n where n is an integer, stands for all the length n specifics of the address prefix. For example, 30.0.0.0/8^16 contains all the more specifics of 30.0.0.0/8 which are of length 16 such as 30.9.0.0/16.
^nここで、nは整数であり、アドレスプレフィックスのすべての長さnの詳細を表します。たとえば、30.0.0.0/8716には、30.0.0.0/16などの長さ16の30.0.0.0/8のすべての詳細が含まれています。
^n-m where n and m are integers, stands for all the length n to length m specifics of the address prefix. For example, 30.0.0.0/8^24-32 contains all the more specifics of 30.0.0.0/8 which are of length 24 to 32 such as 30.9.9.96/28.
^n-mここで、nとmは整数であり、アドレスプレフィックスのすべての長さnから長さmの詳細を表します。たとえば、30.0.0.0/8^24-32には、30.9.96/28などの長さ24から32の30.0.0.0/8のすべての詳細が含まれています。
Range operators can also be applied to address prefix sets. In this case, they distribute over the members of the set. For example, for a route-set (defined later) rs-foo, rs-foo^+ contains all the inclusive more specifics of all the prefixes in rs-foo.
範囲演算子を適用して、プレフィックスセットをアドレスすることもできます。この場合、彼らはセットのメンバーに配布します。たとえば、ルートセット（後で定義）の場合、rs-foo^には、rs-fooのすべての接頭辞のすべての包括的な詳細が含まれます。
It is an error to follow a range operator with another one (e.g. 30.0.0.0/8^24-28^+ is an error). However, a range operator can be applied to an address prefix set that has address prefix ranges in it (e.g. {30.0.0.0/8^24-28}^27-30 is not an error). In this case, the outer operator ^n-m distributes over the inner operator ^k-l and becomes the operator ^max(n,k)-m if m is greater than or equal to max(n,k), or otherwise, the prefix is deleted from the set. Note that the operator ^n is equivalent to ^n-n; prefix/l^+ is equivalent to prefix/l^l-32; prefix/l^- is equivalent to prefix/l^(l+1)-32; {prefix/l^n-m}^+ is equivalent to {prefix/l^n-32}; and {prefix/l^n-m}^- is equivalent to {prefix/l^(n+1)-32}. For example,
レンジオペレーターを別のオペレーターでフォローするのはエラーです（例：30.0.0.0/8^24-28^はエラーです）。ただし、範囲演算子は、アドレスプレフィックス範囲があるアドレスプレフィックスセットに適用できます（例：{30.0.0.0/8^24-28} ^27-30はエラーではありません）。この場合、外部演算子 ^n-mは内部演算子 ^k-lに分配され、mがmax（n、k）以上の場合、またはその他の場合、操作 ^max（n、k）-mになります。セットから削除されました。演算子 ^nは ^n-nに相当することに注意してください。プレフィックス/l^は、プレフィックス/l^ l-32に相当します。プレフィックス/l^ - は、プレフィックス/l^（l 1）-32に相当します。{プレフィックス/l^n-m}^は{プレフィックス/l^n-32}に相当します。および{プレフィックス/l^n-m}^ - は{prefix/l^（n 1）-32}に相当します。例えば、
{128.9.0.0/16^+}^- == {128.9.0.0/16^-}
{128.9.0.0/16^-}^+ == {128.9.0.0/16^-}
{128.9.0.0/16^17}^24 == {128.9.0.0/16^24}
{128.9.0.0/16^20-24}^26-28 == {128.9.0.0/16^26-28}
{128.9.0.0/16^20-24}^22-28 == {128.9.0.0/16^22-28}
{128.9.0.0/16^20-24}^18-28 == {128.9.0.0/16^20-28}
{128.9.0.0/16^20-24}^18-22 == {128.9.0.0/16^20-22}
{128.9.0.0/16^20-24}^18-19 == {}
<date> A date is represented as an eight digit integer of the form YYYYMMDD where YYYY represents the year, MM represents the month of the year (01 through 12), and DD represents the day of the month (01 through 31). All dates are in UTC unless otherwise specified. For example, June 24, 1996 is represented as 19960624.
<tate>日付は、yyyyが年を表すyyyymmddの形式の8桁の整数として表され、mmは年（01〜12）を表し、DDは月（01〜31）を表します。特に指定がない限り、すべての日付はUTCにあります。たとえば、1996年6月24日は19960624として表されています。
<email-address>is as described in RFC-822 [10].
<メールアドレス>は、RFC-822 [10]に記載されているとおりです。
<dns-name>is as described in RFC-1034 [17].
<dns-name>は、RFC-1034 [17]に記載されているとおりです。
<nic-handle> is a uniquely assigned identifier word used by routing, address allocation, and other registries to unambiguously refer to contact information. Person and role classes map NIC handles to actual person names, and contact information.
<nichandle>は、ルーティング、アドレス割り当て、およびその他のレジストリが連絡先情報を明確に参照するために使用される一意に割り当てられた識別子ワードです。個人と役割のクラスは、NICハンドルを実際の個人名と連絡先情報にマッピングします。
<free-form>is a sequence of ASCII characters.
<Free-Form>は、ASCII文字のシーケンスです。
<X-name> is a name of an object of type X. That is <mntner-name> is a name of a mntner object.
<x-name>はタイプxのオブジェクトの名前です。つまり、<mntner-name>はmntnerオブジェクトの名前です。
<registry-name> is a name of an IRR registry. The routing registries are listed in Appendix A.
<Registry-Name>はIRRレジストリの名前です。ルーティングレジストリは付録Aにリストされています。
A value of an attribute may also be a list of one of these types. A list is represented by separating the list members by commas ",". For example, "AS1, AS2, AS3, AS4" is a list of AS numbers. Note that being list valued and being multiple valued are orthogonal. A multiple valued attribute has more than one value, each of which may or may not be a list. On the other hand a single valued attribute may have a list value.
属性の値は、これらのタイプのいずれかのリストでもあります。リストは、リストメンバーをコンマで分離することによって表されます」、 "。たとえば、「AS1、AS2、AS3、AS4」はAS数のリストです。リストが評価され、複数の価値があることは直交することに注意してください。複数の価値のある属性には複数の値があり、それぞれがリストになる場合とそうでない場合があります。一方、単一の価値のある属性にはリスト値がある場合があります。
An RPSL object is textually represented as a list of attribute-value pairs. Each attribute-value pair is written on a separate line. The attribute name starts at column 0, followed by character ":" and followed by the value of the attribute. The attribute which has the same name as the object's class should be specified first. The object's representation ends when a blank line is encountered. An attribute's value can be split over multiple lines, by having a space, a tab or a plus ('+') character as the first character of the continuation lines. The character "+" for line continuation allows attribute values to contain blank lines. More spaces may optionally be used after the continuation character to increase readability. The order of attribute-value pairs is significant.
RPSLオブジェクトは、属性値ペアのリストとしてテキストに表されます。各属性値ペアは別の行に記述されます。属性名は列0で始まり、文字 "："が続き、その後に属性の値が続きます。オブジェクトのクラスと同じ名前を持つ属性を最初に指定する必要があります。オブジェクトの表現は、空白の行に遭遇すると終了します。属性の値は、継続ラインの最初の文字としてスペース、タブ、またはプラス（ ''）文字を持つことにより、複数の行に分割できます。Line Continuationの文字「」は、属性値が空白線を含めることを可能にします。読みやすさを向上させるために、継続文字の後にオプションで使用される場合があります。属性値のペアの順序は重要です。
An object's description may contain comments. A comment can be anywhere in an object's definition, it starts at the first "#" character on a line and ends at the first end-of-line character. White space characters can be used to improve readability.
オブジェクトの説明にはコメントが含まれている場合があります。コメントはオブジェクトの定義のどこにでもあります。最初の「＃」文字から始まり、最初の終わりの文字で終わります。ホワイトスペースのキャラクターは、読みやすさを向上させるために使用できます。
An integer can be specified using (1) the C programming language notation (e.g. 1, 12345); (2) sequence of four 1-octet integers (in the range from 0 to 255) separated by the character dot "." (e.g. 1.1.1.1, 255.255.0.0), in this case a 4-octet integer is formed by concatenating these 1-octet integers in the most significant to least significant order; (3) sequence of two 2-octet integers (in the range from 0 to 65535) separated by the character colon ":" (e.g. 3561:70, 3582:10), in this case a 4-octet integer is formed by concatenating these 2-octet integers in the most significant to least significant order.
（1）Cプログラミング言語表記（例：1、12345）を使用して整数を指定できます。（2）文字DOTで分離された4つの1-OCTET整数（0から255までの範囲）のシーケンス。（例：1.1.1.1、255.255.0.0）、この場合、これらの1-OCTET整数を最も重要なものから最も重要な順序で連結することにより、4-OCTET整数が形成されます。（3）キャラクターコロンで分離された2つの2オクテットの整数（0〜65535の範囲）のシーケンス： "（例：3561：70、3582：10）、この場合、4-OCTET整数は連結することによって形成されます。これらの2-OCTET整数は、最も重要なものから最も重要な順序で。
3 Contact Information
3連絡先情報
The mntner, person and role classes, admin-c, tech-c, mnt-by, changed, and source attributes of all classes describe contact information. The mntner class also specifies authenticaiton information required to create, delete and update other objects. These classes do not specify routing policies and each registry may have different or additional requirements on them. Here we present the common denominator for completeness which is the RIPE database implementation [16]. Please consult your routing registry for the latest specification of these classes and attributes. The "Routing Policy System Security" document [20] describes the authenticaiton and authorization model in more detail.
すべてのクラスのMNTNER、個人およびロールクラス、Admin-C、Tech-C、MNT-BY、変更、およびソース属性は、連絡先情報を説明しています。MNTNERクラスは、他のオブジェクトを作成、削除、更新するために必要なAuthenticAiton情報も指定しています。これらのクラスはルーティングポリシーを指定しておらず、各レジストリには異なる要件または追加要件がある場合があります。ここでは、熟したデータベースの実装である完全性のための共通の分母を提示します[16]。これらのクラスと属性の最新の仕様については、ルーティングレジストリを参照してください。「ルーティングポリシーシステムセキュリティ」ドキュメント[20]では、AuthenticAitonと認証モデルをより詳細に説明しています。
The mntner class specifies authenticaiton information required to create, delete and update RPSL objects. A provider, before he/she can create RPSL objects, first needs to create a mntner object. The attributes of the mntner class are shown in Figure 1. The mntner class was first described in [13].
MNTNERクラスは、RPSLオブジェクトを作成、削除、更新するために必要なAuthenticAiton情報を指定します。プロバイダーは、RPSLオブジェクトを作成する前に、最初にMNTNERオブジェクトを作成する必要があります。MNTNERクラスの属性を図1に示します。MNTNERクラスは[13]で最初に説明されました。
The mntner attribute is mandatory and is the class key. Its value is an RPSL name. The auth attribute specifies the scheme that will be used to identify and authenticate update requests from this maintainer. It has the following syntax:
MNTNER属性は必須であり、クラスキーです。その値はRPSL名です。AUTH属性は、このメンテナーからの更新要求を識別および認証するために使用されるスキームを指定します。次の構文があります。
auth: <scheme-id> <auth-info>
E.g. auth: NONE
例えば。AUTH：なし
Attribute Value Type
mntner <object-name> mandatory, single-valued, class key
descr <free-form> mandatory, single-valued
auth see description in text mandatory, multi-valued
upd-to <email-address> mandatory, multi-valued
mnt-nfy <email-address> optional, multi-valued
tech-c <nic-handle> mandatory, multi-valued
admin-c <nic-handle> optional, multi-valued
remarks <free-form> optional, multi-valued
notify <email-address> optional, multi-valued
mnt-by list of <mntner-name> mandatory, multi-valued
changed <email-address> <date> mandatory, multi-valued
source <registry-name> mandatory, single-valued
Figure 1: mntner Class Attributes
図1：MNTNERクラス属性
auth: CRYPT-PW dhjsdfhruewf
auth: MAIL-FROM .*@ripe\.net
The <scheme-id>'s currently defined are: NONE, MAIL-FROM, PGP-KEY and CRYPT-PW. The <auth-info> is additional information required by a particular scheme: in the case of MAIL-FROM, it is a regular expression matching valid email addresses; in the case of CRYPT-PW, it is a password in UNIX crypt format; and in the case of PGP-KEY, it is a pointer to key-certif object [22] containing the PGP public key of the user. If multiple auth attributes are specified, an update request satisfying any one of them is authenticated to be from the maintainer.
現在定義されている<scheme-id>は次のとおりです。<auth-info>は、特定のスキームで必要な追加情報です。メールからのメールでは、有効な電子メールアドレスを一致させる正規表現です。Crypt-PWの場合、UNIX Crypt形式のパスワードです。また、PGP-Keyの場合、ユーザーのPGP公開キーを含むキーCERTIFオブジェクト[22]へのポインターです。複数の認証属性が指定されている場合、それらのいずれかを満足させる更新リクエストは、メンテナーからのものであると認証されます。
The upd-to attribute is an email address. On an unauthorized update attempt of an object maintained by this maintainer, an email message will be sent to this address. The mnt-nfy attribute is an email address. A notification message will be forwarded to this email address whenever an object maintained by this maintainer is added, changed or deleted.
Upd-To属性はメールアドレスです。このメンテナーによって維持されているオブジェクトの不正な更新試行では、このアドレスに電子メールメッセージが送信されます。MNT-NFY属性はメールアドレスです。このメンテナーによって維持されているオブジェクトが追加、変更、または削除された場合は、通知メッセージがこのメールアドレスに転送されます。
The descr attribute is a short, free-form textual description of the object. The tech-c attribute is a technical contact NIC handle. This is someone to be contacted for technical problems such as misconfiguration. The admin-c attribute is an administrative contact NIC handle. The remarks attribute is a free text explanation or clarification. The notify attribute is an email address to which notifications of changes to this object should be sent. The mnt-by attribute is a list of mntner object names. The authorization for changes to this object is governed by any of the maintainer objects referenced. The changed attribute documents who last changed this object, and when this change was made. Its syntax has the following form:
DESCR属性は、オブジェクトの短い自由形式のテキスト説明です。Tech-C属性は、技術的な連絡先NICハンドルです。これは、誤解などの技術的な問題について連絡する人です。Admin-C属性は、管理者の連絡先NICハンドルです。備考属性は、無料のテキストの説明または明確化です。Notify属性は、このオブジェクトへの変更の通知を送信するメールアドレスです。MNT-by属性は、MNTNERオブジェクト名のリストです。このオブジェクトの変更の承認は、参照されるメンテナーオブジェクトのいずれかによって支配されます。最後にこのオブジェクトを変更した変更ドキュメント、およびこの変更が行われたとき。その構文には次の形式があります。
changed: <email-address> <YYYYMMDD>
E.g. changed: johndoe@terabit-labs.nn 19900401
例えば。変更：johndoe@terabit-labs.nn 19900401
The <email-address> identifies the person who made the last change. <YYYYMMDD> is the date of the change. The source attribute specifies the registry where the object is registered. Figure 2 shows an example mntner object. In the example, UNIX crypt format password authentication is used.
<email-address>は、最後の変更を行った人を識別します。<yyyymmdd>は変更の日付です。ソース属性は、オブジェクトが登録されているレジストリを指定します。図2は、MNTNERオブジェクトの例を示しています。この例では、UNIX Crypt形式のパスワード認証が使用されています。
mntner: RIPE-NCC-MNT
descr: RIPE-NCC Maintainer
admin-c: DK58
tech-c: OPS4-RIPE
upd-to: ops@ripe.net
mnt-nfy: ops-fyi@ripe.net
auth: CRYPT-PW lz1A7/JnfkTtI
mnt-by: RIPE-NCC-MNT
changed: ripe-dbm@ripe.net 19970820
source: RIPE
Figure 2: An example mntner object.
図2：MNTNERオブジェクトの例。
The descr, tech-c, admin-c, remarks, notify, mnt-by, changed and source attributes are attributes of all RPSL classes. Their syntax, semantics, and mandatory, optional, multi-valued, or single-valued status are the same for for all RPSL classes. Only exception to this is the admin-c attribute which is mandatory for the aut-num class. We do not further discuss them in other sections.
DESCR、Tech-C、Admin-C、備考、Notify、Mnt-by、およびSource属性は、すべてのRPSLクラスの属性です。それらの構文、セマンティクス、および必須、オプション、多値、または単一値ステータスは、すべてのRPSLクラスで同じです。これの唯一の例外は、Aut-Numクラスに必須のAdmin-C属性です。他のセクションではこれ以上説明しません。
A person class is used to describe information about people. Even though it does not describe routing policy, we still describe it here briefly since many policy objects make reference to person objects. The person class was first described in [15].
個人のクラスは、人々に関する情報を説明するために使用されます。ルーティングポリシーは説明されていませんが、多くのポリシーオブジェクトが個人のオブジェクトに言及しているため、ここで簡単に説明します。人クラスは[15]で最初に説明されました。
The attributes of the person class are shown in Figure 3. The person attribute is the full name of the person. The phone and the fax-no attributes have the following syntax:
人クラスの属性を図3に示します。個人の属性は人のフルネームです。電話とFax-Noの属性には、次の構文があります。
phone: +<country-code> <city> <subscriber> [ext. <extension>]
E.g.: phone: +31 20 12334676
例：電話：31 20 12334676
Attribute Value Type
person <free-form> mandatory, single-valued
nic-hdl <nic-handle> mandatory, single-valued, class key
address <free-form> mandatory, multi-valued
phone see description in text mandatory, multi-valued
fax-no same as phone optional, multi-valued
e-mail <email-address> mandatory, multi-valued
Figure 3: person Class Attributes
図3：人クラスの属性
phone: +44 123 987654 ext. 4711
電話：44 123 987654内線4711
Figure 4 shows an example person object.
図4は、人物の例を示しています。
person: Daniel Karrenberg
address: RIPE Network Coordination Centre (NCC)
address: Singel 258
address: NL-1016 AB Amsterdam
address: Netherlands
phone: +31 20 535 4444
fax-no: +31 20 535 4445
e-mail: Daniel.Karrenberg@ripe.net
nic-hdl: DK58
changed: Daniel.Karrenberg@ripe.net 19970616
source: RIPE
Figure 4: An example person object.
図4：人物の例。
The role class is similar to the person object. However, instead of describing a human being, it describes a role performed by one or more human beings. Examples include help desks, network monitoring centers, system administrators, etc. Role object is particularly useful since often a person performing a role may change, however the role itself remains.
ロールクラスは、Personオブジェクトに似ています。しかし、人間を説明する代わりに、1人以上の人間によって実行される役割を説明しています。例には、ヘルプデスク、ネットワーク監視センター、システム管理者などが含まれます。ロールオブジェクトは、役割を実行する人が変化する可能性があることが多いため、特に役立ちますが、役割自体が残っています。
The attributes of the role class are shown in Figure 5. The nic-hdl attributes of the person and role classes share the same name space. The trouble attribute of role object may contain additional contact information to be used when a problem arises in any object that references this role object. Figure 6 shows an example role object.
ロールクラスの属性を図5に示します。ロールオブジェクトのトラブル属性には、このロールオブジェクトを参照するオブジェクトに問題が発生した場合に使用する追加の連絡先情報が含まれている場合があります。図6は、ロールオブジェクトの例を示しています。
Attribute Value Type
role <free-form> mandatory, single-valued
nic-hdl <nic-handle> mandatory, single-valued,
class key
trouble <free-form> optional, multi-valued
address <free-form> mandatory, multi-valued
phone see description in text mandatory, multi-valued
fax-no same as phone optional, multi-valued
e-mail <email-address> mandatory, multi-valued
Figure 5: role Class Attributes
図5：ロールクラスの属性
role: RIPE NCC Operations
trouble:
address: Singel 258
address: 1016 AB Amsterdam
address: The Netherlands
phone: +31 20 535 4444
fax-no: +31 20 545 4445
e-mail: ops@ripe.net
admin-c: CO19-RIPE
tech-c: RW488-RIPE
tech-c: JLSD1-RIPE
nic-hdl: OPS4-RIPE
notify: ops@ripe.net
changed: roderik@ripe.net 19970926
source: RIPE
Figure 6: An example role object.
図6：ロールオブジェクトの例。
4 route Class
4ルートクラス
Each interAS route (also referred to as an interdomain route) originated by an AS is specified using a route object. The attributes of the route class are shown in Figure 7. The route attribute is the address prefix of the route and the origin attribute is the AS number of the AS that originates the route into the interAS routing system. The route and origin attribute pair is the class key.
ルートオブジェクトを使用して指定されているAnによって発信される各インターアスルート（ドメイン間ルートとも呼ばれます）。ルートクラスの属性を図7に示します。ルート属性はルートのアドレスプレフィックスであり、原点属性は、ルートをインターアスルーティングシステムに由来するASの数です。Route and Origin属性ペアはクラスキーです。
Figure 8 shows examples of four route objects (we do not include contact attributes such as admin-c, tech-c for brevity). Note that the last two route objects have the same address prefix, namely 128.8.0.0/16. However, they are different route objects since they are originated by different ASes (i.e. they have different keys).
図8は、4つのルートオブジェクトの例を示しています（admin-c、tech-c for brevityなどの連絡先属性は含まれていません）。最後の2つのルートオブジェクトには、同じアドレスプレフィックス、つまり128.8.0.0/16があることに注意してください。ただし、さまざまなASE（つまり、異なるキーがある）が発信されるため、異なるルートオブジェクトです。
Attribute Value Type
route <address-prefix> mandatory, single-valued,
class key
origin <as-number> mandatory, single-valued,
class key
member-of list of <route-set-names> optional, multi-valued
see Section 5
inject see Section 8 optional, multi-valued
components see Section 8 optional, single-valued
aggr-bndry see Section 8 optional, single-valued
aggr-mtd see Section 8 optional, single-valued
export-comps see Section 8 optional, single-valued
holes see Section 8 optional, multi-valued
Figure 7: route Class Attributes
図7：ルートクラスの属性
route: 128.9.0.0/16 origin: AS226
ルート：128.9.0.0/16起源：AS226
route: 128.99.0.0/16 origin: AS226
ルート：128.99.0.0/16起源：AS226
route: 128.8.0.0/16 origin: AS1
ルート：128.8.0.0/16原点：AS1
route: 128.8.0.0/16 origin: AS2
ルート：128.8.0.0/16原点：AS2
Figure 8: Route Objects
図8：ルートオブジェクト
5 Set Classes
5セットクラス
To specify policies, it is often useful to define sets of objects. For this purpose we define as-set, route-set, rtr-set, filter-set, and peering-set classes. These classes define a named set. The members of these sets can be specified either directly by listing them in the sets' definition, or indirectly by having member objects refer to the sets' names, or a combination of both methods.
ポリシーを指定するには、オブジェクトのセットを定義することがしばしば役立ちます。この目的のために、ASセット、ルートセット、RTRセット、フィルターセット、およびピアリングセットクラスを定義します。これらのクラスは、名前付きセットを定義します。これらのセットのメンバーは、セットの定義にそれらをリストすることにより、またはメンバーオブジェクトにセットの名前を参照するか、両方の方法の組み合わせを指すことによって直接指定できます。
A set's name is an rpsl word with the following restrictions: All as-set names start with prefix "as-". All route-set names start with prefix "rs-". All rtr-set names start with prefix "rtrs-". All filter-set names start with prefix "fltr-". All peering-set names start with prefix "prng-". For example, as-foo is a valid as-set name.
セットの名前は、次の制限を備えたRPSLワードです。すべてのAS-SET名は「AS-」のプレフィックスから始まります。すべてのルートセット名は、プレフィックス「rs-」で始まります。すべてのrtrセット名は、 "rtrs-"のプレフィックスから始まります。すべてのフィルターセット名は、「FLTR-」のプレフィックスから始まります。すべてのピアリングセット名は、プレフィックス「PRNG-」から始まります。たとえば、As-Fooは有効なASセット名です。
Set names can also be hierarchical. A hierarchical set name is a sequence of set names and AS numbers separated by colons ":". At least one component of such a name must be an actual set name (i.e. start with one of the prefixes above). All the set name components of an hierarchical name has to be of the same type. For example, the following names are valid: AS1:AS-CUSTOMERS, AS1:RS-EXPORT:AS2, RS-EXCEPTIONS:RS-BOGUS.
セット名は階層的にすることもできます。階層セット名は、セット名のシーケンスであり、コロンで区切られた数字「：」。このような名前の少なくとも1つのコンポーネントは、実際のセット名でなければなりません（つまり、上記のプレフィックスの1つから始めます）。階層名のすべてのセット名コンポーネントは、同じタイプでなければなりません。たとえば、次の名前は有効です。AS1：AS-Customers、AS1：RS-Export：AS2、RS-Exceptions：RS-bogus。
The purpose of an hierarchical set name is to partition the set name space so that the maintainers of the set X1 controls the whole set name space underneath, i.e. X1:...:Xn-1. Thus, a set object with name X1:...:Xn-1:Xn can only be created by the maintainer of the object with name X1:...:Xn-1. That is, only the maintainer of AS1 can create a set with name AS1:AS-FOO; and only the maintainer of AS1:AS-FOO can create a set with name AS1:AS-FOO:AS-BAR. Please see RPS Security Document [20] for details.
階層セット名の目的は、セットx1のメンテナーが下のセット名スペース全体、つまりx1：...：xn-1を制御するように、セット名スペースを分割することです。したがって、名前x1：...：xn-1：xnを備えたセットオブジェクトは、名前x1：...：xn-1でオブジェクトのメンテナーによってのみ作成できます。つまり、AS1のメンテナーのみがAS1：AS-FOOという名前のセットを作成できます。AS1：AS-Fooのメンテナーのみが、AS1：AS-FOO：AS-BARで名前を作成できます。詳細については、RPSセキュリティドキュメント[20]を参照してください。
The attributes of the as-set class are shown in Figure 9. The as-set attribute defines the name of the set. It is an RPSL name that starts with "as-". The members attribute lists the members of the set. The members attribute is a list of AS numbers, or other as-set names.
AS-SETクラスの属性を図9に示します。ASSET属性は、セットの名前を定義します。「As-」で始まるRPSL名です。メンバー属性は、セットのメンバーをリストします。メンバー属性は、数字またはその他のASセット名のリストです。
Attribute Value Type
as-set <object-name> mandatory, single-valued,
class key
members list of <as-numbers> or optional, multi-valued
<as-set-names>
mbrs-by-ref list of <mntner-names> optional, multi-valued
Figure 9: as-set Class Attributes
図9：AS-SETクラス属性
Figure 10 presents two as-set objects. The set as-foo contains two ASes, namely AS1 and AS2. The set as-bar contains the members of the set as-foo and AS3, that is it contains AS1, AS2, AS3. The set as-empty contains no members.
図10は、2つのASセットオブジェクトを示しています。セットASFOOには、AS1とAS2の2つのASEが含まれています。セットAS-BARには、SET AS-FOOおよびAS3のメンバーが含まれています。つまり、AS1、AS2、AS3が含まれています。セットAs-Semptyにはメンバーが含まれていません。
as-set: as-foo as-set: as-bar as-set: as-empty
members: AS1, AS2 members: AS3, as-foo
Figure 10: as-set objects.
図10：ASセットオブジェクト。
The mbrs-by-ref attribute is a list of maintainer names or the keyword ANY. If this attribute is used, the AS set also includes ASes whose aut-num objects are registered by one of these maintainers and whose member-of attribute refers to the name of this AS set. If the value of a mbrs-by-ref attribute is ANY, any AS object referring to the AS set is a member of the set. If the mbrs-by-ref attribute is missing, only the ASes listed in the members attribute are members of the set.
MBRS-by-ref属性は、メンテナー名またはキーワードのリストです。この属性を使用する場合、SESSには、これらのメンテナーの1つによってAut-Numオブジェクトが登録されており、メンバーオブ属性がこの名前をセットとして参照するASEも含まれます。MBRS-by-ref属性の値がいずれかである場合、AS SETを参照するオブジェクトはセットのメンバーです。MBRS-REF属性が欠落している場合、メンバー属性にリストされているASESのみがセットのメンバーです。
as-set: as-foo members: AS1, AS2 mbrs-by-ref: MNTR-ME
as-set：as-fooメンバー：as1、as2 mbrs-by-ref：mntr-me
aut-num: AS3 aut-num: AS4
member-of: as-foo member-of: as-foo
mnt-by: MNTR-ME mnt-by: MNTR-OTHER
Figure 11: as-set objects.
図11：ASセットオブジェクト。
Figure 11 presents an example as-set object that uses the mbrs-by-ref attribute. The set as-foo contains AS1, AS2 and AS3. AS4 is not a member of the set as-foo even though the aut-num object references as-foo. This is because MNTR-OTHER is not listed in the as-foo's mbrs-by-ref attribute.
図11は、MBRS-REF属性を使用するAS SETオブジェクトの例を示しています。セットASFOOには、AS1、AS2、およびAS3が含まれています。AS4は、Aut-NumオブジェクトがAs-Fooを参照しているにもかかわらず、SET AS-Fooのメンバーではありません。これは、MNTR-OTHEがAs-FooのMBRS-REF属性にリストされていないためです。
The attributes of the route-set class are shown in Figure 12. The route-set attribute defines the name of the set. It is an RPSL name that starts with "rs-". The members attribute lists the members of the set. The members attribute is a list of address prefixes or other route-set names. Note that, the route-set class is a set of route prefixes, not of RPSL route objects.
ルートセットクラスの属性を図12に示します。ルートセット属性は、セットの名前を定義します。「rs-」で始まるRPSL名です。メンバー属性は、セットのメンバーをリストします。メンバー属性は、アドレスプレフィックスまたはその他のルートセット名のリストです。ルートセットクラスは、RPSLルートオブジェクトではなく、ルートプレフィックスのセットであることに注意してください。
Attribute Value Type
route-set <object-name> mandatory,
single-valued,
class key
members list of <address-prefix-range> or optional, multi-valued
<route-set-name> or
<route-set-name><range-operator>
mbrs-by-ref list of <mntner-names> optional, multi-valued
Figure 12: route-set Class Attributes
図12：ルートセットクラスの属性
Figure 13 presents some example route-set objects. The set rs-foo contains two address prefixes, namely 128.9.0.0/16 and 128.9.0.0/24. The set rs-bar contains the members of the set rs-foo and the address prefix 128.7.0.0/16.
図13は、いくつかのルートセットオブジェクトの例を示しています。セットRS-Fooには、2つのアドレスプレフィックス、つまり128.9.0.0/16および128.9.0.0/24が含まれています。セットRS-BARには、セットRS-Fooのメンバーとアドレスプレフィックス128.7.0.0/16が含まれています。
An address prefix or a route-set name in a members attribute can be optionally followed by a range operator. For example, the following set:
メンバー属性のアドレスプレフィックスまたはルートセット名にオプションで、レンジオペレーターが続くことができます。たとえば、次のセット：
route-set: rs-foo members: 128.9.0.0/16, 128.9.0.0/24
ルートセット：RS-Fooメンバー：128.9.0.0/16、128.9.0.0/24
route-set: rs-bar members: 128.7.0.0/16, rs-foo
ルートセット：RS-BARメンバー：128.7.0.0/16、RS-Foo
Figure 13: route-set Objects
図13：ルートセットオブジェクト
route-set: rs-bar
members: 5.0.0.0/8^+, 30.0.0.0/8^24-32, rs-foo^+
contains all the more specifics of 5.0.0.0/8 including 5.0.0.0/8, all the more specifics of 30.0.0.0/8 which are of length 24 to 32 such as 30.9.9.96/28, and all the more specifics of address prefixes in route set rs-foo.
5.0.0.0/8を含む5.0.0.0/8のすべての詳細が含まれています。30.0.0.0/8のすべての詳細は、30.9.96/28などの長さ24〜32であり、アドレスの詳細はすべてルートセットrs-fooのプレフィックス。
The mbrs-by-ref attribute is a list of maintainer names or the keyword ANY. If this attribute is used, the route set also includes address prefixes whose route objects are registered by one of these maintainers and whose member-of attribute refers to the name of this route set. If the value of a mbrs-by-ref attribute is ANY, any route object referring to the route set name is a member. If the mbrs-by-ref attribute is missing, only the address prefixes listed in the members attribute are members of the set.
MBRS-by-ref属性は、メンテナー名またはキーワードのリストです。この属性を使用すると、ルートセットには、これらのメンテナーのいずれかによってルートオブジェクトが登録されており、メンバーオブ属性がこのルートセットの名前を参照するアドレスプレフィックスも含まれています。MBRS-by-Ref属性の値が任意の場合、ルートセット名を参照するルートオブジェクトはメンバーです。MBRS-REF属性が欠落している場合、メンバー属性にリストされているアドレスプレフィックスのみがセットのメンバーです。
route-set: rs-foo mbrs-by-ref: MNTR-ME, MNTR-YOU
ルートセット：rs-foo mbrs-by-ref：mntr-me、mntr-you
route-set: rs-bar members: 128.7.0.0/16 mbrs-by-ref: MNTR-YOU
ルートセット：RS-BARメンバー：128.7.0.0/16 MBRS-BY-REF：MNTR-You
route: 128.9.0.0/16 origin: AS1 member-of: rs-foo mnt-by: MNTR-ME
ルート：128.9.0.0/16起源：AS1メンバー：rs-foomnt-by：mntr-me
route: 128.8.0.0/16 origin: AS2 member-of: rs-foo, rs-bar mnt-by: MNTR-YOU
ルート：128.8.0.0/16起源：AS2メンバー：rs-foo、rs-bar mnt-by：mntr-you
Figure 14: route-set objects.
図14：ルートセットオブジェクト。
Figure 14 presents example route-set objects that use the mbrs-by-ref attribute. The set rs-foo contains two address prefixes, namely 128.8.0.0/16 and 128.9.0.0/16 since the route objects for 128.8.0.0/16 and 128.9.0.0/16 refer to the set name rs-foo in their member-of attribute. The set rs-bar contains the address prefixes 128.7.0.0/16 and 128.8.0.0/16. The route 128.7.0.0/16 is explicitly listed in the members attribute of rs-bar, and the route object for 128.8.0.0/16 refer to the set name rs-bar in its member-of attribute.
図14は、MBRS-REF属性を使用するルートセットオブジェクトの例を示しています。セットRS-Fooには、128.8.0.0.0/16および128.9.0.0.0/16のルートオブジェクトがあるため、2つのアドレスプレフィックス、つまり128.8.0.0/16および128.9.0.0/16が含まれています。属性の。セットRS-BARには、アドレスプレフィックス128.7.0.0/16および128.8.0.0/16が含まれています。ルート128.7.0.0/16は、RS-BARのメンバー属性に明示的にリストされており、128.8.0.0/16のルートオブジェクトは、メンバーの属性のセット名RS-BARを参照してください。
Note that, if an address prefix is listed in a members attribute of a route set, it is a member of that route set. The route object corresponding to this address prefix does not need to contain a member-of attribute referring to this set name. The member-of attribute of the route class is an additional mechanism for specifying the members indirectly.
アドレスプレフィックスがルートセットのメンバー属性にリストされている場合、それはそのルートセットのメンバーであることに注意してください。このアドレスプレフィックスに対応するルートオブジェクトは、このセット名を参照するメンバーの属性を含める必要はありません。ルートクラスのメンバーの属性は、メンバーを間接的に指定するための追加のメカニズムです。
In a context that expects a route set (e.g. members attribute of the route-set class), an AS number ASx defines the set of routes that are originated by ASx; and an as-set AS-X defines the set of routes that are originated by the ASes in AS-X. A route p is said to be originated by ASx if there is a route object for p with ASx as the value of the origin attribute. For example, in Figure 15, the route set rs-special contains 128.9.0.0/16, routes of AS1 and AS2, and routes of the ASes in AS set AS-FOO.
ルートセット（例：ルートセットクラスのメンバー属性など）を期待するコンテキストでは、AS番号ASXは、ASXから発信されるルートのセットを定義します。AS-SET AS-Xは、AS-XのASESによって発信されるルートのセットを定義します。Origin属性の値としてASXを持つPのルートオブジェクトがある場合、ルートPはASXによって発信されると言われています。たとえば、図15では、ルートセットのRSスペシャルには、128.9.0.0/16、AS1とAS2のルート、およびAS AS AS-FOOのASのルートが含まれています。
route-set: rs-special members: 128.9.0.0/16, AS1, AS2, AS-FOO
ルートセット：RSスペシャルメンバー：128.9.0.0/16、AS1、AS2、As-Foo
Figure 15: Use of AS numbers and AS sets in route sets.
図15：ルートセットでのAS番号およびASセットの使用。
The set rs-any contains all routes registered in IRR. The set as-any contains all ASes registered in IRR.
セットRS-Anyには、IRRに登録されているすべてのルートが含まれています。SET AS-は、IRRに登録されているすべてのASEが含まれています。
The attributes of the filter-set class are shown in Figure 16. A filter-set object defines a set of routes that are matched by its filter. The filter-set attribute defines the name of the filter. It is an RPSL name that starts with "fltr-".
フィルターセットクラスの属性を図16に示します。フィルターセットオブジェクトは、そのフィルターによって一致するルートのセットを定義します。フィルターセット属性は、フィルターの名前を定義します。「FLTR」から始まるRPSL名です。
Attribute Value Type filter-set <object-name> mandatory, single-valued, class key filter <filter> mandatory, single-valued
属性値タイプタイプフィルターセット<Object-Name>必須、単一値、クラスキーフィルター<フィルター>必須、単一値
Figure 16: filter Class Attributes
図16：クラス属性をフィルター
filter-set: fltr-foo
filter: { 5.0.0.0/8, 6.0.0.0/8 }
filter-set: fltr-bar
filter: (AS1 or fltr-foo) and <AS2>
Figure 17: filter-set objects.
図17：フィルターセットオブジェクト。
The filter attribute defines the set's policy filter. A policy filter is a logical expression which when applied to a set of routes returns a subset of these routes. We say that the policy filter matches the subset returned. The policy filter can match routes using any BGP path attribute, such as the destination address prefix (or NLRI), AS-path, or community attributes.
フィルター属性は、セットのポリシーフィルターを定義します。ポリシーフィルターは、ルートのセットに適用すると、これらのルートのサブセットを返す論理的な式です。ポリシーフィルターは返されたサブセットと一致すると言います。ポリシーフィルターは、宛先アドレスプレフィックス（またはNLRI）、AS-PATH、またはコミュニティ属性など、任意のBGPパス属性を使用してルートに一致させることができます。
The policy filters can be composite by using the operators AND, OR, and NOT. The following policy filters can be used to select a subset of routes:
ポリシーフィルターは、オペレーターを使用して、OR、およびそうではないことにより複合することができます。次のポリシーフィルターを使用して、ルートのサブセットを選択できます。
ANY The keyword ANY matches all routes.
すべてのルートと一致するキーワードはすべてです。
Address-Prefix Set This is an explicit list of address prefixes enclosed in braces '{' and '}'. The policy filter matches the set of routes whose destination address-prefix is in the set. For example:
address-prefixセットこれは、ブレース '{'および '}に囲まれたアドレスプレフィックスの明示的なリストです。ポリシーフィルターは、宛先アドレス-Prefixがセットにあるルートのセットと一致します。例えば：
{ 0.0.0.0/0 }
{ 128.9.0.0/16, 128.8.0.0/16, 128.7.128.0/17, 5.0.0.0/8 }
{ }
An address prefix can be optionally followed by a range operator (i.e.
アドレスのプレフィックスには、オプションで範囲演算子が続くことができます（つまり、
{ 5.0.0.0/8^+, 128.9.0.0/16^-, 30.0.0.0/8^16, 30.0.0.0/8^24-32 }
contains all the more specifics of 5.0.0.0/8 including 5.0.0.0/8, all the more specifics of 128.9.0.0/16 excluding 128.9.0.0/16, all the more specifics of 30.0.0.0/8 which are of length 16 such as 30.9.0.0/16, and all the more specifics of 30.0.0.0/8 which are of length 24 to 32 such as 30.9.9.96/28.
5.0.0.0/8を含む5.0.0.0/8のすべての詳細が含まれています。128.9.0.0.0/16を除く128.9.0.0.0/16のすべての詳細は、長さ16の30.0.0.0/8のすべての詳細30.9.0.0/16など、30.0.0.0/8のすべての詳細は、30.9.96/28などの長さ24〜32です。
Route Set Name A route set name matches the set of routes that are members of the set. A route set name may be a name of a route-set object, an AS number, or a name of an as-set object (AS numbers and as-set names implicitly define route sets; please see Section 5.3). For example:
ルートセット名ルートセット名は、セットのメンバーであるルートのセットと一致します。ルートセット名は、ルートセットオブジェクトの名前、AS番号、またはASセットオブジェクトの名前である場合があります（数字とASセット名が暗黙的にルートセットを定義します。セクション5.3を参照）。例えば：
aut-num: AS1 import: from AS2 accept AS2 import: from AS2 accept AS-FOO import: from AS2 accept RS-FOO
Aut-Num：AS1インポート：AS2からAS2を受け入れます。
The keyword PeerAS can be used instead of the AS number of the peer AS. PeerAS is particularly useful when the peering is specified using an AS expression. For example:
キーワードのPeerasは、ピアの数としての代わりに使用できます。Peerasは、AS式を使用してピアリングが指定されている場合に特に役立ちます。例えば：
as-set: AS-FOO members: AS2, AS3
AS-SET：As-Fooメンバー：AS2、AS3
aut-num: AS1 import: from AS-FOO accept PeerAS
Aut-Num：AS1インポート：As-FooからPeerasを受け入れます
is same as:
と同じです：
aut-num: AS1 import: from AS2 accept AS2 import: from AS3 accept AS3
Aut-Num：AS1インポート：AS2からAS2を受け入れる：AS3からAS3を受け入れる
A route set name can also be followed by one of the operators '^-', '^+', example, { 5.0.0.0/8, 6.0.0.0/8 }^+ equals { 5.0.0.0/8^+, 6.0.0.0/8^+ }, and AS1^- equals all the exclusive more specifics of routes originated by AS1.
ルートセット名の後に、オペレーターの1つの^ - '、'^ '、例、{5.0.0.0/8、6.0.0.0/8}^ equals {5.0.0.0/8^、6.0.0.0も続くことができます。/8^}、およびAS1^ - は、AS1から発信されるルートのすべての排他的な詳細な詳細に等しくなります。
AS Path Regular Expressions An AS-path regular expression can be used as a policy filter by enclosing the expression in `<' and `>'. An AS-path policy filter matches the set of routes which traverses a sequence of ASes matched by the AS-path regular expression. A router can check this using the AS_PATH attribute in the Border Gateway Protocol [19], or the RD_PATH attribute in the Inter-Domain Routing Protocol [18].
パス正規表現として、式を「<'および `>」に囲むことにより、ポリシーフィルターとして使用できます。As-Pathポリシーフィルターは、As-Path正規表現と一致するASEのシーケンスを横断するルートのセットと一致します。ルーターは、Border Gateway Protocol [19]のAS_Path属性またはドメイン間ルーティングプロトコル[18]のRD_PATH属性を使用してこれを確認できます。
AS-path Regular Expressions are POSIX compliant regular expressions over the alphabet of AS numbers. The regular expression constructs are as follows:
As-Pathの正規表現は、As数のアルファベット上のPOSIX準拠の正規表現です。正規表現構造は次のとおりです。
ASN where ASN is an AS number. ASN matches the AS-path that is of length 1 and contains the corresponding AS number (e.g. AS-path regular expression AS1 matches the AS-path "1").
ASNここで、ASNはAS数です。ASNは、長さ1であるAs-Pathと一致し、対応する数字を含みます（たとえば、As-Path正規表現AS1はAs-Path "1"に一致します）。
The keyword PeerAS can be used instead of the AS number of the peer AS.
キーワードのPeerasは、ピアの数としての代わりに使用できます。
AS-set where AS-set is an AS set name. AS-set matches the AS-paths that is matched by one of the ASes in the AS-set.
ASセットASセットはAS SET名です。ASセットは、ASセットのASESの1つと一致するASパスと一致します。
. matches the AS-paths matched by any AS number.
。AS ASの数と一致するASパスと一致します。
[...] is an AS number set. It matches the AS-paths matched by the AS numbers listed between the brackets. The AS numbers in the set are separated by white space characters. If a `-' is used between two AS numbers in this set, all AS numbers between the two AS numbers are included in the set. If an as-set name is listed, all AS numbers in the as-set are included.
[...]はAS番号セットです。ブラケットの間にリストされているAS数字と一致するASパスと一致します。セット内のAS数字は、ホワイトスペース文字によって区切られています。このセットの2つとして ` - 'が2つとして使用されている場合、2つの間の数値としてすべてがセットに含まれています。AS-SET名がリストされている場合、AS AS-SETのすべての数字が含まれています。
[^...] is a complemented AS number set. It matches any AS-path which is not matched by the AS numbers in the set.
[^...]は、数字セットとして補完されます。セットのAS数字と一致しないASパスと一致します。
^ Matches the empty string at the beginning of an AS-path.
^パスの先頭にある空の文字列に一致します。
$ Matches the empty string at the end of an AS-path.
$ As-Pathの端にある空の文字列に一致します。
We next list the regular expression operators in the decreasing order of evaluation. These operators are left associative, i.e. performed left to right.
次に、評価の減少順序で正規表現演算子をリストします。これらの演算子は連想的に残されています。つまり、左から右に実行されます。
Unary postfix operators * + ? {m} {m,n} {m,}
For a regular expression A, A* matches zero or more occurrences of
A; A+ matches one or more occurrences of A; A? matches zero or
one occurrence of A; A{m} matches m occurrence of A; A{m,n}
matches m to n occurrence of A; A{m,} matches m or more occurrence
of A. For example, [AS1 AS2]{2} matches AS1 AS1, AS1 AS2, AS2 AS1,
and AS2 AS2.
Unary postfix operators ~* ~+ ~{m} ~{m,n} ~{m,} These operators have similar functionality as the corresponding operators listed above, but all occurrences of the regular expression has to match the same pattern. For example, [AS1 AS2]~{2} matches AS1 AS1 and AS2 AS2, but it does not match AS1 AS2 and AS2 AS1.
Unary Postfix演算子〜* 〜〜 {m}〜{m、n}〜{m、}これらの演算子は、上記の対応する演算子と同様の機能を持っていますが、正規表現のすべての発生は同じパターンと一致する必要があります。たとえば、[AS1 AS2]〜{2}はAS1 AS1およびAS2 AS2と一致しますが、AS1 AS2およびAS2 AS1と一致しません。
Binary catenation operator This is an implicit operator and exists between two regular expressions A and B when no other explicit operator is specified. The resulting expression A B matches an AS-path if A matches some prefix of the AS-path and B matches the rest of the AS-path.
バイナリカテネーションオペレーターこれは暗黙的な演算子であり、他の明示的な演算子が指定されていない場合、2つの正規式AとBの間に存在します。結果の式Aは、As-PathとBのいくつかの接頭辞と一致する場合、As-PathとAs-Pathと一致する場合、As-Pathと一致します。
Binary alternative (or) operator | For a regular expressions A and B, A | B matches any AS-path that is matched by A or B.
バイナリ代替（または）演算子|正規表現aとbの場合、a |bは、AまたはBによって一致するAs-Pathと一致します
Parenthesis can be used to override the default order of evaluation. White spaces can be used to increase readability.
括弧を使用して、デフォルトの評価順序をオーバーライドできます。白いスペースを使用して、読みやすさを向上させることができます。
The following are examples of AS-path filters:
以下は、As-Pathフィルターの例です。
<AS3> <^AS1> <AS2$> <^AS1 AS2 AS3$> <^AS1 .* AS2$>.
<as3> <^as1> <as2 $> <^as1 as2 as3 $> <^as1。* as2 $>。
The first example matches any route whose AS-path contains AS3, the second matches routes whose AS-path starts with AS1, the third matches routes whose AS-path ends with AS2, the fourth matches routes whose AS-path is exactly "1 2 3", and the fifth matches routes whose AS-path starts with AS1 and ends in AS2 with any number of AS numbers in between.
最初の例は、As-PathがAS3を含むルートと一致します。2番目のマッチはASパスがAS1で始まるルートです。3番目のマッチはAS2で終わるルートです。3 "、および5番目のマッチは、As-PathがAS1で始まり、AS2で終了するルートを任意の数のAS ASの数字で終了します。
Composite Policy Filters The following operators (in decreasing order of evaluation) can be used to form composite policy filters:
複合ポリシーフィルター次の演算子（評価の順序の減少）を使用して、複合ポリシーフィルターを形成できます。
NOT Given a policy filter x, NOT x matches the set of routes that are not matched by x. That is it is the negation of policy filter x.
ポリシーフィルターxが与えられていないため、xではなく、xと一致しないルートのセットと一致します。それは、ポリシーフィルターxの否定です。
AND Given two policy filters x and y, x AND y matches the intersection of the routes that are matched by x and that are matched by y.
2つのポリシーフィルターxとy、x、yは、xと一致し、yによって一致するルートの交差点と一致します。
OR Given two policy filters x and y, x OR y matches the union of the routes that are matched by x and that are matched by y.
または、2つのポリシーフィルターxとy、x、またはyが与えられ、xと一致し、yによって一致するルートの結合と一致します。
Note that an OR operator can be implicit, that is `x y' is equivalent to `x OR y'.
またはオペレーターは暗黙的である可能性があり、「x y」は「xまたはy」に相当することに注意してください。
E.g.
NOT {128.9.0.0/16, 128.8.0.0/16}
AS226 AS227 OR AS228
AS226 AND NOT {128.9.0.0/16}
AS226 AND {0.0.0.0/0^0-18}
The first example matches any route except 128.9.0.0/16 and 128.8.0.0/16. The second example matches the routes of AS226, AS227 and AS228. The third example matches the routes of AS226 except 128.9.0.0/16. The fourth example matches the routes of AS226 whose length are not longer than 18.
最初の例は、128.9.0.0/16および128.8.0.0/16を除くルートと一致します。2番目の例は、AS226、AS227、AS228のルートと一致しています。3番目の例は、128.9.0.0/16を除くAS226のルートと一致します。4番目の例は、長さが18以下ではないAS226のルートと一致します。
Routing Policy Attributes Policy filters can also use the values of other attributes for comparison. The attributes whose values can be used in policy filters are specified in the RPSL dictionary. Please refer to Section 7 for details. An example using the the BGP community attribute is shown below:
ルーティングポリシー属性ポリシーフィルターは、比較のために他の属性の値を使用することもできます。ポリシーフィルターで値を使用できる属性は、RPSL辞書で指定されています。詳細については、セクション7を参照してください。BGPコミュニティ属性を使用した例を以下に示します。
aut-num: AS1 export: to AS2 announce AS1 AND NOT community(NO_EXPORT)
Aut-Num：AS1 Export：AS2にAS1を発表してコミュニティではなく発表（no_export）
Filters using the routing policy attributes defined in the dictionary are evaluated before evaluating the operators AND, OR and NOT.
辞書で定義されているルーティングポリシー属性を使用したフィルターは、演算子を評価する前に評価されます。
Filter Set Name A filter set name matches the set of routes that are matched by its filter attribute. Note that the filter attribute of a filter set, can recursively refer to other filter set names. For example in Figure 17, fltr-foo matches { 5.0.0.0/8, 6.0.0.0/8 }, and fltr-bar matches AS1'S routes or { 5.0.0.0/8, 6.0.0.0/8 } if their as path contained AS2.
フィルターセット名フィルターセット名は、そのフィルター属性と一致するルートのセットに一致します。フィルターセットのフィルター属性は、他のフィルターセット名を再帰的に参照できることに注意してください。たとえば、図17では、FLTR-FOOは{5.0.0.0/8、6.0.0.0/8}を一致させ、FLTR-BARはAS1のルートまたは{5.0.0.0/8、6.0.0.0/8}を一致させます。AS2。
The attributes of the rtr-set class are shown in Figure 18. The rtr-set attribute defines the name of the set. It is an RPSL name that starts with "rtrs-". The members attribute lists the members of the set. The members attribute is a list of inet-rtr names, ipv4_addresses or other rtr-set names.
RTRセットクラスの属性を図18に示します。RTRセット属性は、セットの名前を定義します。「RTRS-」で始まるRPSL名です。メンバー属性は、セットのメンバーをリストします。メンバー属性は、INET-RTR名、IPv4_Addresses、またはその他のRTRセット名のリストです。
Attribute Value Type
rtr-set <object-name> mandatory, single-valued,
class key
members list of <inet-rtr-names> or optional, multi-valued
<rtr-set-names>
or <ipv4_addresses>
mbrs-by-ref list of <mntner-names> optional, multi-valued
Figure 18: rtr-set Class Attributes
図18：RTRセットクラス属性
Figure 19 presents two rtr-set objects. The set rtrs-foo contains two routers, namely rtr1.isp.net and rtr2.isp.net. The set rtrs-bar contains the members of the set rtrs-foo and rtr3.isp.net, that is it contains rtr1.isp.net, rtr2.isp.net, rtr3.isp.net.
図19は、2つのRTRセットオブジェクトを示しています。SET RTRS-FOOには、Rtr1.isp.netとrtr2.isp.netの2つのルーターが含まれています。SET RTRS-BARには、set rtrs-fooおよびrtr3.isp.netのメンバーが含まれています。つまり、rtr1.isp.net、rtr2.isp.net、rtr3.isp.netが含まれています。
rtr-set: rtrs-foo rtr-set: rtrs-bar
members: rtr1.isp.net, rtr2.isp.net members: rtr3.isp.net, rtrs-foo
Figure 19: rtr-set objects.
図19：RTRセットオブジェクト。
The mbrs-by-ref attribute is a list of maintainer names or the keyword ANY. If this attribute is used, the router set also includes routers whose inet-rtr objects are registered by one of these maintainers and whose member-of attribute refers to the name of this router set. If the value of a mbrs-by-ref attribute is ANY, any inet-rtr object referring to the router set is a member of the set. If the mbrs-by-ref attribute is missing, only the routers listed in the members attribute are members of the set.
MBRS-by-ref属性は、メンテナー名またはキーワードのリストです。この属性を使用すると、ルーターセットには、これらのメンテナーのいずれかによってINET-RTRオブジェクトが登録されており、メンバーオブ属性がこのルーターセットの名前を指すルーターも含まれています。MBRS-by-REF属性の値がいずれかである場合、ルーターセットを参照するINET-RTRオブジェクトはセットのメンバーです。MBRS-REF属性が欠落している場合、メンバー属性にリストされているルーターのみがセットのメンバーです。
rtr-set: rtrs-foo members: rtr1.isp.net, rtr2.isp.net mbrs-by-ref: MNTR-ME
rtr-set：rtrs-fooメンバー：rtr1.isp.net、rtr2.isp.net mbrs-by-ref：mntr-me
inet-rtr: rtr3.isp.net local-as: as1 ifaddr: 1.1.1.1 masklen 30 member-of: rtrs-foo mnt-by: MNTR-ME
inet-rtr：rtr3.isp.net local-as：as1ifaddr：1.1.1.1 masklen 30メンバー：rtrs-foomnt-by：mntr-me
Figure 20: rtr-set objects.
図20：RTRセットオブジェクト。
Figure 20 presents an example rtr-set object that uses the mbrs-by-ref attribute. The set rtrs-foo contains rtr1.isp.net, rtr2.isp.net and rtr3.isp.net.
図20は、MBRS-REF属性を使用するRTRセットオブジェクトの例を示しています。SET RTRS-FOOには、rtr1.isp.net、rtr2.isp.net、rtr3.isp.netが含まれています。
The attributes of the peering-set class are shown in Figure 21. A peering-set object defines a set of peerings that are listed in its peering attributes. The peering-set attribute defines the name of the set. It is an RPSL name that starts with "prng-".
ピアリングセットクラスの属性を図21に示します。ピアリングセットオブジェクトは、ピアリング属性にリストされている一連のピーリングを定義します。ピアリングセット属性は、セットの名前を定義します。「PRNG-」で始まるRPSL名です。
Attribute Value Type peering-set <object-name> mandatory, single-valued, class key peering <peering> mandatory, multi-valued
属性値タイプのピアリングセット<Object-name>必須、シングル値、クラスキーピーリング<ピアリング>必須、マルチ値
Figure 21: filter Class Attributes
図21：クラス属性をフィルター
The peering attribute defines a peering that can be used for importing or
ピアリング属性は、インポートに使用できるピアリングまたは
---------------------- ----------------------
| 7.7.7.1 |-------| |-------| 7.7.7.2 |
| | ======== | |
| AS1 | EX1 |-------| 7.7.7.3 AS2 |
| | | |
| 9.9.9.1 |------ ------| 9.9.9.2 |
---------------------- | | ----------------------
===========
| EX2
---------------------- |
| 9.9.9.3 |---------
| |
| AS3 |
----------------------
Figure 22: Example topology consisting of three ASes, AS1, AS2, and AS3; two exchange points, EX1 and EX2; and six routers.
図22：AS1、AS2、およびAS3の3つのASEで構成されるトポロジの例。EX1とEX2の2つの交換ポイント。および6つのルーター。
exporting routes. In describing peerings, we are going to use the topology of Figure 22. In this topology, there are three ASes, AS1, AS2, and AS3; two exchange points, EX1 and EX2; and six routers. Routers connected to the same exchange point peer with each other and exchange routing information. That is, 7.7.7.1, 7.7.7.2 and 7.7.7.3 peer with each other; 9.9.9.1, 9.9.9.2 and 9.9.9.3 peer with each other.
エクスポートルート。ピアリングを説明する際に、図22のトポロジーを使用します。このトポロジには、AS1、AS2、およびAS3の3つのASEがあります。EX1とEX2の2つの交換ポイント。および6つのルーター。同じ交換ポイントピアに接続されているルーターは、ルーティング情報を交換します。つまり、7.7.7.1、7.7.7.2、7.7.7.3のピア。9.9.9.1、9.9.9.2および9.9.9.3は、互いにピア。
The syntax of a peering specification is:
ピアリング仕様の構文は次のとおりです。
<as-expression> [<router-expression-1>] [at <router-expression-2>]
| <peering-set-name>
where <as-expression> is an expression over AS numbers and AS sets using operators AND, OR, and EXCEPT, and <router-expression-1> and <router-expression-2> are expressions over router IP addresses, inet-rtr names, and rtr-set names using operators AND, OR, and EXCEPT. The binary "EXCEPT" operator is the set subtraction operator and has the same precedence as the operator AND (it is semantically equivalent to "AND NOT" combination). That is "(AS1 OR AS2) EXCEPT AS2" equals "AS1".
ここで、<as-expression>は数字としての式であり、演算子を使用してセットとして、および、および、<router-expression -1>および<router-expression-2>はルーターIPアドレスを介した式、inet-rtrオペレーターを使用した名前、およびrtrセット名と、または除く。バイナリ「除く」演算子は、セット減算演算子であり、演算子と同じ優先順位を持ち、（「組み合わせではなく」と同等です）。つまり、AS2が「AS1」に等しい」（AS1またはAS2）です。
This form identifies all the peerings between any local router in <router-expression-2> to any of their peer routers in <router-expression-1> in the ASes in <as-expression>. If <router-expression-2> is not specified, it defaults to all routers of the local AS that peer with ASes in <as-expression>. If <router-expression-1> is not specified, it defaults to all routers of the peer ASes in <as-expression> that peer with the local AS.
このフォームは、<ルーター - 発現-2>のローカルルーター間のすべてのピアリングを、<as-expression>のASEの<router-expression-1>のピアルーターのいずれかに識別します。<router-expression-2>が指定されていない場合、<as-expression>でASEを使用したそのピアとして、ローカルのすべてのルーターにデフォルトです。<router-expression-1>が指定されていない場合、ローカルASとピアが<As-Expression>のピアASEのすべてのルーターにデフォルトです。
If a <peering-set-name> is used, the peerings are listed in the corresponding peering-set object. Note that the peering-set objects can be recursive.
A <Peering-Set-Name>を使用すると、ピーリングは対応するピアリングセットオブジェクトにリストされます。ピアリングセットオブジェクトは再帰的である可能性があることに注意してください。
Many special forms of this general peering specification is possible. The following examples illustrate the most common cases, using the import attribute of the aut-num class. In the following example 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2.
この一般的なピアリング仕様の多くの特別な形式が可能です。次の例は、Aut-Numクラスのインポート属性を使用して、最も一般的なケースを示しています。次の例では、7.7.7.0/16から7.7.7.2から輸入128.9.0.0/16。
(1) aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1 accept { 128.9.0.0/16 }
In the following example 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2 and 7.7.7.3.
次の例では、7.7.7.2および7.7.7.3から128.9.0.0/16を輸入します。
(2) aut-num: AS1
import: from AS2 at 7.7.7.1 accept { 128.9.0.0/16 }
In the following example 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2 and 7.7.7.3, and 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2.
次の例では、7.7.7.2および7.7.7.2および7.7.7.3から128.9.0.0/16を輸入し、9.9.9.1は9.9.9.2から128.9.0.0.0/16を輸入します。
(3) aut-num: AS1
import: from AS2 accept { 128.9.0.0/16 }
In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2 and 9.9.9.3.
次の例9.9.9.1では、9.9.9.2および9.9.9.3から128.9.0.0/16を輸入します。
(4) as-set: AS-FOO members: AS2, AS3
(4) AS-SET：As-Fooメンバー：AS2、AS3
aut-num: AS1
import: from AS-FOO at 9.9.9.1 accept { 128.9.0.0/16 }
In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2 and 9.9.9.3, and 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2 and 7.7.7.3.
次の例9.9.9.1では、9.9.9.2および9.9.9.3から128.9.0.0/16を輸入し、7.7.7.2および7.7.7.3から7.7.7.1から128.9.0.0.0/16を輸入します。
(5) aut-num: AS1
import: from AS-FOO accept { 128.9.0.0/16 }
In the following example AS1 imports 128.9.0.0/16 from AS3 at router 9.9.9.1
次の例では、AS1はルーター9.9.9.1でAS3から128.9.0.0/16をインポートします
(6) aut-num: AS1 import: from AS-FOO and not AS2 at not 7.7.7.1 accept { 128.9.0.0/16 }
(6) Aut-Num：AS1インポート：AS-FOOからAS2ではなく7.7.7.1を受け入れます{128.9.0.0/16}
This is because "AS-FOO and not AS2" equals AS3 and "not 7.7.7.1" equals 9.9.9.1.
これは、「As-FooおよびAs2ではない」はAS3に等しく、「7.7.7.1ではない」が9.9.9.1に等しいためです。
In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2 and 9.9.9.3.
次の例9.9.9.1では、9.9.9.2および9.9.9.3から128.9.0.0/16を輸入します。
(7) peering-set: prng-bar peering: AS1 at 9.9.9.1
(7) ピアリングセット：PRNG-BARピアリング：AS1 at 9.9.9.1
peering-set: prng-foo peering: prng-bar peering: AS2 at 9.9.9.1
ピアリングセット：prng-foo peering：prng-bar peering：as2 at 9.9.9.1
aut-num: AS1
import: from prng-foo accept { 128.9.0.0/16 }
6 aut-num Class
6 Aut-Numクラス
Routing policies are specified using the aut-num class. The attributes of the aut-num class are shown in Figure 23. The value of the aut-num attribute is the AS number of the AS described by this object. The as-name attribute is a symbolic name (in RPSL name syntax) of the AS. The import, export and default routing policies of the AS are specified using import, export and default attributes respectively.
ルーティングポリシーは、Aut-Numクラスを使用して指定されています。Aut-Numクラスの属性を図23に示します。Aut-Num属性の値は、このオブジェクトで説明されているASの数です。As-Name属性は、ASのシンボリック名（RPSL名構文）です。インポート、エクスポート、およびデフォルトのルーティングポリシーは、それぞれインポート、エクスポート、デフォルト属性を使用して指定されています。
Attribute Value Type aut-num <as-number> mandatory, single-valued, class key as-name <object-name> mandatory, single-valued member-of list of <as-set-names> optional, multi-valued import see Section 6.1 optional, multi valued export see Section 6.2 optional, multi valued default see Section 6.5 optional, multi valued
属性値タイプタイプaut-num <as-Number>必須、シングル値、クラスキーAs-name <object-name>必須、<asset-names>オプション、マルチ値のインポートのリストのシングル値メンバーのメンバーセクション6.1を参照オプション、多額のエクスポートセクション6.2オプション、多額のデフォルトを参照
Figure 23: aut-num Class Attributes
図23：Aut-Numクラスの属性
In RPSL, an import policy is divided into import policy expressions. Each import policy expression is specified using an import attribute. The import attribute has the following syntax (we will extend this syntax later in Sections 6.3 and 6.6):
RPSLでは、インポートポリシーはインポートポリシーの表現に分けられます。各インポートポリシー式は、インポート属性を使用して指定されます。Import属性には次の構文があります（この構文をセクション6.3および6.6で拡張します）：
import: from <peering-1> [action <action-1>]
. . .
from <peering-N> [action <action-N>]
accept <filter>
The action specification is optional. The semantics of an import attribute is as follows: the set of routes that are matched by <filter> are imported from all the peers in <peerings>; while importing routes at <peering-M>, <action-M> is executed.
アクション仕様はオプションです。インポート属性のセマンティクスは次のとおりです。<filter>によって一致するルートのセットは、<peerings>のすべてのピアからインポートされます。<peering-m>でルートをインポートすると、<cation-m>が実行されます。
E.g.
aut-num: AS1
import: from AS2 action pref = 1; accept { 128.9.0.0/16 }
This example states that the route 128.9.0.0/16 is accepted from AS2 with preference 1. We already presented how peerings (see Section 5.6) and filters (see Section 5.4) are specified. We next present how to specify actions.
この例では、Route 128.9.0.0/16はAS2からPrecreference 1から受け入れられていることを示しています。次に、アクションを指定する方法を提示します。
Policy actions in RPSL either set or modify route attributes, such as assigning a preference to a route, adding a BGP community to the BGP community path attribute, or setting the MULTI-EXIT-DISCRIMINATOR attribute. Policy actions can also instruct routers to perform special operations, such as route flap damping.
RPSLのポリシーアクションは、ルートへの優先度の割り当て、BGPコミュニティパス属性へのBGPコミュニティの追加、マルチエキシットディスクリミネーター属性の設定など、ルート属性を設定または変更するかどうかのいずれかです。また、ポリシーアクションは、ルーターがルートフラップダンピングなどの特殊作業を実行するように指示することもできます。
The routing policy attributes whose values can be modified in policy actions are specified in the RPSL dictionary. Please refer to Section 7 for a list of these attributes. Each action in RPSL is terminated by the semicolon character (';'). It is possible to form composite policy actions by listing them one after the other. In a composite policy action, the actions are executed left to right. For example,
ポリシーアクションで値を変更できるルーティングポリシー属性は、RPSL辞書で指定されています。 これらの属性のリストについては、セクション7を参照してください。 RPSLの各アクションは、セミコロン文字（ ';'）によって終了します。 複合ポリシーアクションを次々にリストすることにより、コンポジットポリシーアクションを形成することが可能です。 複合ポリシーアクションでは、アクションは左から右に実行されます。 例えば、
aut-num: AS1
import: from AS2
action pref = 10; med = 0; community.append(10250, 3561:10);
accept { 128.9.0.0/16 }
sets pref to 10, med to 0, and then appends 10250 and 3561:10 to the BGP community path attribute. The pref attribute is the inverse of the local-pref attribute (i.e. local-pref == 65535 - pref). A route with a local-pref attribute is always preferred over a route without one.
セットは10に、MEDは0になり、次に10250および3561：10をBGPコミュニティパス属性に追加します。Pref属性は、ローカル-PREF属性の逆です（つまり、local-pref == 65535-pref）。ローカルプレフ属性を備えたルートは、常に1つのルートのないルートよりも推奨されます。
aut-num: AS1
import: from AS2 action pref = 1;
from AS3 action pref = 2;
accept AS4
The above example states that AS4's routes are accepted from AS2 with preference 1, and from AS3 with preference 2 (routes with lower integer preference values are preferred over routes with higher integer preference values).
上記の例では、AS4のルートは優先順位1のAS2から受け入れられ、AS3から優先順位2から受け入れられていることが示されています（整数の優先度値が低いルートでは、整数設定値が高いルートよりも優先されます）。
aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 1;
from AS2 action pref = 2;
accept AS4
The above example states that AS4's routes are accepted from AS2 on peering 7.7.7.1-7.7.7.2 with preference 1, and on any other peering with AS2 with preference 2.
上記の例では、AS4のルートは、Peering 7.7.7.1-7.7.7.2でAS2からAS2から受け入れられていることを示しています。
Similarly, an export policy expression is specified using an export attribute. The export attribute has the following syntax:
同様に、エクスポート属性を使用してエクスポートポリシー式が指定されています。エクスポート属性には次の構文があります。
export: to <peering-1> [action <action-1>]
. . .
to <peering-N> [action <action-N>]
announce <filter>
The action specification is optional. The semantics of an export attribute is as follows: the set of routes that are matched by <filter> are exported to all the peers specified in <peerings>; while exporting routes at <peering-M>, <action-M> is executed.
アクション仕様はオプションです。エクスポート属性のセマンティクスは次のとおりです。<filter>によって一致するルートのセットは、<peerings>で指定されたすべてのピアにエクスポートされます。<peering-m>でルートをエクスポートすると、<アクション-M>が実行されます。
E.g.
aut-num: AS1
export: to AS2 action med = 5; community .= { 70 };
announce AS4
In this example, AS4's routes are announced to AS2 with the med attribute's value set to 5 and community 70 added to the community list.
この例では、AS4のルートはAS2に発表され、MED属性の値が5に設定され、コミュニティ70がコミュニティリストに追加されます。
Example:
例：
aut-num: AS1 export: to AS-FOO announce ANY
Aut-Num：AS1 Export：As-Fooへの発表
In this example, AS1 announces all of its routes to the ASes in the set AS-FOO.
この例では、AS1は、セットAs-FooのASESへのすべてのルートを発表します。
The more complete syntax of the import and export attributes are as follows:
インポートおよびエクスポート属性のより完全な構文は次のとおりです。
import: [protocol <protocol-1>] [into <protocol-2>]
from <peering-1> [action <action-1>]
. . .
from <peering-N> [action <action-N>]
accept <filter>
export: [protocol <protocol-1>] [into <protocol-2>]
to <peering-1> [action <action-1>]
. . .
to <peering-N> [action <action-N>]
announce <filter>
Where the optional protocol specifications can be used for specifying policies for other routing protocols, or for injecting routes of one protocol into another protocol, or for multi-protocol routing policies. The valid protocol names are defined in the dictionary. The <protocol-1> is the name of the protocol whose routes are being exchanged. The <protocol-2> is the name of the protocol which is receiving these routes. Both <protocol-1> and <protocol-2> default to the Internet Exterior Gateway Protocol, currently BGP.
オプションのプロトコル仕様を使用して、他のルーティングプロトコルのポリシーを指定したり、あるプロトコルのルートを別のプロトコルに注入したり、マルチプロトコルルーティングポリシーに注入したりできます。有効なプロトコル名は辞書で定義されています。<protocol-1>は、ルートが交換されているプロトコルの名前です。<プロトコル2>は、これらのルートを受信しているプロトコルの名前です。<Protocol-1>と<Protocol-2>の両方が、現在BGPであるインターネット外部ゲートウェイプロトコルにデフォルトです。
In the following example, all interAS routes are injected into RIP.
次の例では、すべてのInterasルートがRIPに注入されます。
aut-num: AS1 import: from AS2 accept AS2 export: protocol BGP4 into RIP to AS1 announce ANY
Aut-Num：AS1インポート：AS2からAS2エクスポートを受け入れる：プロトコルBGP4がRIPにAS1を発表する
In the following example, AS1 accepts AS2's routes including any more specifics of AS2's routes, but does not inject these extra more specific routes into OSPF.
次の例では、AS1はAS2のルートの詳細を含むAS2のルートを受け入れますが、これらの特別な特定のルートをOSPFに注入しません。
aut-num: AS1 import: from AS2 accept AS2^+ export: protocol BGP4 into OSPF to AS1 announce AS2
Aut-Num：AS1インポート：AS2からAS2^エクスポートを受け入れる：プロトコルBGP4がOSPFにAS1 AS2を発表する
In the following example, AS1 injects its static routes (routes which are members of the set AS1:RS-STATIC-ROUTES) to the interAS routing protocol and appends AS1 twice to their AS paths.
次の例では、AS1は静的ルート（SET AS1：RS-Static-routesのメンバーであるルート）をInterasルーティングプロトコルに注入し、AS1をAS ASパスに2回追加します。
aut-num: AS1 import: protocol STATIC into BGP4 from AS1 action aspath.prepend(AS1, AS1); accept AS1:RS-STATIC-ROUTES
Aut-Num：AS1インポート：AS1アクションASPATH.PREPT（AS1、AS1）からBGP4への静的プロトコル。AS1：rs-static-routesを受け入れます
In the following example, AS1 imports different set of unicast routes for multicast reverse path forwarding from AS2:
次の例では、AS1は、AS2からのマルチキャストリバースパスの転送用の異なるユニキャストルートセットをインポートします。
aut-num: AS1 import: from AS2 accept AS2 import: protocol IDMR from AS2 accept AS2:RS-RPF-ROUTES
Aut-Num：AS1インポート：AS2からAS2を受け入れる：AS2からAS2を受け入れるプロトコルIDMR：RS-RPF-Routes
It is possible that the same peering can be covered by more that one peering specification in a policy expression. For example:
同じピアリングが、ポリシー表現における1つのピアリング仕様よりも多くカバーできる可能性があります。例えば：
aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 2;
from AS2 7.7.7.2 at 7.7.7.1 action pref = 1;
accept AS4
This is not an error, though definitely not desirable. To break the ambiguity, the action corresponding to the first peering specification is used. That is the routes are accepted with preference 2. We call this rule as the specification-order rule.
これはエラーではありませんが、絶対に望ましくはありません。あいまいさを破るために、最初のピアリング仕様に対応するアクションが使用されます。これは、ルートが優先順位で受け入れられることです。このルールを仕様順序ルールと呼びます。
Consider the example:
例を考えてみましょう：
aut-num: AS1
import: from AS2 action pref = 2;
from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; dpa = 5;
accept AS4
where both peering specifications cover the peering 7.7.7.1-7.7.7.2, though the second one covers it more specifically. The specification order rule still applies, and only the action "pref = 2" is executed. In fact, the second peering-action pair has no use since the first peering-action pair always covers it. If the intended policy was to accept these routes with preference 1 on this particular peering and with preference 2 in all other peerings, the user should have specified:
両方のピアリング仕様がピアリング7.7.7.1-7.7.7.2をカバーしていますが、2番目のものはより具体的にカバーしています。仕様順序ルールは引き続き適用され、アクション「pref = 2」のみが実行されます。実際、最初のピアリングアクションペアが常にカバーしているため、2番目のピアリングアクションペアは役に立ちません。意図されたポリシーが、この特定のピアリングで優先され、他のすべてのピーリングで優先順位2でこれらのルートを受け入れることであった場合、ユーザーは次のように指定する必要があります。
aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; dpa = 5;
from AS2 action pref = 2;
accept AS4
It is also possible that more than one policy expression can cover the same set of routes for the same peering. For example:
また、複数のポリシー表現が同じピアリングに対して同じルートセットをカバーできる可能性もあります。例えば：
aut-num: AS1
import: from AS2 action pref = 2; accept AS4
import: from AS2 action pref = 1; accept AS4
In this case, the specification-order rule is still used. That is, AS4's routes are accepted from AS2 with preference 2. If the filters were overlapping but not exactly the same:
この場合、仕様順序ルールが引き続き使用されています。つまり、AS4のルートはAS2から受け入れられています。2。フィルターが重複しているがまったく同じではない場合：
aut-num: AS1
import: from AS2 action pref = 2; accept AS4
import: from AS2 action pref = 1; accept AS4 OR AS5
the AS4's routes are accepted from AS2 with preference 2 and however AS5's routes are also accepted, but with preference 1.
AS4のルートはAS2からPreference 2から受け入れられますが、AS5のルートも受け入れられますが、優先順位があります。
We next give the general specification order rule for the benefit of the RPSL implementors. Consider two policy expressions:
次に、RPSL実装者の利益のために一般的な仕様順序ルールを提供します。2つのポリシー式を検討してください。
aut-num: AS1 import: from peerings-1 action action-1 accept filter-1 import: from peerings-2 action action-2 accept filter-2
Aut-Num：AS1インポート：Peerings-1 Action Action-1 Accept Filter-1インポート：Peerings-2 Action Action-2 Accept Filter-2
The above policy expressions are equivalent to the following three expressions where there is no ambiguity:
上記のポリシー表現は、あいまいさがない次の3つの表現と同等です。
aut-num: AS1 import: from peerings-1 action action-1 accept filter-1 import: from peerings-3 action action-2 accept filter-2 AND NOT filter-1 import: from peerings-4 action action-2 accept filter-2
Aut-Num：AS1インポート：Peerings-1 Action Action-1 Accept Filter-1インポート：Peerings-3 Action Action-2 Acceat-2 Filter-1インポート：Peerings-4 Action Action-2 Accept-2フィルター-2
where peerings-3 are those that are covered by both peerings-1 and peerings-2, and peerings-4 are those that are covered by peerings-2 but not by peerings-1 ("filter-2 AND NOT filter-1" matches the routes that are matched by filter-2 but not by filter-1).
Peerings-3は、Peerings-1とPeerings-2の両方でカバーされているものであり、Peerings-4はPeerings-2で覆われているが、Peerings-1ではカバーされていないものです（ "フィルター-2およびフィルター-1ではない」一致するものフィルター-2によって一致するが、フィルター-1ではないルート）。
Example:
例：
aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1
action pref = 2;
accept {128.9.0.0/16}
import: from AS2
action pref = 1;
accept {128.9.0.0/16, 75.0.0.0/8}
Lets consider two peerings with AS2, 7.7.7.1-7.7.7.2 and 9.9.9.1- 9.9.9.2. Both policy expressions cover 7.7.7.1-7.7.7.2. On this peering, the route 128.9.0.0/16 is accepted with preference 2, and the route 75.0.0.0/8 is accepted with preference 1. The peering 9.9.9.1-9.9.9.2 is only covered by the second policy expressions. Hence, both the route 128.9.0.0/16 and the route 75.0.0.0/8 are accepted with preference 1 on peering 9.9.9.1-9.9.9.2.
AS2、7.7.7.1-7.7.7.2および9.9.9.1- 9.9.9.2の2つのピーリングを考えてみましょう。両方のポリシー式は7.7.7.1-7.7.7.2をカバーしています。このピアリングでは、ルート128.9.0.0/16は優先順位2で受け入れられ、ルート75.0.0.0/8は優先順位で受け入れられます。したがって、ルート128.9.0.0/16とルート75.0.0.0/8の両方が、ピアリング9.9.9.1-9.9.9.9.9.2の優先順位1で受け入れられます。
Note that the same ambiguity resolution rules also apply to export and default policy expressions.
同じあいまいさ解決ルールも、エクスポートおよびデフォルトのポリシー式に適用されることに注意してください。
Default routing policies are specified using the default attribute. The default attribute has the following syntax:
デフォルトのルーティングポリシーは、デフォルト属性を使用して指定されます。デフォルトの属性には、次の構文があります。
default: to <peering> [action <action>] [networks <filter>]
The <action> and <filter> specifications are optional. The semantics are as follows: The <peering> specification indicates the AS (and the router if present) is being defaulted to; the <action> specification, if present, indicates various attributes of defaulting, for example a relative preference if multiple defaults are specified; and the <filter> specifications, if present, is a policy filter. A router only uses the default policy if it received the routes matched by <filter> from this peer.
<アクション>および<filter>仕様はオプションです。セマンティクスは次のとおりです。<Peering>仕様は、as（および存在する場合のルーター）がデフォルトになっていることを示します。存在する場合は、<アクション>仕様は、デフォルトのさまざまな属性を示します。たとえば、複数のデフォルトが指定されている場合の相対的な好みを示します。<filter>仕様は、存在する場合、ポリシーフィルターです。ルーターは、このピアから<filter>に一致するルートを受信した場合にのみ、デフォルトのポリシーを使用します。
In the following example, AS1 defaults to AS2 for routing.
次の例では、AS1はルーティングのAS2にデフォルトです。
aut-num: AS1 default: to AS2
Aut-Num：AS1デフォルト：AS2へ
In the following example, router 7.7.7.1 in AS1 defaults to router 7.7.7.2 in AS2.
次の例では、AS1のルーター7.7.7.1は、AS2のルーター7.7.7.2にデフォルトです。
aut-num: AS1 default: to AS2 7.7.7.2 at 7.7.7.1
Aut-Num：AS1デフォルト：AS2 7.7.7.2 at 7.7.7.1
In the following example, AS1 defaults to AS2 and AS3, but prefers AS2 over AS3.
次の例では、AS1はAS2およびAS3にデフォルトですが、AS3よりもAS2を好みます。
aut-num: AS1
default: to AS2 action pref = 1;
default: to AS3 action pref = 2;
In the following example, AS1 defaults to AS2 and uses 128.9.0.0/16 as the default network.
次の例では、AS1はAS2にデフォルトであり、128.9.0.0/16をデフォルトネットワークとして使用します。
aut-num: AS1
default: to AS2 networks { 128.9.0.0/16 }
The import and export policies can be structured. We only reccomend structured policies to advanced RPSL users. Please feel free to skip this section.
インポートおよびエクスポートポリシーを構成できます。高度なRPSLユーザーに構造化されたポリシーのみをお勧めします。このセクションをお気軽にスキップしてください。
The syntax for a structured policy specification is the following:
構造化されたポリシー仕様の構文は次のとおりです。
<import-factor> ::= from <peering-1> [action <action-1>]
. . .
from <peering-N> [action <action-N>]
accept <filter>;
<import-term> ::= <import-factor> |
LEFT-BRACE
<import-factor>
. . .
<import-factor>
RIGHT-BRACE
<import-expression> ::= <import-term> |
<import-term> EXCEPT <import-expression> |
<import-term> REFINE <import-expression>
import: [protocol <protocol1>] [into <protocol2>]
<import-expression>
Please note the semicolon at the end of an <import-factor>. If the policy specification is not structured (as in all the examples in other sections), this semicolon is optional. The syntax and semantics for an <import-factor> is already defined in Section 6.1.
<Import-Factor>の終わりにあるセミコロンに注意してください。ポリシー仕様が構造化されていない場合（他のセクションのすべての例のように）、このセミコロンはオプションです。<Import-Factor>の構文とセマンティクスは、セクション6.1で既に定義されています。
An <import-term> is either a sequence of <import-factor>'s enclosed within matching braces (i.e. `{' and `}') or just a single <import-factor>. The semantics of an <import-term> is the union of <import-factor>'s using the specification order rule. An <import-expression> is either a single <import-term> or an <import-term> followed by one of the keywords "except" and "refine", followed by another <import-expression>. Note that our definition allows nested expressions. Hence there can be exceptions to exceptions, refinements to refinements, or even refinements to exceptions, and so on.
<Import-Term>は、マッチングブレース（つまり `{'および`}'）に囲まれた<intort-factor>のシーケンスのいずれか、または単一の<intort-factor>のいずれかです。<Import-Tertem>のセマンティクスは、仕様順序ルールを使用した<Import-Factor>のユニオンです。<インポートエクスプレッション>は、単一の<intempert-term>または<intempert-term>のいずれかに続いて、キーワードの1つが「 "and" refine "を除き、その後に別の<intert-expression>が続きます。私たちの定義により、ネストされた式が許可されていることに注意してください。したがって、例外、改良の改良、または例外の改良などの例外があります。
The semantics for the except operator is as follows: The result of an except operation is another <import-term>. The resulting policy set contains the policies of the right hand side but their filters are modified to only include the routes also matched by the left hand side. The policies of the left hand side are included afterwards and their filters are modified to exclude the routes matched by the right hand side. Please note that the filters are modified during this process but the actions are copied verbatim. When there are multiple levels of nesting, the operations (both except and refine) are performed right to left.
Opering Operatorのセマンティクスは次のとおりです。操作を除く結果は別の<intempert-Term>です。結果として得られるポリシーセットには、右側のポリシーが含まれていますが、フィルターは変更されており、左側にも一致するルートのみを含むように変更されています。左側のポリシーはその後含まれ、そのフィルターは右側に一致するルートを除外するように変更されます。このプロセス中にフィルターは変更されますが、アクションは逐語的にコピーされます。ネストに複数のレベルがある場合、操作（除く両方とも洗練の両方）が左から右に実行されます。
Consider the following example:
次の例を考えてみましょう。
import: from AS1 action pref = 1; accept as-foo;
except {
from AS2 action pref = 2; accept AS226;
except {
from AS3 action pref = 3; accept {128.9.0.0/16};
}
}
where the route 128.9.0.0/16 is originated by AS226, and AS226 is a member of the as set as-foo. In this example, the route 128.9.0.0/16 is accepted from AS3, any other route (not 128.9.0.0/16) originated by AS226 is accepted from AS2, and any other ASes' routes in as-foo is accepted from AS1.
ルート128.9.0.0/16はAS226によって発信され、AS226はAS Set As-Fooのメンバーです。この例では、ルート128.9.0.0/16はAS3から受け入れられ、AS226が発信する他のルート（128.9.0.0/16ではなく）はAS2から受け入れられ、ASFOOの他のASESルートはAS1から受け入れられます。
We can come to the same conclusion using the algebra defined above. Consider the inner exception specification:
上記の代数を使用して同じ結論に達することができます。内部例外仕様を考えてみましょう。
from AS2 action pref = 2; accept AS226;
except {
from AS3 action pref = 3; accept {128.9.0.0/16};
}
is equivalent to
に相当します
{
from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16};
from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16};
}
Hence, the original expression is equivalent to:
したがって、元の式は以下と同等です。
import: from AS1 action pref = 1; accept as-foo;
except {
from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16};
from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16};
}
which is equivalent to
これは同等です
import: {
輸入： {
from AS3 action pref = 3;
accept as-foo AND AS226 AND {128.9.0.0/16};
from AS2 action pref = 2;
accept as-foo AND AS226 AND NOT {128.9.0.0/16};
from AS1 action pref = 1;
accept as-foo AND NOT
(AS226 AND NOT {128.9.0.0/16} OR AS226 AND {128.9.0.0/16});
}
Since AS226 is in as-foo and 128.9.0.0/16 is in AS226, it simplifies to:
AS226はASFOOで、128.9.0.0/16はAS226にあるため、次のことを簡素化します。
import: {
from AS3 action pref = 3; accept {128.9.0.0/16};
from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16};
from AS1 action pref = 1; accept as-foo AND NOT AS226;
}
In the case of the refine operator, the resulting set is constructed by taking the cartasian product of the two sides as follows: for each policy l in the left hand side and for each policy r in the right hand side, the peerings of the resulting policy are the peerings common to both r and l; the filter of the resulting policy is the intersection of l's filter and r's filter; and action of the resulting policy is l's action followed by r's action. If there are no common peerings, or if the intersection of filters is empty, a resulting policy is not generated.
洗練オペレーターの場合、結果のセットは、次のように両側のカルタジア産物を採取することによって構築されます。左側の各ポリシーLについて、右側の各ポリシーrについて、結果のピアリングはポリシーは、RとLの両方に共通のピアリングです。結果のポリシーのフィルターは、LのフィルターとRのフィルターの交差点です。そして、結果のポリシーの行動は、Rのアクションに続くRのアクションです。一般的なピアリングがない場合、またはフィルターの交差点が空の場合、結果のポリシーは生成されません。
Consider the following example:
次の例を考えてみましょう。
import: { from AS-ANY action pref = 1; accept community(3560:10);
from AS-ANY action pref = 2; accept community(3560:20);
} refine {
from AS1 accept AS1;
from AS2 accept AS2;
from AS3 accept AS3;
}
Here, any route with community 3560:10 is assigned a preference of 1 and any route with community 3560:20 is assigned a preference of 2 regardless of whom they are imported from. However, only AS1's routes are imported from AS1, and only AS2's routes are imported from AS2, and only AS3's routes are imported form AS3, and no routes are imported from any other AS. We can reach the same conclusion using the above algebra. That is, our example is equivalent to:
ここでは、コミュニティ3560：10のルートには1の選好が割り当てられ、コミュニティ3560：20のルートには、誰から輸入されているかに関係なく2の優先順位が割り当てられます。ただし、AS1のルートのみがAS1からインポートされ、AS2のルートのみがAS2からインポートされ、AS3のルートのみがAS3からインポートされ、他のASから輸入されるルートはありません。上記の代数を使用して同じ結論に達することができます。つまり、私たちの例は次のとおりです。
import: {
from AS1 action pref = 1; accept community(3560:10) AND AS1;
from AS1 action pref = 2; accept community(3560:20) AND AS1;
from AS2 action pref = 1; accept community(3560:10) AND AS2;
from AS2 action pref = 2; accept community(3560:20) AND AS2;
from AS3 action pref = 1; accept community(3560:10) AND AS3;
from AS3 action pref = 2; accept community(3560:20) AND AS3;
}
Note that the common peerings between "from AS1" and "from AS-ANY" are those peerings in "from AS1". Even though we do not formally define "common peerings", it is straight forward to deduce the definition from the definitions of peerings (please see Section 5.6).
「AS1から」と「AS-ANYから」の間の一般的なピーリングは、「AS1から」のピアリングであることに注意してください。「一般的なピアリング」を正式に定義していませんが、ピーリングの定義から定義を推測するのは簡単です（セクション5.6を参照）。
Consider the following example:
次の例を考えてみましょう。
import: {
from AS-ANY action med = 0; accept {0.0.0.0/0^0-18};
} refine {
from AS1 at 7.7.7.1 action pref = 1; accept AS1;
from AS1 action pref = 2; accept AS1;
}
where only routes of length 0 to 18 are accepted and med's value is set to 0 to disable med's effect for all peerings; In addition, from AS1 only AS1's routes are imported, and AS1's routes imported at 7.7.7.1 are preferred over other peerings. This is equivalent to:
長さ0〜18のルートのみが受け入れられ、すべてのピーリングに対してMEDの効果を無効にするためにMEDの値が0に設定されています。さらに、AS1からAS1のルートのみが輸入され、7.7.7.1で輸入されたAS1のルートは他のピーリングよりも推奨されます。これは次のとおりです。
import: {
from AS1 at 7.7.7.1 action med=0; pref=1; accept {0.0.0.0/0^0-
18} AND AS1;
from AS1 action med=0; pref=2; accept {0.0.0.0/0^0-
18} AND AS1;
}
The above syntax and semantics also apply equally to structured export policies with "from" replaced with "to" and "accept" is replaced with "announce".
上記の構文とセマンティクスは、「」から「」に置き換えられ、「アナウンス」に置き換えられた「」に置き換えられた構造化されたエクスポートポリシーに等しく適用されます。
7 dictionary Class
7辞書クラス
The dictionary class provides extensibility to RPSL. Dictionary objects define routing policy attributes, types, and routing protocols. Routing policy attributes, henceforth called rp-attributes, may correspond to actual protocol attributes, such as the BGP path attributes (e.g. community, dpa, and AS-path), or they may correspond to router features (e.g. BGP route flap damping). As new protocols, new protocol attributes, or new router features are introduced, the dictionary object is updated to include appropriate rp-attribute and protocol definitions.
辞書クラスは、RPSLの拡張性を提供します。辞書オブジェクトは、ルーティングポリシーの属性、タイプ、およびルーティングプロトコルを定義します。RP-Attributesと呼ばれるルーティングポリシー属性は、BGPパス属性（コミュニティ、DPA、AS-PATHなど）などの実際のプロトコル属性に対応するか、ルーター機能（BGPルートフラップダンピングなど）に対応する場合があります。新しいプロトコル、新しいプロトコル属性、または新しいルーター機能が導入されると、辞書オブジェクトが更新され、適切なRPアトリブおよびプロトコル定義が含まれます。
An rp-attribute is an abstract class; that is a data representation is not available. Instead, they are accessed through access methods. For example, the rp-attribute for the BGP AS-path attribute is called aspath; and it has an access method called prepend which stuffs extra AS numbers to the AS-path attributes. Access methods can take arguments. Arguments are strongly typed. For example, the method prepend above takes AS numbers as arguments.
RPアトリブは抽象クラスです。それはデータ表現が利用できません。代わりに、アクセス方法を介してアクセスされます。たとえば、BGP As-Path属性のRPアトリブはASPATHと呼ばれます。また、Prependというアクセス方法があり、As-Path属性に数字を追加します。アクセス方法は引数を取ることができます。引数は強くタイプされています。たとえば、上記のメソッドは、引数として数字として取得されます。
Once an rp-attribute is defined in the dictionary, it can be used to describe policy filters and actions. Policy analysis tools are required to fetch the dictionary object and recognize newly defined rp-attributes, types, and protocols. The analysis tools may approximate policy analyses on rp-attributes that they do not understand: a filter method may always match, and an action method may always perform no-operation. Analysis tools may even download code to perform appropriate operations using mechanisms outside the scope of RPSL.
rp-aTtributeが辞書で定義されると、ポリシーフィルターとアクションを記述するために使用できます。辞書オブジェクトを取得し、新しく定義されたRPアトリビュート、タイプ、およびプロトコルを認識するには、ポリシー分析ツールが必要です。分析ツールは、RP-Attributesのポリシー分析を理解していない場合があります。フィルターメソッドは常に一致する場合があり、アクションメソッドは常に操作を実行できません。分析ツールは、RPSLの範囲外のメカニズムを使用して適切な操作を実行するためにコードをダウンロードすることもできます。
We next describe the syntax and semantics of the dictionary class. This description is not essential for understanding dictionary objects (but it is essential for creating one). Please feel free to skip to the RPSL Initial Dictionary subsection (Section 7.1).
次に、辞書クラスの構文とセマンティクスについて説明します。この説明は、辞書オブジェクトを理解するために不可欠ではありません（ただし、作成するには不可欠です）。RPSLの初期辞書サブセクション（セクション7.1）に自由にスキップしてください。
The attributes of the dictionary class are shown in Figure 24. The dictionary attribute is the name of the dictionary object, obeying the RPSL naming rules. There can be many dictionary objects, however there is always one well-known dictionary object "RPSL". All tools use this dictionary by default.
辞書クラスの属性を図24に示します。辞書属性は辞書オブジェクトの名前で、RPSLの命名ルールに従います。多くの辞書オブジェクトが存在する場合がありますが、常によく知られている辞書オブジェクト「RPSL」が1つあります。すべてのツールは、デフォルトでこの辞書を使用します。
Attribute Value Type dictionary <object-name> mandatory, single-valued, class key rp-attribute see description in text optional, multi valued typedef see description in text optional, multi valued protocol see description in text optional, multi valued
属性値タイプディクショナリ<Object-name>必須、単一値、クラスキーRPアトリブテキストの説明を参照オプション、マルチ値Typedefテキストの説明を参照オプション、マルチ値のプロトコル
Figure 24: dictionary Class Attributes
図24：辞書クラスの属性
The rp-attribute attribute has the following syntax:
RPアトリブ属性には、次の構文があります。
rp-attribute: <name>
<method-1>(<type-1-1>, ..., <type-1-N1> [, "..."])
...
<method-M>(<type-M-1>, ..., <type-M-NM> [, "..."])
where <name> is the name of the rp-attribute; and <method-i> is the name of an access method for the rp-attribute, taking Ni arguments where the j-th argument is of type <type-i-j>. A method name is either an RPSL name or one of the operators defined in Figure 25. The operator methods with the exception of operator() and operator[] can take only one argument.
ここで、<name>はrp-aTtributeの名前です。<method-i>は、rp-aTtributeのアクセス方法の名前であり、j-th引数がタイプ<type-i-j>の引数がある場合にni引数を取得します。メソッド名は、RPSL名または図25に定義されている演算子のいずれかです。オペレーター（）とオペレーター[]を除く演算子メソッドは、1つの引数のみを取得できます。
operator= operator==
operator<<= operator<
operator>>= operator>
operator+= operator>=
operator-= operator<=
operator*= operator!=
operator/= operator()
operator.= operator[]
Figure 25: Operators
図25：オペレーター
An rp-attribute can have many methods defined for it. Some of the methods may even have the same name, in which case their arguments are of different types. If the argument list is followed by "...", the method takes a variable number of arguments. In this case, the actual arguments after the Nth argument are of type <type-N>.
RPアトリブには、多くの方法が定義されています。一部の方法には同じ名前さえあるかもしれません。その場合、彼らの議論は異なるタイプです。引数リストの後に「...」が続く場合、メソッドはさまざまな数の引数を取ります。この場合、n番目の引数の後の実際の引数はタイプ<タイプ-N>です。
Arguments are strongly typed. A <type> in RPSL is either a predefined type, a union type, a list type, or a dictionary defined type. The predefined types are listed in Figure 26.
引数は強くタイプされています。RPSLの<タイプ>は、定義済みのタイプ、ユニオンタイプ、リストタイプ、または辞書定義型のいずれかです。事前定義されたタイプを図26に示します。
integer[lower, upper] ipv4_address
real[lower, upper] address_prefix
enum[name, name, ...] address_prefix_range
string dns_name
boolean filter
rpsl_word as_set_name
free_text route_set_name
email rtr_set_name
as_number filter_set_name
peering_set_name
Figure 26: Predefined Types
図26：事前定義されたタイプ
The integer and the real predefined types can be followed by a lower and an upper bound to specify the set of valid values of the argument. The range specification is optional. We use the ANSI C language conventions for representing integer, real and string values. The enum type is followed by a list of RPSL names which are the valid values of the type. The boolean type can take the values true or false. as_number, ipv4_address, address_prefix and dns_name types are as in Section 2. filter type is a policy filter as in Section 6. The value of filter type is suggested to be enclosed in parenthesis.
整数と実際の事前定義されたタイプに続いて、下部と上限が続いて、引数の有効な値のセットを指定できます。範囲仕様はオプションです。整数、実際の値、文字列値を表すために、ANSI C言語規則を使用します。列挙型の後に、タイプの有効な値であるRPSL名のリストが続きます。ブールタイプは、値を真またはfalseにすることができます。as_number、ipv4_address、address_prefix、dns_nameタイプはセクション2のように、フィルタータイプはセクション6のようにポリシーフィルターです。
The syntax of a union type is as follows:
組合タイプの構文は次のとおりです。
union <type-1>, ... , <type-N>
where <type-i> is an RPSL type. The union type is either of the types <type-1> through <type-N> (analogous to unions in C[14]).
ここで、<タイプ-i>はRPSLタイプです。ユニオンタイプは、タイプ<タイプ1>から<タイプ-N>（C [14]の組合に類似）のいずれかです。
The syntax of a list type is as follows:
リストタイプの構文は次のとおりです。
list [<min_elems>:<max_elems>] of <type>
In this case, the list elements are of <type> and the list contains at least <min_elems> and at most <max_elems> elements. The size specification is optional. If it is not specified, there is no restriction in the number of list elements. A value of a list type is represented as a sequence of elements separated by the character "," and enclosed by the characters "{" and "}".
この場合、リスト要素は<type>のものであり、リストには少なくとも<min_elems>およびせいぜい<max_elems>要素が含まれています。サイズの仕様はオプションです。指定されていない場合、リスト要素の数に制限はありません。リストタイプの値は、文字「」、「」{"および"} "によって囲まれた一連の要素として表されます。
The typedef attribute in the dictionary defines named types as follows:
辞書のtypedef属性は、次のように指定されたタイプを定義します。
typedef: <name> <type>
where <name> is a name for type <type>. typedef attribute is paticularly useful when the type defined is not a predefined type (e.g. list of unions, list of lists, etc.).
ここで、<name>は<type>の名前です。typedef属性は、定義されたタイプが事前定義されたタイプではない場合に鮮明に役立ちます（たとえば、組合のリスト、リストのリストなど）。
A protocol attribute of the dictionary class defines a protocol and a set of peering parameters for that protocol (which are used in inet-rtr class in Section 9). Its syntax is as follows:
辞書クラスのプロトコル属性は、そのプロトコルのプロトコルと一連のピアリングパラメーターを定義します（セクション9のINET-RTRクラスで使用されています）。その構文は次のとおりです。
protocol: <name>
MANDATORY | OPTIONAL <parameter-1>(<type-1-1>,...,
<type-1-N1> [,"..."])
...
MANDATORY | OPTIONAL <parameter-M>(<type-M-1>,...,
<type-M-NM> [,"..."])
where <name> is the name of the protocol; MANDATORY and OPTIONAL are keywords; and <parameter-i> is a peering parameter for this protocol, taking Ni many arguments. The syntax and semantics of the arguments are as in the rp-attribute. If the keyword MANDATORY is used, the parameter is mandatory and needs to be specified for each peering of this protocol. If the keyword OPTIONAL is used, the parameter can be skipped.
ここで、<name>はプロトコルの名前です。必須でオプションはキーワードです。<parameter-i>は、このプロトコルのピアリングパラメーターであり、多くの引数を取得しています。引数の構文とセマンティクスは、RPアトリブのようなものです。必須のキーワードが使用されている場合、パラメーターは必須であり、このプロトコルのピアリングごとに指定する必要があります。キーワードオプションが使用されている場合、パラメーターをスキップできます。
dictionary: RPSL
rp-attribute: # preference, smaller values represent higher preferences
pref
operator=(integer[0, 65535])
rp-attribute: # BGP multi_exit_discriminator attribute
med
# to set med to 10: med = 10;
# to set med to the IGP metric: med = igp_cost;
operator=(union integer[0, 65535], enum[igp_cost])
rp-attribute: # BGP destination preference attribute (dpa)
dpa
operator=(integer[0, 65535])
rp-attribute: # BGP aspath attribute
aspath
# prepends AS numbers from last to first order
prepend(as_number, ...)
typedef: # a community value in RPSL is either
# - a 4 byte integer (ok to use 3561:70 notation)
# - internet, no_export, no_advertise (see RFC-1997)
community_elm union
integer[1, 4294967295],
enum[internet, no_export, no_advertise],
typedef: # list of community values { 40, no_export, 3561:70 }
community_list list of community_elm
rp-attribute: # BGP community attribute
community
# set to a list of communities
operator=(community_list)
# append community values
operator.=(community_list)
append(community_elm, ...)
# delete community values
delete(community_elm, ...)
# a filter: true if one of community values is contained
contains(community_elm, ...)
# shortcut to contains: community(no_export, 3561:70)
operator()(community_elm, ...)
# order independent equality comparison
operator==(community_list)
rp-attribute: # next hop router in a static route
next-hop
# to set to 7.7.7.7: next-hop = 7.7.7.7;
# to set to router's own address: next-hop = self; operator=(union ipv4_address, enum[self]) rp-attribute: # cost of a static route cost operator=(integer[0, 65535]) protocol: BGP4 # as number of the peer router MANDATORY asno(as_number) # enable flap damping OPTIONAL flap_damp() OPTIONAL flap_damp(integer[0,65535], # penalty per flap integer[0,65535], # penalty value for supression integer[0,65535], # penalty value for reuse integer[0,65535], # halflife in secs when up integer[0,65535], # halflife in secs when down integer[0,65535]) # maximum penalty protocol: OSPF protocol: RIP protocol: IGRP protocol: IS-IS protocol: STATIC protocol: RIPng protocol: DVMRP protocol: PIM-DM protocol: PIM-SM protocol: CBT protocol: MOSPF
＃ルーター自身のアドレスに設定するには：next-hop = self;operator =（Union IPv4_Address、enum [self]）rp-aTtribute：＃静的ルートのコストコストoperator =（integer [0、65535]）プロトコル：BGP4＃ピアルーターの番号として必須（AS_Number）オプションのflap_damp（）オプションのflap_damp（integer [0,65535]、＃flap integer [0,65535]あたりの＃ペナルティ、抑制整数[0,65535]のペナルティ値、＃reuse integer [0,65535]、＃ペナルティ値、＃整数[0,65535]の場合のsecsのハーフライフ、＃整数の場合は＃ハーフライフ[0,65535]）：DVMRPプロトコル：PIM-DMプロトコル：PIM-SMプロトコル：CBTプロトコル：MOSPF
Figure 27: RPSL Dictionary
図27：RPSL辞書
Figure 27 shows the initial RPSL dictionary. It has seven rp-attributes: pref to assign local preference to the routes accepted; med to assign a value to the MULTI_EXIT_DISCRIMINATOR BGP attribute; dpa to assign a value to the DPA BGP attribute; aspath to prepend a value to the AS_PATH BGP attribute; community to assign a value to or to check the value of the community BGP attribute; next-hop to assign next hop routers to static routes; and cost to assign a cost to static routes. The dictionary defines two types: community_elm and community_list. community_elm type is either a 4-byte unsigned integer, or one of the keywords internet, no_export or no_advertise (defined in [9]). An integer can be specified using two 2-byte integers seperated by ":" to partition the community number space so that a provider can use its AS number as the first two bytes, and assigns a semantics of its choice to the last two bytes.
図27は、初期のRPSL辞書を示しています。7つのrp-aTtributesがあります。受け入れられたルートへのローカル選好を割り当てることができます。med multi_exit_discriminator bgp属性に値を割り当てる。dpa bgp属性に値を割り当てる。AS_Path BGP属性に値を準備するASPATH;コミュニティは、コミュニティBGP属性の値をに割り当てる、または確認するためのコミュニティ。次のホップルーターを静的ルートに割り当てる次のホップ。静的ルートにコストを割り当てるためのコスト。辞書は、community_elmとcommunity_listの2つのタイプを定義します。community_elmタイプは、4バイトのunsigned Integer、またはキーワードインターネット、no_exportまたはno_advertise（[9]で定義）のいずれかです。整数は、「：」で分離された2つの2バイト整数を使用して指定できます。コミュニティ番号スペースを分割して、プロバイダーが最初の2バイトとしてその数字を使用し、選択のセマンティクスを最後の2バイトに割り当てることができます。
The initial dictionary (Figure 27) defines only options for the Border Gateway Protocol: asno and flap_damp. The mandatory asno option is the AS number of the peer router. The optional flap_damp option instructs the router to damp route flaps [21] when importing routes from the peer router.
初期辞書（図27）は、境界ゲートウェイプロトコルのオプションのみを定義しています：asno and flap_damp。必須のASNOオプションは、ピアルーターの数です。オプションのFLAP_DAMPオプションは、ピアルーターからルートをインポートするときに、ルーターに湿ったルートフラップ[21]を指示します。
It can be specified with or without parameters. If parameters are missing, they default to:
パラメーターの有無にかかわらず指定できます。パラメーターが欠落している場合、デフォルトは次のとおりです。
flap_damp(1000, 2000, 750, 900, 900, 20000)
flap_damp（1000、2000、750、900、900、20000）
That is, a penalty of 1000 is assigned at each route flap, the route is suppressed when penalty reaches 2000. The penalty is reduced in half after 15 minutes (900 seconds) of stability regardless of whether the route is up or down. A supressed route is reused when the penalty falls below 750. The maximum penalty a route can be assigned is 20,000 (i.e. the maximum suppress time after a route becomes stable is about 75 minutes). These parameters are consistent with the default flap damping parameters in several routers.
つまり、各ルートフラップで1000のペナルティが割り当てられ、ペナルティが2000年に達するとルートが抑制されます。ルートが上下するかどうかに関係なく、15分（900秒）安定性の後にペナルティが減少します。ペナルティが750を下回ると、抑制されたルートが再利用されます。ルートを割り当てることができる最大ペナルティは20,000です（つまり、ルートが安定した後の最大抑制時間は約75分です）。これらのパラメーターは、いくつかのルーターのデフォルトのフラップ減衰パラメーターと一致しています。
Policy Actions and Filters Using RP-Attributes
RP-ATTRIBUTESを使用したポリシーアクションとフィルター
The syntax of a policy action or a filter using an rp-attribute x is as follows:
rp-aTtribute xを使用したポリシーアクションまたはフィルターの構文は次のとおりです。
x.method(arguments) x "op" argument
X.METHOD（引数）X "OP"引数
where method is a method and "op" is an operator method of the rp-attribute x. If an operator method is used in specifying a composite policy filter, it evaluates earlier than the composite policy filter operators (i.e. AND, OR, NOT, and implicit or operator).
メソッドはメソッドであり、「OP」はRPアトリブXの演算子メソッドです。コンポジットポリシーフィルターの指定に演算子方法が使用される場合、複合ポリシーフィルター演算子（つまり、OR、およびnot、および暗黙的または演算子）よりも早く評価します。
The pref rp-attribute can be assigned a positive integer as follows:
Pref RP-Attributeには、次のように正の整数を割り当てることができます。
pref = 10;
pref = 10;
The med rp-attribute can be assigned either a positive integer or the word "igp_cost" as follows:
MED RP-Attributeには、次のように、正の整数または「IGP_COST」という単語のいずれかを割り当てることができます。
med = 0;
med = igp_cost;
The dpa rp-attribute can be assigned a positive integer as follows:
dpa = 100;
The BGP community attribute is list-valued, that is it is a list of 4-byte integers each representing a "community". The following examples demonstrate how to add communities to this rp-attribute:
BGPコミュニティ属性はリスト値です。つまり、それぞれ「コミュニティ」を表す4バイトの整数のリストです。次の例は、このRPアトリブにコミュニティを追加する方法を示しています。
community .= { 100 };
community .= { NO_EXPORT };
community .= { 3561:10 };
In the last case, a 4-byte integer is constructed where the more significant two bytes equal 3561 and the less significant two bytes equal 10. The following examples demonstrate how to delete communities from the community rp-attribute:
最後のケースでは、4バイトの整数が構築され、より重要な2バイトが3561に等しく、2つのバイトが等しく等しくなります。次の例は、コミュニティからコミュニティを削除する方法を示しています。
community.delete(100, NO_EXPORT, 3561:10);
Filters that use the community rp-attribute can be defined as demonstrated by the following examples:
コミュニティRPアトリブを使用するフィルターは、次の例で示すように定義できます。
community.contains(100, NO_EXPORT, 3561:10);
community(100, NO_EXPORT, 3561:10); # shortcut
The community rp-attribute can be set to a list of communities as follows:
コミュニティRPアトリブは、次のようにコミュニティのリストに設定できます。
community = {100, NO_EXPORT, 3561:10, 200};
community = {};
In this first case, the community rp-attribute contains the communities 100, NO_EXPORT, 3561:10, and 200. In the latter case, the community rp-attribute is cleared. The community rp-attribute can be compared against a list of communities as follows:
この最初のケースでは、Community RP-AttributeにはCommunities 100、No_export、3561：10、および200が含まれています。後者の場合、コミュニティRPアトリブがクリアされています。コミュニティRPアトリブは、次のようにコミュニティのリストと比較できます。
community == {100, NO_EXPORT, 3561:10, 200}; # exact match
To influence the route selection, the BGP as_path rp-attribute can be made longer by prepending AS numbers to it as follows:
ルートの選択に影響を与えるために、BGP AS_PATH RP-Attributeは、次のように数値として準備することで長くすることができます。
aspath.prepend(AS1);
aspath.prepend(AS1, AS1, AS1);
The following examples are invalid:
次の例は無効です。
med = -50; # -50 is not in the range med = igp; # igp is not one of the enum values med.assign(10); # method assign is not defined community.append(AS3561:20); # the first argument should be 3561 Figure 28 shows a more advanced example using the rp-attribute community. In this example, AS3561 bases its route selection preference on the community attribute. Other ASes may indirectly affect AS3561's route selection by including the appropriate communities in their route announcements.
Med = -50;＃-50は範囲内にありませんmed = igp;＃IGPは列挙値med.Assign（10）の1つではありません。＃メソッドの割り当ては定義されていませんcommunity.append（AS3561：20）;＃最初の引数は3561である必要があります。図28は、RPアトリブコミュニティを使用したより高度な例を示しています。この例では、AS3561は、コミュニティ属性のルート選択選好を基にしています。他のASEは、適切なコミュニティをルートの発表に含めることにより、間接的にAS3561のルート選択に影響を与える可能性があります。
aut-num: AS1
export: to AS2 action community.={3561:90};
to AS3 action community.={3561:80};
announce AS1
as-set: AS3561:AS-PEERS members: AS2, AS3
as-set：as3561：as-peersメンバー：AS2、AS3
aut-num: AS3561
import: from AS3561:AS-PEERS
action pref = 10;
accept community(3561:90)
import: from AS3561:AS-PEERS
action pref = 20;
accept community(3561:80)
import: from AS3561:AS-PEERS
action pref = 20;
accept community(3561:70)
import: from AS3561:AS-PEERS
action pref = 0;
accept ANY
Figure 28: Policy example using the community rp-attribute.
図28：コミュニティRPアトリブを使用したポリシー例。
8 Advanced route Class
8高度なルートクラス
The components, aggr-bndry, aggr-mtd, export-comps, inject, and holes attributes are used for specifying aggregate routes [11]. A route object specifies an aggregate route if any of these attributes, with the exception of inject, is specified. The origin attribute for an aggregate route is the AS performing the aggregation, i.e. the aggregator AS. In this section, we used the term "aggregate" to refer to the route generated, the term "component" to refer to the routes used to generate the path attributes of the aggregate, and the term "more specifics" to refer to any route which is a more specific of the aggregate regardless of whether it was used to form the path attributes.
コンポーネント、AGGR-BNDRY、AGGR-MTD、エクスポートコンピング、注入、および穴の属性は、集合ルートを指定するために使用されます[11]。ルートオブジェクトは、これらの属性のいずれかが注入を除いて指定されている場合、集約ルートを指定します。集約ルートの起源属性は、集約を実行するAS、つまりアグリゲーターとしてです。このセクションでは、「集計」という用語を使用して生成されたルートを参照し、「コンポーネント」という用語を参照して、集約のパス属性を生成するために使用されるルートを参照し、「より詳細」という用語は、任意のルートを参照する「より詳細」という用語を参照しました。これは、パス属性の形成に使用されたかどうかに関係なく、集合体よりも具体的です。
The components attribute defines what component routes are used to form the aggregate. Its syntax is as follows:
コンポーネント属性は、集約を形成するために使用されるコンポーネントルートを定義します。その構文は次のとおりです。
components: [ATOMIC] [[<filter>] [protocol <protocol> <filter> ...]]
where <protocol> is a routing protocol name such as BGP4, OSPF or RIP (valid names are defined in the dictionary) and <filter> is a policy expression. The routes that match one of these filters and are learned from the corresponding protocol are used to form the aggregate. If <protocol> is omitted, it defaults to any protocol. <filter> implicitly contains an "AND" term with the more specifics of the aggregate so that only the component routes are selected. If the keyword ATOMIC is used, the aggregation is done atomically [11]. If a <filter> is not specified it defaults to more specifics. If the components attribute is missing, all more specifics without the ATOMIC keyword is used.
ここで、<protocol>はBGP4、OSPF、RIPなどのルーティングプロトコル名（有効な名前は辞書で定義されています）、<filter>はポリシー式です。これらのフィルターの1つに一致し、対応するプロトコルから学習されたルートは、凝集体を形成するために使用されます。<protocol>が省略されている場合、任意のプロトコルがデフォルトです。<filter>暗黙的に「および」と "タームが含まれているため、コンポーネントルートのみが選択されるようにします。キーワードアトミックを使用すると、集約は原子的に行われます[11]。<filter>が指定されていない場合、デフォルトの詳細になります。コンポーネント属性が欠落している場合、Atomicキーワードを使用しないすべての詳細が使用されます。
route: 128.8.0.0/15
origin: AS1
components: <^AS2>
route: 128.8.0.0/15
origin: AS1
components: protocol BGP4 {128.8.0.0/16^+}
protocol OSPF {128.9.0.0/16^+}
Figure 29: Two aggregate route objects.
図29：2つの集計ルートオブジェクト。
Figure 29 shows two route objects. In the first example, more specifics of 128.8.0.0/15 with AS paths starting with AS2 are aggregated. In the second example, some routes learned from BGP and some routes learned form OSPF are aggregated.
図29は、2つのルートオブジェクトを示しています。最初の例では、AS2から始まるASパスを使用した128.8.0.0/15の詳細な詳細が集計されています。2番目の例では、BGPから学んだいくつかのルートとOSPFの形式を学んだルートは集約されています。
The aggr-bndry attribute is an AS expression over AS numbers and sets (see Section 5.6). The result defines the set of ASes which form the aggregation boundary. If the aggr-bndry attribute is missing, the origin AS is the sole aggregation boundary. Outside the aggregation boundary, only the aggregate is exported and more specifics are suppressed. However, within the boundary, the more specifics are also exchanged.
aggr-bndry属性は、数字とセットとしての式としての式です（セクション5.6を参照）。結果は、集約境界を形成するASEのセットを定義します。Aggr-bndry属性が欠落している場合、唯一の集約境界と同様に起源。集約境界の外では、集計のみがエクスポートされ、より多くの詳細が抑制されます。ただし、境界内では、より多くの詳細も交換されます。
The aggr-mtd attribute specifies how the aggregate is generated. Its syntax is as follows:
AGGR-MTD属性は、集計の生成方法を指定します。その構文は次のとおりです。
aggr-mtd: inbound | outbound [<as-expression>]
AGGR-MTD：インバウンド|アウトバウンド[<as-expression>]
where <as-expression> is an expression over AS numbers and sets (see Section 5.6). If <as-expression> is missing, it defaults to AS-ANY. If outbound aggregation is specified, the more specifics of the aggregate will be present within the AS and the aggregate will be formed at all inter-AS boundaries with ASes in <as-expression> before export, except for ASes that are within the aggregating boundary (i.e. aggr-bndry is enforced regardless of <as-expression>). If inbound aggregation is specified, the aggregate is formed at all inter-AS boundaries prior to importing routes into the aggregator AS. Note that <as-expression> can not be specified with inbound aggregation. If aggr-mtd attribute is missing, it defaults to "outbound AS-ANY".
ここで、<as-expression>は数字とセットとしての式です（セクション5.6を参照）。<as-expression>が欠落している場合、デフォルトはas-anyになります。アウトバウンド集約が指定されている場合、AS内に集合体のより多くの詳細が存在し、集約境界内にあるASEを除き、エクスポート前に<as-expression>のASESとのすべての境界で集合体が形成されます。（つまり、aggr-bndryは<as-expression>に関係なく施行されます）。インバウンド集約が指定されている場合、アグリゲーターにルートをインポートする前に、集合体はすべてのAS境界で形成されます。<as-expression>は、インバウンド集約で指定できないことに注意してください。AGGR-MTD属性が欠落している場合、デフォルトは「アウトバウンドANY」になります。
route: 128.8.0.0/15 route: 128.8.0.0/15
origin: AS1 origin: AS2
components: {128.8.0.0/15^-} components: {128.8.0.0/15^-}
aggr-bndry: AS1 OR AS2 aggr-bndry: AS1 OR AS2
aggr-mtd: outbound AS-ANY aggr-mtd: outbound AS-ANY
Figure 30: Outbound multi-AS aggregation example.
図30：アウトバウンドマルチAS集約例。
Figure 30 shows an example of an outbound aggregation. In this example, AS1 and AS2 are coordinating aggregation and announcing only the less specific 128.8.0.0/15 to outside world, but exchanging more specifics between each other. This form of aggregation is useful when some of the components are within AS1 and some are within AS2.
図30は、アウトバウンド集約の例を示しています。この例では、AS1とAS2は集約を調整し、特定の128.8.0.0/15のみを外の世界に発表していますが、互いにより多くの詳細を交換しています。この形式の集約は、一部のコンポーネントがAS1内で、一部がAS2内にある場合に役立ちます。
When a set of routes are aggregated, the intent is to export only the aggregate route and suppress exporting of the more specifics outside the aggregation boundary. However, to satisfy certain policy and topology constraints (e.g. a multi-homed component), it is often required to export some of the components. The export-comps attribute equals an RPSL filter that matches the more specifics that need to be exported outside the aggregation boundary. If this attribute is missing, more specifics are not exported outside the aggregation boundary. Note that, the export-comps filter contains an implicit "AND" term with the more specifics of the aggregate.
一連のルートが集約されている場合、目的は集約経路のみをエクスポートし、集約境界外のより多くの詳細のエクスポートを抑制することです。ただし、特定のポリシーとトポロジの制約（たとえば、マルチホームコンポーネントなど）を満たすためには、一部のコンポーネントをエクスポートするためにしばしば必要です。Export-Comps属性は、集約境界の外側でエクスポートする必要があるより多くの詳細と一致するRPSLフィルターに等しくなります。この属性が欠落している場合、集約境界の外側でより多くの詳細がエクスポートされません。エクスポート-Compsフィルターには、集計のより多くの詳細を伴う暗黙の "および"用語が含まれていることに注意してください。
Figure 31 shows an example of an outbound aggregation. In this example, the more specific 128.8.8.0/24 is exported outside AS1 in addition to the aggregate. This is useful, when 128.8.8.0/24 is multi-homed site to AS1 with some other AS.
図31は、アウトバウンド集約の例を示しています。この例では、より具体的な128.8.8.0/24は、集合体に加えてAS1外でエクスポートされます。これは、128.8.8.0/24が他のASを使用してAS1にマルチホームのサイトである場合に便利です。
route: 128.8.0.0/15
origin: AS1
components: {128.8.0.0/15^-}
aggr-mtd: outbound AS-ANY
export-comps: {128.8.8.0/24}
Figure 31: Outbound aggregation with export exception.
図31：エクスポートの例外を伴うアウトバウンド集約。
The inject attribute specifies which routers perform the aggregation and when they perform it. Its syntax is as follow:
Inject属性は、どのルーターが集約を実行し、それを実行するかを指定します。その構文は次のとおりです。
inject: [at <router-expression>] ...
[action <action>]
[upon <condition>]
where <action> is an action specification (see Section 6.1.1), <condition> is a boolean expression described below, and <router-expression> is as described in Section 5.6.
ここで、<アクション>はアクション仕様です（セクション6.1.1を参照）、<condition>は以下で説明するブール式式であり、<router-expression>はセクション5.6で説明されています。
All routers in <router-expression> and in the aggregator AS perform the aggregation. If a <router-expression> is not specified, all routers inside the aggregator AS perform the aggregation. The <action> specification may set path attributes of the aggregate, such as assign a preferences to the aggregate.
<router-expression>およびアグリゲーターのすべてのルーターは、集約を実行します。A <ルーター - 発現>が指定されていない場合、集約を実行するアグリゲーター内のすべてのルーター。<action>仕様は、集約への設定を割り当てるなど、集約のパス属性を設定する場合があります。
The upon clause is a boolean condition. The aggregate is generated if and only if this condition is true. <condition> is a boolean expression using the logical operators AND and OR (i.e. operator NOT is not allowed) over:
上の句はブールの状態です。この条件が真である場合にのみ、集合体が生成されます。<condition>は、論理演算子を使用したブール式と、および（つまり、オペレーターは許可されていません）オーバーです。
HAVE-COMPONENTS { list of prefixes }
EXCLUDE { list of prefixes }
STATIC
The list of prefixes in HAVE-COMPONENTS can only be more specifics of the aggregate. It evaluates to true when all the prefixes listed are present in the routing table of the aggregating router. The list can also include prefix ranges (i.e. using operators ^-, ^+, ^n, and ^n-m). In this case, at least one prefix from each prefix range needs to be present in the routing table for the condition to be true. The list of prefixes in EXCLUDE can be arbitrary. It evaluates to true when none of the prefixes listed is present in the routing table. The list can also include prefix ranges, and no prefix in that range should be present in the routing table. The keyword static always evaluates to true. If no upon clause is specified the aggregate is generated if an only if there is a component in the routing table (i.e. a more specific that matches the filter in the components attribute).
HASコンポーネントの接頭辞のリストは、集計の詳細のみになります。リストされているすべてのプレフィックスが集約ルーターのルーティングテーブルに存在する場合、それはtrueに評価されます。リストには、プレフィックス範囲（つまり、演算子 ^ - 、 ^、 ^n、および ^n-mを使用する）も含めることができます。この場合、各プレフィックス範囲から少なくとも1つのプレフィックスをルーティングテーブルに存在する必要があります。除外された接頭辞のリストは任意です。リストされているプレフィックスがルーティングテーブルに存在しない場合、trueに評価します。リストにはプレフィックス範囲を含めることもでき、その範囲内のプレフィックスはルーティングテーブルに存在する必要はありません。キーワード静的は常にtrueに評価されます。句が指定されていない場合、ルーティングテーブルにコンポーネントがある場合にのみ集約が生成されます（つまり、コンポーネント属性のフィルターと一致するより具体的です）。
route: 128.8.0.0/15
origin: AS1
components: {128.8.0.0/15^-}
aggr-mtd: outbound AS-ANY
inject: at 1.1.1.1 action dpa = 100;
inject: at 1.1.1.2 action dpa = 110;
route: 128.8.0.0/15
origin: AS1
components: {128.8.0.0/15^-}
aggr-mtd: outbound AS-ANY
inject: upon HAVE-COMPONENTS {128.8.0.0/16, 128.9.0.0/16}
holes: 128.8.8.0/24
Figure 32: Examples of inject.
図32：注射の例。
Figure 32 shows two examples. In the first case, the aggregate is injected at two routers each one setting the dpa path attribute differently. In the second case, the aggregate is generated only if both 128.8.0.0/16 and 128.9.0.0/16 are present in the routing table, as opposed to the first case where the presence of just one of them is sufficient for injection.
図32は2つの例を示しています。最初のケースでは、集合体はそれぞれ2つのルーターに注入され、DPAパス属性を異なる方法で設定します。2番目のケースでは、凝集体は、128.8.0.0.0/16と128.9.0.0.0/16の両方が、注射に十分な最初のケースとは対照的に、ルーティングテーブルに存在する場合にのみ生成されます。
The holes attribute lists the component address prefixes which are not reachable through the aggregate route (perhaps that part of the address space is unallocated). The holes attribute is useful for diagnosis purposes. In Figure 32, the second example has a hole, namely 128.8.8.0/24. This may be due to a customer changing providers and taking this part of the address space with it.
ホール属性には、集計ルートを介して到達できないコンポーネントアドレスプレフィックスがリストされています（おそらくアドレス空間の一部が割り当てられていません）。穴の属性は、診断の目的に役立ちます。図32には、2番目の例には穴があります。つまり、128.8.8.0/24です。これは、顧客がプロバイダーを変更し、住所スペースのこの部分を採用しているためかもしれません。
An aggregate formed is announced to other ASes only if the export policies of the AS allows exporting the aggregate. When the aggregate is formed, the more specifics are suppressed from being exported except to the ASes in aggr-bndry and except the components in export-comps. For such exceptions to happen, the export policies of the AS should explicitly allow exporting of these exceptions.
形成された集計は、ASのエクスポートポリシーが集合体をエクスポートできる場合にのみ、他のASEに発表されます。凝集体が形成されると、Aggr-BndryのASESを除き、輸出制度のコンポーネントを除き、より多くの詳細がエクスポートされることから抑制されます。このような例外を除いて、ASのエクスポートポリシーは、これらの例外のエクスポートを明示的に許可する必要があります。
If an aggregate is not formed (due to the upon clause), then the more specifics of the aggregate can be exported to other ASes, but only if the export policies of the AS allows it. In other words, before a route (aggregate or more specific) is exported it is filtered twice, once based on the route objects, and once based on the export policies of the AS.
集合体が形成されていない場合（上の条項のため）、集合体のより多くの詳細を他のASEにエクスポートできますが、それを許可する場合のみです。言い換えれば、ルート（集約またはより具体的）がエクスポートされる前に、ルートオブジェクトに基づいて1回、ASのエクスポートポリシーに基づいて2回フィルタリングされます。
route: 128.8.0.0/16 origin: AS1
ルート：128.8.0.0/16原点：AS1
route: 128.9.0.0/16 origin: AS1
ルート：128.9.0.0/16原点：AS1
route: 128.8.0.0/15
origin: AS1
aggr-bndry: AS1 or AS2 or AS3
aggr-mtd: outbound AS3 or AS4 or AS5
components: {128.8.0.0/16, 128.9.0.0/16}
inject: upon HAVE-COMPONENTS {128.9.0.0/16, 128.8.0.0/16}
aut-num: AS1
export: to AS2 announce AS1
export: to AS3 announce AS1 and not {128.9.0.0/16}
export: to AS4 announce AS1
export: to AS5 announce AS1
export: to AS6 announce AS1
Figure 33: Interaction with policies in aut-num class.
図33：Aut-Numクラスのポリシーとの相互作用。
In Figure 33 shows an interaction example. By examining the route objects, the more specifics 128.8.0.0/16 and 128.9.0.0/16 should be exchanged between AS1, AS2 and AS3 (i.e. the aggregation boundary). Outbound aggregation is done to AS4 and AS5 and not to AS3, since AS3 is in the aggregation boundary. The aut-num object allows exporting both components to AS2, but only the component 128.8.0.0/16 to AS3. The aggregate can only be formed if both components are available. In this case, only the aggregate is announced to AS4 and AS5. However, if one of the components is not available the aggregate will not be formed, and any available component or more specific will be exported to AS4 and AS5. Regardless of aggregation is performed or not, only the more specifics will be exported to AS6 (it is not listed in the aggr-mtd attribute).
図33は、相互作用の例を示しています。ルートオブジェクトを調べることにより、より多くの詳細128.8.0.0/16および128.9.0.0/16は、AS1、AS2、およびAS3（つまり、集約境界）の間で交換する必要があります。AS3は凝集境界にあるため、アウトバウンド集約はAS4およびAS5ではなくAS3に行われます。Aut-Numオブジェクトを使用すると、両方のコンポーネントをAS2にエクスポートできますが、コンポーネントは128.8.0.0/16からAS3です。両方のコンポーネントが利用可能な場合にのみ、集合体を形成できます。この場合、凝集体のみがAS4およびAS5に発表されます。ただし、コンポーネントのいずれかが使用できない場合、集約は形成されず、利用可能なコンポーネントまたはより具体的なコンポーネントはAS4およびAS5にエクスポートされます。集約が実行されるかどうかに関係なく、より多くの詳細だけがAS6にエクスポートされます（AGGR-MTD属性にはリストされていません）。
When doing an inbound aggregation, configuration generators may eliminating the aggregation statements on routers where import policy of the AS prohibits importing of any more specifics.
インバウンド集約を行う場合、構成ジェネレーターは、ASのインポートポリシーがこれ以上の詳細のインポートを禁止するルーターの集約ステートメントを排除する場合があります。
When several aggregate routes are specified and they overlap, i.e. one is less specific of the other, they must be evaluated more specific to less specific order. When an outbound aggregation is performed for a peer, the aggregate and the components listed in the export-comps attribute for that peer are available for generating the next less specific aggregate. The components that are not specified in the export-comps attribute are not available. A route is exportable to an AS if it is the least specific aggregate exportable to that AS or it is listed in the export-comps attribute of an exportable route. Note that this is a recursive definition.
いくつかの集計ルートが指定され、それらが重複する場合、つまり、一方が他のルートよりも具体的ではない場合、それらはより具体的ではない順序よりもより具体的に評価する必要があります。ピアに対してアウトバウンド集約が実行されると、そのピアのエクスポートコンピング属性にリストされている凝集体とコンポーネントが次の特定の骨材を生成するために使用できます。Export-Comps属性で指定されていないコンポーネントは利用できません。ルートは、エクスポート可能なルートのエクスポート-comps属性にリストされている、またはそれに対してエクスポート可能なエクスポート可能であるかのように、あたかもエクスポート可能です。これは再帰的な定義であることに注意してください。
route: 128.8.0.0/15
origin: AS1
aggr-bndry: AS1 or AS2
aggr-mtd: outbound
inject: upon HAVE-COMPONENTS {128.8.0.0/16, 128.9.0.0/16}
route: 128.10.0.0/15
origin: AS1
aggr-bndry: AS1 or AS3
aggr-mtd: outbound
inject: upon HAVE-COMPONENTS {128.10.0.0/16, 128.11.0.0/16}
export-comps: {128.11.0.0/16}
route: 128.8.0.0/14
origin: AS1
aggr-bndry: AS1 or AS2 or AS3
aggr-mtd: outbound
inject: upon HAVE-COMPONENTS {128.8.0.0/15, 128.10.0.0/15}
export-comps: {128.10.0.0/15}
Figure 34: Overlapping aggregations.
図34：集約の重複。
In Figure 34, AS1 together with AS2 aggregates 128.8.0.0/16 and 128.9.0.0/16 into 128.8.0.0/15. Together with AS3, AS1 aggregates 128.10.0.0/16 and 128.11.0.0/16 into 128.10.0.0/15. But altogether they aggregate these four routes into 128.8.0.0/14. Assuming all four components are available, a router in AS1 for an outside AS, say AS4, will first generate 128.8.0.0/15 and 128.10.0.0/15. This will make 128.8.0.0/15, 128.10.0.0/15 and its exception 128.11.0.0/16 available for generating 128.8.0.0/14. The router will then generate 128.8.0.0/14 from these three routes. Hence for AS4, 128.8.0.0/14 and its exception 128.10.0.0/15 and its exception 128.11.0.0/16 will be exportable.
図34では、AS1とAS2凝集体128.8.0.0/16および128.9.0.0/16に128.8.0.0.0/15に凝集しています。AS3とともに、AS1は128.10.0.0/16および128.11.0.0/16を128.10.0.0/15に集約します。しかし、全体として、これらの4つのルートを128.8.0.0/14に集約します。4つのコンポーネントすべてが利用可能であると仮定すると、AS1のAS1のルーターは、AS4が最初に128.8.0.0/15および128.10.0.0/15を生成します。これにより、128.8.0.0/15、128.10.0.0/15になり、その例外128.11.0.0/16が128.8.0.0.0/14を生成するために利用可能になります。ルーターは、これら3つのルートから128.8.0.0/14を生成します。したがって、AS4、128.8.0.0/14およびその例外128.10.0.0/15およびその例外128.11.0.0/16はエクスポート可能です。
For AS2, a router in AS1 will only generate 128.10.0.0/15. Hence, 128.10.0.0/15 and its exception 128.11.0.0/16 will be exportable. Note that 128.8.0.0/16 and 128.9.0.0/16 are also exportable since they did not participate in an aggregate exportable to AS2.
AS2の場合、AS1のルーターは128.10.0.0/15のみを生成します。したがって、128.10.0.0/15とその例外128.11.0.0/16はエクスポート可能になります。128.8.0.0/16および128.9.0.0/16は、AS2にエクスポート可能な集計に参加しなかったため、エクスポート可能であることに注意してください。
Similarly, for AS3, a router in AS1 will only generate 128.8.0.0/15. In this case 128.8.0.0/15, 128.10.0.0/16, 128.11.0.0/16 are exportable.
同様に、AS3の場合、AS1のルーターは128.8.0.0/15のみを生成します。この場合、128.8.0.0/15、128.10.0.0/16、128.11.0.0/16はエクスポート可能です。
The inject attribute can be used to specify static routes by using "upon static" as the condition:
注入属性を使用して、条件として「static」を使用することにより、静的ルートを指定できます。
inject: [at <router-expression>] ...
[action <action>]
upon static
In this case, the routers in <router-expression> executes the <action> and injects the route to the interAS routing system statically. <action> may set certain route attributes such as a next-hop router or a cost.
この場合、<router-expression>のルーターは<アクション>を実行し、Interasルーティングシステムへのルートを静的に注入します。<action>次のルーターやコストなどの特定のルート属性を設定する場合があります。
In the following example, the router 7.7.7.1 injects the route 128.7.0.0/16. The next-hop routers (in this example, there are two next-hop routers) for this route are 7.7.7.2 and 7.7.7.3 and the route has a cost of 10 over 7.7.7.2 and 20 over 7.7.7.3.
次の例では、ルーター7.7.7.1がルート128.7.0.0/16を注入します。このルートには、次のホップルーター（この例では、2つのネクストホップルーターがあります）は7.7.7.2および7.7.7.3で、ルートのコストは7.7.7.2を超えて7.7.7.3を超えています。
route: 128.7.0.0/16
origin: AS1
inject: at 7.7.7.1 action next-hop = 7.7.7.2; cost = 10; upon static
inject: at 7.7.7.1 action next-hop = 7.7.7.3; cost = 20; upon static
9 inet-rtr Class
9 INET-RTRクラス
Routers are specified using the inet-rtr class. The attributes of the inet-rtr class are shown in Figure 35. The inet-rtr attribute is a valid DNS name of the router described. Each alias attribute, if present, is a canonical DNS name for the router. The local-as attribute specifies the AS number of the AS which owns/operates this router.
ルーターは、INET-RTRクラスを使用して指定されています。INET-RTRクラスの属性を図35に示します。INET-RTR属性は、説明されているルーターの有効なDNS名です。各エイリアス属性は、存在する場合、ルーターの標準的なDNS名です。Local-As属性は、このルーターを所有/操作するASの数を指定します。
Attribute Value Type inet-rtr <dns-name> mandatory, single-valued, class key alias <dns-name> optional, multi-valued local-as <as-number> mandatory, single-valued ifaddr see description in text mandatory, multi-valued peer see description in text optional, multi-valued member-of list of <rtr-set-names> optional, multi-valued
属性値タイプINET-RTR <DNS-NAME>必須、シングル値、クラスキーエイリアス<DNS-NAME>オプション、マルチ値のローカルAS <As-Number>必須、単一値のIFADDRは、テキストの説明を参照してください、必須、マルチバリューピアテキストで説明を参照オプション、マルチバリューのメンバーオブ<rtr-set-names>オプション、多値
Figure 35: inet-rtr Class Attributes
図35：INET-RTRクラス属性
The value of an ifaddr attribute has the following syntax:
IFADDR属性の値には、次の構文があります。
<ipv4-address> masklen <integer> [action <action>]
The IP address and the mask length are mandatory for each interface. Optionally an action can be specified to set other parameters of this interface.
IPアドレスとマスクの長さは、各インターフェイスに必須です。オプションでは、このインターフェイスの他のパラメーターを設定するようにアクションを指定できます。
Figure 36 presents an example inet-rtr object. The name of the router is "amsterdam.ripe.net". "amsterdam1.ripe.net" is a canonical name for the router. The router is connected to 4 networks. Its IP addresses and mask lengths in those networks are specified in the ifaddr attributes.
図36は、INET-RTRオブジェクトの例を示しています。ルーターの名前は「amsterdam.ripe.net」です。「amsterdam1.ripe.net」は、ルーターの標準名です。ルーターは4つのネットワークに接続されています。これらのネットワークのIPアドレスとマスクの長さは、IFADDR属性で指定されています。
inet-rtr: Amsterdam.ripe.net
alias: amsterdam1.ripe.net
local-as: AS3333
ifaddr: 192.87.45.190 masklen 24
ifaddr: 192.87.4.28 masklen 24
ifaddr: 193.0.0.222 masklen 27
ifaddr: 193.0.0.158 masklen 27
peer: BGP4 192.87.45.195 asno(AS3334), flap_damp()
Figure 36: inet-rtr Objects
図36：INET-RTRオブジェクト
Each peer attribute, if present, specifies a protocol peering with another router. The value of a peer attribute has the following syntax:
各ピア属性は、存在する場合、別のルーターでプロトコルピアリングを指定します。ピア属性の値には、次の構文があります。
<protocol> <ipv4-address> <options>
| <protocol> <inet-rtr-name> <options>
| <protocol> <rtr-set-name> <options>
| <protocol> <peering-set-name> <options>
where <protocol> is a protocol name, <ipv4-address> is the IP address of the peer router, and <options> is a comma separated list of peering options for <protocol>. Instead of the peer's IP address, its inet-rtr-name can be used. Possible protocol names and attributes are defined in the dictionary (please see Section 7). In the above example, the router has a BGP peering with the router 192.87.45.195 in AS3334 and turns the flap damping on when importing routes from this router.
ここで、<protocol>はプロトコル名、<ipv4-address>はピアルーターのIPアドレスであり、<options>は<protocol>のピアリングオプションのコンマ分離リストです。ピアのIPアドレスの代わりに、そのINET-RTR-NAMEを使用できます。可能なプロトコル名と属性は辞書で定義されています（セクション7を参照してください）。上記の例では、ルーターには、AS3334にルーター192.87.45.195でBGPのピアリングがあり、このルーターからルートをインポートするときにフラップの減衰をオンにします。
Instead of a single peer, a group of peers can be specified by using the <rtr-set-name> and <peering-set-name> forms. If <peering-set-name> form is being used only the peerings in the corresponding peering set that are with this router are included. Figure 37 shows an example inet-rtr object with peering groups.
単一のピアの代わりに、<rtr-set-name>および<peering-set-name>フォームを使用して、ピアのグループを指定できます。<Peering-Set-Name>フォームが使用されている場合、このルーターにある対応するピアリングセットのピーリングのみが含まれています。図37は、ピアリンググループを持つINET-RTRオブジェクトの例を示しています。
rtr-set: rtrs-ibgp-peers members: 1.1.1.1, 2.2.2.2, 3.3.3.3
RTR-SET：RTRS-IBGP-PEERSメンバー：1.1.1.1、2.2.2.2、3.3.3.3
peering-set: prng-ebgp-peers peering: AS3334 192.87.45.195 peering: AS3335 192.87.45.196
ピアリングセット：prng-ebgp-peersピアリング：AS3334 192.87.45.195ピアリング：AS3335 192.87.45.196
inet-rtr: Amsterdam.ripe.net
alias: amsterdam1.ripe.net
local-as: AS3333
ifaddr: 192.87.45.190 masklen 24
ifaddr: 192.87.4.28 masklen 24
ifaddr: 193.0.0.222 masklen 27
ifaddr: 193.0.0.158 masklen 27
peer: BGP4 rtrs-ibgp-peers asno(AS3333), flap_damp()
peer: BGP4 prng-ebgp-peers asno(PeerAS), flap_damp()
Figure 37: inet-rtr Object with peering groups
図37：ピアリンググループを備えたINET-RTRオブジェクト
10 Extending RPSL
10 RPSLの拡張
Our experience with earlier routing policy languages and data formats (PRDB [2], RIPE-81 [8], and RIPE-181 [7]) taught us that RPSL had to be extensible. As a result, extensibility was a primary design goal for RPSL. New routing protocols or new features to existing routing protocols can be easily handled using RPSL's dictionary class. New classes or new attributes to the existing classes can also be added.
以前のルーティングポリシー言語とデータ形式（PRDB [2]、RIPE-81 [8]、およびRIPE-181 [7]）での私たちの経験は、RPSLが拡張可能でなければならないことを教えてくれました。その結果、拡張性はRPSLの主要な設計目標でした。既存のルーティングプロトコルの新しいルーティングプロトコルまたは新機能は、RPSLの辞書クラスを使用して簡単に処理できます。既存のクラスの新しいクラスまたは新しい属性も追加できます。
This section provides guidelines for extending RPSL. These guidelines are designed with an eye toward maintaining backward compatibility with existing tools and databases. We next list the available options for extending RPSL from the most preferred to the least preferred order.
このセクションでは、RPSLを拡張するためのガイドラインを提供します。これらのガイドラインは、既存のツールとデータベースとの逆方向の互換性を維持することに目を向けて設計されています。次に、RPSLを最も優先順序から最小の順序まで拡張するための利用可能なオプションをリストします。
The dictionary class is the primary mechanism provided to extend RPSL. Dictionary objects define routing policy attributes, types, and routing protocols.
辞書クラスは、RPSLを拡張するために提供される主要なメカニズムです。辞書オブジェクトは、ルーティングポリシーの属性、タイプ、およびルーティングプロトコルを定義します。
We recommend updating the RPSL dictionary to include appropriate rp-attribute and protocol definitions as new path attributes or router features are introduced. For example, in an earlier version of the RPSL document, it was only possible to specify that a router performs route flap damping on a peer, but it was not possible to specify the parameters of route flap damping. Later the parameters were added by changing the dictionary.
RPSL辞書を更新して、新しいパス属性またはルーター機能が導入されているため、適切なRPアトリブおよびプロトコル定義を含めることをお勧めします。たとえば、RPSLドキュメントの以前のバージョンでは、ルーターがピアでルートフラップダンピングを実行することを指定することのみが可能でしたが、ルートフラップダンピングのパラメーターを指定することはできませんでした。その後、辞書を変更することによりパラメーターが追加されました。
When changing the dictionary, full compatibility should be maintained. For example, in our flap damping case, we made the parameter specification optional in case this level of detail was not desired by some ISPs. This also achieved compatibility. Any object registered without the parameters will continue to be valid. Any tool based on RPSL is expected to do a default action on routing policy attributes that they do not understand (e.g. issue a warning and otherwise ignore). Hence, old tools upon encountering a flap damping specification with parameters will ignore the parameters.
辞書を変更するときは、完全な互換性を維持する必要があります。たとえば、フラップ減衰の場合、このレベルの詳細がいくつかのISPによって望まれていない場合に備えて、パラメーター仕様をオプションにしました。これも互換性を達成しました。パラメーターなしで登録されているオブジェクトは引き続き有効です。RPSLに基づくツールは、理解できないルーティングポリシー属性に対してデフォルトのアクションを実行することが期待されます（たとえば、警告を発行し、その他の無視）。したがって、パラメーターを使用したフラップ減衰仕様に遭遇すると、古いツールはパラメーターを無視します。
New attributes can be added to any class. To ensure full compatibility, new attributes should not contradict the semantics of the objects they are attached to. Any tool that uses the IRR should be designed so that it ignores attributes that it doesn't understand. Most existing tools adhere to this design principle.
新しい属性を任意のクラスに追加できます。完全な互換性を確保するために、新しい属性は、添付されているオブジェクトのセマンティクスと矛盾してはなりません。IRRを使用するツールは、理解できない属性を無視するように設計する必要があります。ほとんどの既存のツールは、この設計の原則に準拠しています。
We recommend adding new attributes to existing classes when a new aspect of a class is discovered. For example, RPSL route class extends its RIPE-181 predecessor by including several new attributes that enable aggregate and static route specification.
クラスの新しい側面が発見されたら、既存のクラスに新しい属性を追加することをお勧めします。たとえば、RPSLルートクラスは、集約および静的ルートの仕様を可能にするいくつかの新しい属性を含めることにより、Ripe-181の前身を拡張します。
New classes can be added to RPSL to store new types of policy data. Providing full compatibility is straight forward as long as existing classes are still understood. Since a tool should only query the IRR for the classes that it understand, full compatibility should not be a problem in this case.
新しい種類のポリシーデータを保存するために、RPSLに新しいクラスを追加できます。既存のクラスがまだ理解されている限り、完全な互換性を提供することは簡単です。ツールは、理解しているクラスのIRRのみを照会する必要があるため、この場合、完全な互換性は問題になりません。
Before adding a new class, one should question if the information contained in the objects of the new class could have better belonged to some other class. For example, if the geographic location of a router needs to be stored in IRR, it may be tempting to add a new class called, say router-location class. However, the information better belongs to the inet-rtr class, perhaps in a new attribute called location.
新しいクラスを追加する前に、新しいクラスのオブジェクトに含まれる情報が他のクラスに属していた場合があるかどうかを疑問視する必要があります。たとえば、ルーターの地理的位置をIRRに保存する必要がある場合、ルーターロケーションクラスと呼ばれる新しいクラスを追加するのが魅力的かもしれません。ただし、情報は、おそらく場所と呼ばれる新しい属性で、INET-RTRクラスに属します。
If all of the methods described above fail to provide the desired extension, it may be necessary to change the syntax of RPSL. Any change in RPSL syntax must provide backwards compatibility, and should be considered only as a last resort since full compatibility may not be achievable. However, we require that the old syntax to be still valid.
上記のすべての方法が目的の拡張機能を提供できない場合、RPSLの構文を変更する必要がある場合があります。RPSL構文の変更は、逆方向の互換性を提供する必要があり、完全な互換性が達成できない可能性があるため、最後の手段としてのみ考慮する必要があります。ただし、古い構文がまだ有効であることが必要です。
11 Security Considerations
11セキュリティ上の考慮事項
This document describes RPSL, a language for expressing routing policies. The language defines a maintainer (mntner class) object which is the entity which controls or "maintains" the objects stored in a database expressed by RPSL. Requests from maintainers can be authenticated with various techniques as defined by the "auth" attribute of the maintainer object.
このドキュメントは、ルーティングポリシーを表現するための言語であるRPSLについて説明しています。言語は、RPSLが表現するデータベースに保存されているオブジェクトを制御または「維持」するエンティティであるメンテナー（MNTNERクラス）オブジェクトを定義します。メンテナーからのリクエストは、メンテナーオブジェクトの「AUTH」属性で定義されているさまざまな手法で認証できます。
The exact protocols used by IRR's to communicate RPSL objects is beyond the scope of this document, but it is envisioned that several techniques may be used, ranging from interactive query/update protocols to store and forward protocols similar to or based on electronic mail (or even voice telephone calls). Regardless of which protocols are used in a given situation, it is expected that appropriate security techniques such as IPSEC, TLS or PGP/MIME will be utilized.
RPSLオブジェクトを通信するためにIRRが使用する正確なプロトコルは、このドキュメントの範囲を超えていますが、インタラクティブなクエリ/更新プロトコルから、電子メールと同様のプロトコルを保存および転送する（または）（または）プロトコルを保存および転送するために、いくつかの手法を使用できることが想定されています。音声電話でさえ）。特定の状況でどのプロトコルが使用されるかに関係なく、IPSEC、TLS、PGP/MIMEなどの適切なセキュリティ手法が利用されることが期待されています。
12 Acknowledgements
12謝辞
We would like to thank Jessica Yu, Randy Bush, Alan Barrett, Bill Manning, Sue Hares, Ramesh Govindan, Kannan Varadhan, Satish Kumar, Craig Labovitz, Rusty Eddy, David J. LeRoy, David Whipple, Jon Postel, Deborah Estrin, Elliot Schwartz, Joachim Schmitz, Mark Prior, Tony Przygienda, David Woodgate, Rob Coltun, Sanjay Wadhwa, Ardas Cilingiroglu, and the participants of the IETF RPS Working Group for various comments and suggestions.
ジェシカ・ユー、ランディ・ブッシュ、アラン・バレット、ビル・マニング、スー・ハレス、ラメシュ・ゴヴィンダン、カンナン・バラダン、サティシュ・クマール、クレイグ・ラボヴィッツ、ラスティ・エディ、デイビッド・J・リロイ、デビッド・ホイップル、ジョン・ポスエル、デボラ・エスティン、エリオットに感謝しますシュワルツ、ヨアヒム・シュミッツ、マーク・プライア、トニー・プリギエンダ、デビッド・ウッドゲート、ロブ・コルトゥン、サンジェイ・ワドワ、アルダス・カリンガル、およびIETF RPSワーキンググループの参加者は、さまざまなコメントや提案をしています。
References
参考文献
[1] Internet routing registry. procedures. http://www.ra.net/RADB.tools.docs/, http://www.ripe.net/db/doc.html.
[1] インターネットルーティングレジストリ。手順。http://www.ra.net/radb.tools.docs/、http://www.ripe.net/db/doc.html。
[2] Nsfnet policy routing database (prdb). Maintained by MERIT Network Inc., Ann Arbor, Michigan. Contents available from nic.merit.edu.:/nsfnet/announced.networks/nets.tag.now by anonymous ftp.
[2] NSFNETポリシールーティングデータベース（PRDB）。ミシガン州アナーバーのMerit Network Inc.が維持。nic.merit.edu.：/nsfnet/announced.networks/nets.tag.nowから入手可能なコンテンツ。
[3] Alaettinouglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer, D., Terpstra, M. and C. Villamizer, "Routing Policy Specification Language (RPSL)", RFC 2280, January 1998.
[3] Alaettinouglu、C.、Bates、T.、Gerich、E.、Karrenberg、D.、Meyer、D.、Terpsstra、M。、およびC. Villamizer、「ルーティングポリシー仕様言語（RPSL）」、RFC 2280、1998年1月。
[4] C. Alaettinouglu, D. Meyer, and J. Schmitz. Application of routing policy specification language (rpsl) on the internet. Work in Progress.
[4] C. Alaettinouglu、D。Meyer、およびJ. Schmitz。インターネット上のルーティングポリシー仕様言語（RPSL）の適用。進行中の作業。
[5] T. Bates. Specifying an `internet router' in the routing registry. Technical Report RIPE-122, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.
[5] T.ベイツ。ルーティングレジストリで「インターネットルーター」を指定します。テクニカルレポートRIPE-122、Ripe、Ripe NCC、アムステルダム、オランダ、1994年10月。
[6] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu. Representation of ip routing policies in a routing registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.
[6] T.ベイツ、E。ジェリッヒ、L。ジョンシェイ、J-M。Jouanigot、D。Karrenberg、M。Terpsstra、およびJ. Yu。ルーティングレジストリでのIPルーティングポリシーの表現。Technical Report Ripe-181、Ripe、Ripe NCC、アムステルダム、オランダ、1994年10月。
[7] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., Karrenberg, D., Terpstra, M. and J. Yu, " Representation of IP Routing Policies in a Routing Registry", RFC 1786, March 1995.
[7] Bates、T.、Gerich、E.、Joncheray、L.、Jouanigot、J-M。、Karrenberg、D.、Terpsstra、M。and J. Yu、「ルーティングレジストリにおけるIPルーティングポリシーの表現」、RFC 1786、3月1995年。
[8] T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M. Terpstra. Representation of ip routing policies in the ripe database. Technical Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993.
[8] T.ベイツ、J-M。Jouanigot、D。Karrenberg、P。Lothberg、およびM. Terpsstra。熟したデータベースでのIPルーティングポリシーの表現。テクニカルレポートRIPE-81、Ripe、Ripe NCC、アムステルダム、オランダ、1993年2月。
[9] Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[9] Chandra、R.、Traina、P。and T. Li、「BGP Communities Attribute」、RFC 1997、1996年8月。
[10] Crocker, D., "Standard for ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[10] Crocker、D。、「ARPAインターネットテキストメッセージの標準」、STD 11、RFC 822、1982年8月。
[11] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[11] Fuller、V.、Li、T.、Yu、J。、およびK. Varadhan、「クラスレスインタードメインルーティング（CIDR）：アドレス割り当てと集約戦略」、RFC 1519、1993年9月。
[12] D. Karrenberg and T. Bates. Description of inter-as networks in the ripe routing registry. Technical Report RIPE-104, RIPE, RIPE NCC, Amsterdam, Netherlands, December 1993.
[12] D.カレンバーグとT.ベイツ。RIPEルーティングレジストリのAS Inter-ASネットワークの説明。テクニカルレポートRIPE-104、Ripe、Ripe NCC、アムステルダム、オランダ、1993年12月。
[13] D. Karrenberg and M. Terpstra. Authorisation and notification of changes in the ripe database. Technical Report ripe-120, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.
[13] D.カレンバーグとM.テルプストラ。熟したデータベースの変更の承認と通知。1994年10月、オランダ、アムステルダム、Ripe、Ripe、Ripe NCC、Ripe、Ripe NCC、Ripe、Ripe NCC、1994年10月。
[14] B. W. Kernighan and D. M. Ritchie. The C Programming Language. Prentice-Hall, 1978.
[14] B. W. KernighanおよびD. M. Ritchie。Cプログラミング言語。Prentice-Hall、1978年。
[15] A. Lord and M. Terpstra. Ripe database template for networks and persons. Technical Report ripe-119, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.
[15] A.ロードとM.テルプストラ。ネットワークとパーソン用のRIPEデータベーステンプレート。テクニカルレポートRIPE-119、Ripe、Ripe NCC、アムステルダム、オランダ、1994年10月。
[16] A. M. R. Magee. Ripe ncc database documentation. Technical Report RIPE-157, RIPE, RIPE NCC, Amsterdam, Netherlands, May 1997.
[16] A. M. R.マギー。RIPE NCCデータベースドキュメント。テクニカルレポートRIPE-157、RIPE、RIPE NCC、アムステルダム、オランダ、1997年5月。
[17] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[17] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[18] Y. Rekhter. Inter-domain routing protocol (idrp). Journal of Internetworking Research and Experience, 4:61--80, 1993.
[18] Y. Rekhter。ドメイン間ルーティングプロトコル（IDRP）。Journal of InternetWorking Research and Experience、4：61--80、1993。
[19] Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[19] Rekhter Y.およびT. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[20] C. Villamizar, C. Alaettinouglu, D. Meyer, S. Murphy, and C. Orange. Routing policy system security", Work in Progress.
[20] C. Villamizar、C。Alaettinouglu、D。Meyer、S。Murphy、およびC. Orange。ルーティングポリシーシステムのセキュリティ」、進行中の作業。
[21] Villamizar, C., Chandra, R. and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[21] Villamizar、C.、Chandra、R。and R. Govindan、「BGP Route Flap Damping」、RFC 2439、1998年11月。
[22] J. Zsako, "PGP authentication for ripe database updates", Work in Progress.
[22] J. Zsako、「Ripe Database UpdatesのPGP認証」、進行中の作業。
A Routing Registry Sites
ルーティングレジストリサイト
The set of routing registries as of November 1996 are RIPE, RADB, CANet, MCI and ANS. You may contact one of these registries to find out the current list of registries.
1996年11月現在のルーティングレジストリのセットは、熟した、RADB、カネ、MCI、ANSです。これらのレジストリのいずれかに連絡して、現在のレジストリリストを見つけることができます。
B Grammar Rules
B文法規則
In this section we provide formal grammar rules for RPSL. Basic data types are defined in Section 2. We do not provide formal grammar rules for attributes whose values are of basic types or list of basic types. The rules are written using the input language of GNU Bison parser. Hence, they can be cut and pasted to that program.
このセクションでは、RPSLの正式な文法規則を提供します。基本的なデータ型は、セクション2で定義されています。基本タイプまたは基本タイプのリストである属性の正式な文法規則は提供していません。ルールは、GNUバイソンパーサーの入力言語を使用して記述されます。したがって、それらをカットしてそのプログラムに貼り付けることができます。
//**** Generic Attributes **********************************************
changed_attribute: ATTR_CHANGED TKN_EMAIL TKN_INT
chanded_attribute：attr_changed tkn_email tkn_int
//**** aut-num class ***************************************************
//// as_expression /////////////////////////////////////////////////////
/// as_expression ///////////////////////////////////////////
opt_as_expression: | as_expression
opt_as_expression：|as_expression
as_expression: as_expression OP_OR as_expression_term | as_expression_term
as_expression：as_expression op_or as_expression_term |as_expression_term
as_expression_term: as_expression_term OP_AND as_expression_factor | as_expression_term KEYW_EXCEPT as_expression_factor | as_expression_factor
as_expression_term：as_expression_term op_and as_expression_factor |as_expression_term keyw_excect as_expression_factor |as_expression_factor
as_expression_factor: '(' as_expression ')' | as_expression_operand
as_expression_factor： '（' as_expression '）' |as_expression_operand
as_expression_operand: TKN_ASNO | TKN_ASNAME
as_expression_operand：tkn_asno |tkn_asname
//// router_expression /////////////////////////////////////////////////
/// router_expression /////////////////////////////////////////
opt_router_expression: | router_expression
opt_router_expression：|router_expression
opt_router_expression_with_at: | KEYW_AT router_expression
opt_router_expression_with_at：|keyw_at router_expression
router_expression: router_expression OP_OR router_expression_term
| router_expression_term
router_expression_term: router_expression_term OP_AND
router_expression_factor
| router_expression_term KEYW_EXCEPT router_expression_factor
| router_expression_factor
router_expression_factor: '(' router_expression ')' | router_expression_operand
router_expression_factor： '（' router_expression '）' |router_expression_operand
router_expression_operand: TKN_IPV4 | TKN_DNS | TKN_RTRSNAME
router_expression_operand：tkn_ipv4 |tkn_dns |tkn_rtrsname
//// peering ///////////////////////////////////////////////////////////
/// Peering ///////////////////////////////////////////////////////////
peering: as_expression opt_router_expression opt_router_expression_with_at | TKN_PRNGNAME
ピアリング：as_expression opt_router_expression opt_router_expression_with_at |tkn_prngname
//// action ////////////////////////////////////////////////////////////
//// アクション //////////////////////////////////////////////////////////
opt_action: | KEYW_ACTION action
opt_action：|keyw_actionアクション
action: single_action
| action single_action
single_action: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')' ';'
| TKN_RP_ATTR TKN_OPERATOR list_item ';'
| TKN_RP_ATTR '(' generic_list ')' ';'
| TKN_RP_ATTR '[' generic_list ']' ';'
| ';'
//// filter ////////////////////////////////////////////////////////////
//// フィルター //////////////////////////////////////////////////////////
filter: filter OP_OR filter_term | filter filter_term %prec OP_OR | filter_term
フィルター：フィルターop_or filter_term |フィルターフィルター％パーフop_or |filter_term
filter_term : filter_term OP_AND filter_factor | filter_factor
filter_term：filter_term op_and filter_factor |filter_factor
filter_factor : OP_NOT filter_factor | '(' filter ')' | filter_operand
filter_factor：op_not filter_factor |'（'フィルター） '|filter_operand
filter_operand: KEYW_ANY
| '<' filter_aspath '>'
| filter_rp_attribute
| TKN_FLTRNAME
| filter_prefix
filter_prefix: filter_prefix_operand OP_MS
| filter_prefix_operand
filter_prefix_operand: TKN_ASNO
| KEYW_PEERAS
| TKN_ASNAME
| TKN_RSNAME
| '{' opt_filter_prefix_list '}'
opt_filter_prefix_list: | filter_prefix_list
opt_filter_prefix_list：|filter_prefix_list
filter_prefix_list: filter_prefix_list_prefix | filter_prefix_list ',' filter_prefix_list_prefix
filter_prefix_list：filter_prefix_list_prefix |filter_prefix_list '、' filter_prefix_list_prefix
filter_prefix_list_prefix: TKN_PRFXV4 | TKN_PRFXV4RNG
filter_prefix_list_prefix：tkn_prfxv4 |tkn_prfxv4rng
filter_aspath: filter_aspath '|' filter_aspath_term | filter_aspath_term
filter_aspath：filter_aspath '|'filter_aspath_term |filter_aspath_term
filter_aspath_term: filter_aspath_term filter_aspath_closure | filter_aspath_closure
filter_aspath_term：filter_aspath_term filter_aspath_closure |filter_aspath_closure
filter_aspath_closure: filter_aspath_closure '*'
| filter_aspath_closure '?'
| filter_aspath_closure '+'
| filter_aspath_factor
filter_aspath_factor: '^'
| '$'
| '(' filter_aspath ')'
| filter_aspath_no
filter_aspath_no: TKN_ASNO
| KEYW_PEERAS
| TKN_ASNAME
| '.'
| '[' filter_aspath_range ']'
| '[' '^' filter_aspath_range ']'
filter_aspath_range:
| filter_aspath_range TKN_ASNO
| filter_aspath_range KEYW_PEERAS
| filter_aspath_range '.'
| filter_aspath_range TKN_ASNO '-' TKN_ASNO
| filter_aspath_range TKN_ASNAME
filter_rp_attribute: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')'
| TKN_RP_ATTR TKN_OPERATOR list_item
| TKN_RP_ATTR '(' generic_list ')'
| TKN_RP_ATTR '[' generic_list ']'
//// peering action pair ///////////////////////////////////////////////
///ピアリングアクションペア//////////////////////////////////////////////////
import_peering_action_list: KEYW_FROM peering opt_action | import_peering_action_list KEYW_FROM peering opt_action
import_peering_action_list：keyw_from pearing opt_action |import_peering_action_list keyw_from peering opt_action
export_peering_action_list: KEYW_TO peering opt_action | export_peering_action_list KEYW_TO peering opt_action
export_peering_action_list：keyw_to peering opt_action |export_peering_action_list keyw_to peering opt_action
//// import/export factor //////////////////////////////////////////////
///インポート/エクスポートファクター//////////////////////////////////////////////
import_factor: import_peering_action_list KEYW_ACCEPT filter
import_factor：import_peering_action_list keyw_acceptフィルター
import_factor_list: import_factor ';' | import_factor_list import_factor ';'
import_factor_list：import_factor ';'|import_factor_list import_factor ';'
export_factor: export_peering_action_list KEYW_ANNOUNCE filter
export_factor：export_peering_action_list keyw_announceフィルター
export_factor_list: export_factor ';' | export_factor_list export_factor ';'
export_factor_list：export_factor ';'|Export_Factor_List Export_Factor ';'
//// import/export term ////////////////////////////////////////////////
///インポート/エクスポート用語/////////////////////////////////////////////////////
import_term: import_factor ';'
| '{' import_factor_list '}'
export_term: export_factor ';'
| '{' export_factor_list '}'
//// import/export expression //////////////////////////////////////////
///インポート/エクスポート式////////////////////////////////////////////////
import_expression: import_term | import_term KEYW_REFINE import_expression | import_term KEYW_EXCEPT import_expression
import_expression：import_term |import_term keyw_refine import_expression |import_term keyw_except import_expression
export_expression: export_term | export_term KEYW_REFINE export_expression | export_term KEYW_EXCEPT export_expression
export_expression：export_term |export_term keyw_refine export_expression |export_term keyw_except export_expression
//// protocol ///////////////////////////////////////////////////////////
/// Protocol ///////////////////////////////////////////////////
opt_protocol_from: | KEYW_PROTOCOL tkn_wordopt_protocol_into: | KEYW_INTO tkn_word
opt_protocol_from：|keyw_protocol tkn_word opt_protocol_into：|keyw_into tkn_word
//**** import/export attributes ****************************************
import_attribute: ATTR_IMPORT | ATTR_IMPORT opt_protocol_from opt_protocol_into import_factor
import_attribute：attr_import |attr_import opt_protocol_from opt_protocol_into import_factor
export_attribute: ATTR_EXPORT | ATTR_EXPORT opt_protocol_from opt_protocol_into export_factor
export_attribute：attr_export |attr_export opt_protocol_from opt_protocol_into export_factor
opt_default_filter: | KEYW_NETWORKS filter
opt_default_filter：|keyw_networksフィルター
default_attribute: ATTR_DEFAULT KEYW_TO peering
default_attribute：attr_default keyw_to peering
filter_attribute: ATTR_FILTER filter
filter_attribute：attr_filterフィルター
peering_attribute: ATTR_PEERING peering
peering_attribute：attr_peering Peering
//**** inet-rtr class **************************************************
ifaddr_attribute: ATTR_IFADDR TKN_IPV4 KEYW_MASKLEN TKN_INT opt_action
ifaddr_attribute：attr_ifaddr tkn_ipv4 keyw_masklen tkn_int opt_action
//// peer attribute ////////////////////////////////////////////////////
///ピア属性/////////////////////////////////////////////////////
opt_peer_options: | peer_options
opt_peer_options：|peer_options
peer_options: peer_option | peer_options ',' peer_option
peer_options：peer_option |peer_options '、' peer_option
peer_option: tkn_word '(' generic_list ')'
peer_option：tkn_word '（' generic_list '）'
peer_id: TKN_IPV4
| TKN_DNS
| TKN_RTRSNAME
| TKN_PRNGNAME
peer_attribute: ATTR_PEER tkn_word peer_id opt_peer_options
peer_attribute：attr_peer tkn_word peer_id opt_peer_options
//**** route class *****************************************************
aggr_bndry_attribute: ATTR_AGGR_BNDRY as_expression
aggr_bndry_attribute：attr_aggr_bndry as_expression
aggr_mtd_attribute: ATTR_AGGR_MTD KEYW_INBOUND | ATTR_AGGR_MTD KEYW_OUTBOUND opt_as_expression
aggr_mtd_attribute：attr_aggr_mtd keyw_inbound |attr_aggr_mtd keyw_outbound opt_as_expression
//// inject attribute //////////////////////////////////////////////////
/// inject属性/////////////////////////////////////////////////////
opt_inject_expression: | KEYW_UPON inject_expression
opt_inject_expression：|keyw_upon inject_expression
inject_expression: inject_expression OP_OR inject_expression_term | inject_expression_term
Inject_Expression：Inject_Expression op_or inject_expression_term |Inject_expression_term
inject_expression_term: inject_expression_term OP_AND inject_expression_factor | inject_expression_factor
Inject_expression_term：Inject_expression_term op_and inject_expression_factor |Inject_Expression_Factor
inject_expression_factor: '(' inject_expression ')' | inject_expression_operand
Inject_expression_Factor： '（' Indect_expression '）' |Inject_expression_operand
inject_expression_operand: KEYW_STATIC
| KEYW_HAVE_COMPONENTS '{' opt_filter_prefix_list '}'
| KEYW_EXCLUDE '{' opt_filter_prefix_list '}'
inject_attribute: ATTR_INJECT opt_router_expression_with_at opt_action opt_inject_expression
Inject_attribute：attr_inject opt_router_expression_with_at opt_action opt_inject_expression
//// components attribute //////////////////////////////////////////////
///コンポーネント属性///////////////////////////////////////////////
opt_atomic: | KEYW_ATOMIC
opt_atomic：|keyw_atomic
components_list: | filter | components_list KEYW_PROTOCOL tkn_word filter
components_list：|フィルター|components_list keyw_protocol tkn_wordフィルター
components_attribute: ATTR_COMPONENTS opt_atomic components_list
components_attribute：attr_components opt_atomic components_list
//**** route-set *******************************************************
opt_rs_members_list: /* empty list */
| rs_members_list
rs_members_list: rs_member | rs_members_list ',' rs_member
rs_members_list：rs_member |rs_members_list '、' rs_member
rs_member: TKN_ASNO
| TKN_ASNO OP_MS
| TKN_ASNAME
| TKN_ASNAME OP_MS
| TKN_RSNAME
| TKN_RSNAME OP_MS
| TKN_PRFXV4
| TKN_PRFXV4RNG
|tkn_prfxv4rng
rs_members_attribute: ATTR_RS_MEMBERS opt_rs_members_list
rs_members_attribute：attr_rs_members opt_rs_members_list
//**** dictionary ******************************************************
rpattr_attribute: ATTR_RP_ATTR TKN_WORD methods | ATTR_RP_ATTR TKN_RP_ATTR methods
rpattr_attribute：attr_rp_attr tkn_wordメソッド|attr_rp_attr tkn_rp_attrメソッド
methods: method | methods method
方法：方法|メソッドメソッド
method: TKN_WORD '(' ')'
| TKN_WORD '(' typedef_type_list ')'
| TKN_WORD '(' typedef_type_list ',' TKN_3DOTS ')'
| KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ')'
| KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ',' TKN_3DOTS ')'
//// typedef attribute ////////////////////////////////////////////////
/// typedef属性///////////////////////////////////////
typedef_attribute: ATTR_TYPEDEF TKN_WORD typedef_type
typedef_attribute：attr_typedef tkn_word typedef_type
typedef_type_list: typedef_type | typedef_type_list ',' typedef_type
typedef_type_list：typedef_type |typedef_type_list '、' typedef_type
typedef_type: KEYW_UNION typedef_type_list
| KEYW_RANGE KEYW_OF typedef_type
| TKN_WORD
| TKN_WORD '[' TKN_INT ',' TKN_INT ']'
| TKN_WORD '[' TKN_REAL ',' TKN_REAL ']'
| TKN_WORD '[' enum_list ']'
| KEYW_LIST '[' TKN_INT ':' TKN_INT ']' KEYW_OF typedef_type
| KEYW_LIST KEYW_OF typedef_type
enum_list: tkn_word | enum_list ',' tkn_word
enum_list：tkn_word |enum_list '、' tkn_word
//// protocol attribute ////////////////////////////////////////////////
/// protocol属性/////////////////////////////////////////////
protocol_attribute: ATTR_PROTOCOL tkn_word protocol_options
protocol_attribute：attr_protocol tkn_word protocol_options
protocol_options: | protocol_options protocol_option
protocol_options：|protocol_options protocol_option
protocol_option: KEYW_MANDATORY method | KEYW_OPTIONAL method
protocol_option：keyw_mandatoryメソッド|keyw_optionalメソッド
//**** Token Definitions ***********************************************
//// flex macros used in token definitions /////////////////////////////
INT [[:digit:]]+
SINT [+-]?{INT}
REAL [+-]?{INT}?\.{INT}({WS}*E{WS}*[+-]?{INT})?
NAME [[:alpha:]]([[:alnum:]_-]*[[:alnum:]])?
ASNO AS{INT}
ASNAME AS-[[:alnum:]_-]*[[:alnum:]]
RSNAME RS-[[:alnum:]_-]*[[:alnum:]]
RTRSNAME RTRS-[[:alnum:]_-]*[[:alnum:]]
PRNGNAME PRNG-[[:alnum:]_-]*[[:alnum:]]
FLTRNAME FLTR-[[:alnum:]_-]*[[:alnum:]]
IPV4 [0-9]+(\.[0-9]+){3,3}
PRFXV4 {IPV4}\/[0-9]+
PRFXV4RNG {PRFXV4}("^+"|"^-"|"^"{INT}|"^"{INT}-{INT})
ENAMECHAR [^()<>,;:\\\"\.[\] \t\r]
ENAME ({ENAMECHAR}+(\.{ENAMECHAR}+)*\.?)|(\"[^\"@\\\r\n]+\")
DNAME [[:alnum:]_-]+
//// Token Definitions ////////////////////////////////////////////////
TKN_INT {SINT}
TKN_INT {INT}:{INT} if each {INT} is two octets
TKN_INT {INT}.{INT}.{INT}.{INT} if each {INT} is one octet
TKN_REAL {REAL}
TKN_STRING Same as in programming language C
TKN_IPV4 {IPV4}
TKN_PRFXV4 {PRFXV4}
TKN_PRFXV4RNG {PRFXV4RNG}
TKN_ASNO {ASNO}
TKN_ASNAME (({ASNO}|peeras|{ASNAME}):)*{ASNAME}\
(:({ASNO}|peeras|{ASNAME}))*
TKN_RSNAME (({ASNO}|peeras|{RSNAME}):)*{RSNAME}\
(:({ASNO}|peeras|{RSNAME}))*
TKN_RTRSNAME (({ASNO}|peeras|{RTRSNAME}):)*{RTRSNAME}\
(:({ASNO}|peeras|{RTRSNAME}))*
TKN_PRNGNAME (({ASNO}|peeras|{PRNGNAME}):)*{PRNGNAME}\
(:({ASNO}|peeras|{PRNGNAME}))*
TKN_FLTRNAME (({ASNO}|peeras|{FLTRNAME}):)*{FLTRNAME}\
(:({ASNO}|peeras|{FLTRNAME}))*
TKN_BOOLEAN true|false
TKN_RP_ATTR {NAME} if defined in dictionary
TKN_WORD {NAME}
TKN_DNS {DNAME}("."{DNAME})+
TKN_EMAIL {ENAME}@({DNAME}("."{DNAME})+|{IPV4})
C Changes from RFC 2280
RFC 2280 [3] contains an earlier version of RPSL. This section summarizes the changes since then. They are as follows:
RFC 2280 [3]には、RPSLの以前のバージョンが含まれています。このセクションでは、それ以来の変更を要約します。彼らは次のとおりです：
o It is now possible to write integers as sequence of four 1-octet integers (e.g. 1.1.1.1) or as sequence of two 2-octet integers (e.g. 3561:70). Please see Section 2.
o 現在、整数を4つの1-OCTET整数のシーケンス（例えば1.1.1.1）または2つの2オクテットの整数のシーケンス（3561：70など）として記述することが可能になりました。セクション2を参照してください。
o The definition of address prefix range is extended so that an address prefix is also an address prefix range. Please see Section 2.
o アドレスプレフィックス範囲の定義は拡張されているため、アドレスプレフィックスもアドレスプレフィックス範囲になります。セクション2を参照してください。
o The semantics for a range operator applied to a set containing address prefix ranges is defined (e.g. {30.0.0.0/8^24-28}^27-30). Please see Section 2.
o アドレスのプレフィックス範囲を含むセットに適用される範囲演算子のセマンティクスは定義されています（例：{30.0.0.0/8^24-28} ^27-30）。セクション2を参照してください。
o All dates are now in UTC. Please see Section 2.
o すべての日付は現在UTCにあります。セクション2を参照してください。
o Plus ('+') character is added to space and tab characters to split an attribute's value to multiple lines (i.e. by starting the following lines with a space, a tab or a plus ('+') character). Please see Section 2.
o プラス（ ''）文字がスペースとタブ文字に追加され、属性の値を複数の行に分割します（つまり、スペース、タブ、またはプラス（ ''）文字で次の行を開始することにより）。セクション2を参照してください。
o The withdrawn attribute of route class is removed from the language.
o ルートクラスの撤回された属性は、言語から削除されます。
o filter-set class is introduced. Please see Section 5.4.
o フィルターセットクラスが導入されています。セクション5.4を参照してください。
o rtr-set class is introduced. Please see Section 5.5.
o RTRセットクラスが導入されています。セクション5.5を参照してください。
o peering-set class is introduced. Please see Section 5.6.
o ピアリングセットクラスが導入されています。セクション5.6を参照してください。
o Filters can now refer to filter-set names. Please see Section 5.4.
o フィルターがフィルターセット名を参照できるようになりました。セクション5.4を参照してください。
o Peerings can now refer to peering-set, rtr-set names. Both local and peer routers can be specified using router expressions. Please see Section 5.6.
o ピーリングは、ピアリングセット、RTRセット名を参照できるようになりました。ローカルルーターとピアルーターの両方を、ルーター式を使用して指定できます。セクション5.6を参照してください。
o The peer attribute of the inet-rtr class can refer to peering-set, rtr-set names. Please see Section 9.
o INET-RTRクラスのピア属性は、ピアリングセット、RTRセット名を参照できます。セクション9を参照してください。
o The syntax and semantics of union, and list types and typedef attribute have changed. Please see Section 7.
o ユニオンの構文とセマンティクス、およびリストタイプとtypedef属性が変更されました。セクション7を参照してください。
o In the initial dictionary, the typedef attribute defining the community_elm, rp-attribute defining the community attribute has changed. Please see Section 7.
o 最初の辞書では、community_elmを定義するtypedef属性、community属性を定義するrp-aTtributeが変更されました。セクション7を参照してください。
o Guideliness for extending RPSL is added. Please see Section 10.
o RPSLを拡張するためのガイドラインが追加されます。セクション10を参照してください。
o Formal grammar rules are added. Please see Appendix B.
o 正式な文法ルールが追加されています。付録Bをご覧ください
D Authors' Addresses
D著者の住所
Cengiz Alaettinoglu USC/Information Sciences Institute
Cengiz Alaettinoglu USC/Information Sciences Institute
EMail: cengiz@isi.edu
Curtis Villamizar Avici Systems
Curtis Villamizar Aviciシステム
EMail: curtis@avici.com
Elise Gerich At Home Network
Elise Gerich at Home Network
EMail: epg@home.net
David Kessens Qwest Communications
David Kessens QWest Communications
EMail: David.Kessens@qwest.net
David Meyer University of Oregon
オレゴンのデイビッド・マイヤー大学
EMail: meyer@antc.uoregon.edu
Tony Bates Cisco Systems, Inc.
Tony Bates Cisco Systems、Inc。
EMail: tbates@cisco.com
Daniel Karrenberg RIPE NCC
ダニエル・カレンバーグ熟したNCC
EMail: dfk@ripe.net
Marten Terpstra c/o Bay Networks, Inc.
Marten Terpsstra c/o Bay Networks、Inc。
EMail: marten@BayNetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、配布されます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。