Inter-Domain Policy Routing Working Group H. Bowns and M. Steenstrup Internet Draft BBN Communications July 1991 Inter-Domain Policy Routing Configuration and Usage Status of this Memo This draft document will be submitted to the RFC editor as a companion to the IDPR protocol specification. Distribution of this memo is unlimited. Please send comments to idpr-wg@bbn.com. Abstract We present a set of configuration guidelines for inter-domain policy routing (IDPR). In particular, we discuss topology, addressing, policies, and interactions with both intra-domain and inter-domain routing. Also, we provide a copy of the IDPR configuration template and give examples of its use. Contributors The following people have contributed to the IDPR configuration guide: Helen Bowns, Lee Breslau, Ken Carlberg, Deborah Estrin, Martha Steenstrup, and Robert Woodburn. Internet Draft IDPR Configuration July 1991 Contents 1 Introduction 1 1.1 What IDPR Provides 1 2 IDPR for Your Domain 3 3 Configuring Topology 6 3.1 Virtual Gateways 6 3.1.1 The Adjoining Domain 6 3.2 IDPR Entities within a Domain 8 3.2.1 Route Servers 9 3.2.2 Configuration Servers 10 4 IDPR Configuration Parameters and Files 11 5 Entity Configuration Parameters 12 5.1 The File idpr.domain 18 6 Policy Configuration Parameters 21 6.1 Access Restrictions 21 6.1.1 Domain Sets 22 6.1.2 Host Sets 22 6.2 Source Policies 23 6.2.1 Requested Services 24 6.2.2 Source Policy Syntax 25 6.3 Transit Policies 29 6.3.1 Offered Services 30 6.3.2 Transit Policy Syntax 30 6.3.3 The File idpr.policies 35 i Internet Draft IDPR Configuration July 1991 6.4 Service Definitions 43 6.4.1 The File idpr.services 45 7 System Configuration Parameters 51 7.1 Destination Domain Resolution 51 7.2 IDPR Protocol Parameters 51 7.2.1 The File idpr.system 52 ii Internet Draft IDPR Configuration July 1991 1 Introduction This document contains all the information necessary to configure an administrative domain to support inter-domain policy routing (IDPR). IDPR is a set of protocols and procedures designed to provide routing among administrative domains, simultaneously satisfying user service requirements and obeying transit service restrictions. We define an administrative domain (AD) as a collection of contiguous networks, gateways, links, and hosts managed by a single administrative authority. The domain administrator defines service restrictions for transit traffic and service requirements for locally generated traffic and selects the addressing schemes and routing procedures applicable within the domain. Intended especially for domain administrators, this IDPR configuration guide is self-contained. One need not have any prior knowledge of IDPR in order to use this document effectively. However, those interested in details of the IDPR architecture and protocols should consult [1] and [2]; those interested in IDPR network management should consult [3]. 1.1 What IDPR Provides The objective of IDPR is to construct and maintain routes between source and destination administrative domains, that provide user traffic with the requested services within the constraints stipulated for the domains transited. With IDPR, each domain administrator configures transit policies that dictate how and by whom the resources in its domain should be used. The configured transit policies specify the services offered by the domain, including: 1.Access restrictions: depending upon source and destination hosts and domains, user classes, and time of day. 2.Quality: intra-domain delay, delay variance, and throughput. 3.Cost: charge per byte, message, or session time. A domain's transit policies form part of the routing information distributed by IDPR throughout the Internet and hence are known in all Internet domains that support IDPR. Each domain administrator also configures source policies that apply to 1 Internet Draft IDPR Configuration July 1991 individual hosts or groups of hosts for which the domain is responsible as generator of IDPR routes. The configured source policies specify the services requested by the hosts, including: 1.Access restrictions: domains to favor or avoid in routes. 2.Quality: acceptable delay, delay variance, and throughput. 3.Cost: acceptable cost per byte, message, or session time. A domain's source policies are usually private and hence are not known outside of the source domain for which they are configured. IDPR accounts for both source and transit policies when generating routes between source and destination domains. Configuring transit policies controls the use of a domain's resources by promoting generation of routes that are consistent with the domain's service restrictions. Configuring source policies controls the service that user traffic receives by promoting generation of routes that are consistent with the user's service requirements. Moreover, IDPR completely specifies the route to the destination domain. Traffic routed with IDPR follows the specified path; there are no independent routing decisions at intermediate domains. IDPR includes several mechanisms for ensuring secure and reliable delivery of IDPR control information, which minimize the chances of generating and installing invalid routes resulting from corrupted control information. Also, IDPR possesses source selectable mechanisms for maintaining secure and reliable data transmission over IDPR routes. 2 Internet Draft IDPR Configuration July 1991 2 IDPR for Your Domain We believe that most Internet domains will benefit from the introduction of IDPR. However, the decision to support IDPR is an individual one, left to each domain administrator. When deciding whether to configure your domain to support IDPR, you should carefully consider the following questions. Do my hosts communicate with hosts outside of my domain? We expect that most domains will contain at least some hosts that communicate with hosts outside of their immediate domain. With intra-domain communication, the domain administrator has tight control over routing, while with inter-domain communication, the domain administrator is often forced to relinquish some control over routing. IDPR, however, allows the domain administrator to retain control over inter-domain communication, through source specification of routes. Thus, hosts with special routing requirements, communicating across several domains, can benefit from the complete routing control offered by the source specified routes provided through IDPR. Do my hosts run a variety of applications? Each host application has a set of service requirements. Some applications such as electronic mail and file transfer may have few requirements other than uncorrupted delivery. However, other applications such as videoconferencing and scientific visualization have stringent delay and throughput requirements. Host applications with strict service requirements can benefit from the quality of service routing provided by IDPR. Can my domain support multiple inter-domain routing procedures? IDPR can comfortably coexist with other inter-domain routing procedures available in the Internet, without any adverse affects. Within a domain, the domain administrator configures which hosts flows are to use which inter-domain routing procedures. Moreover, when implemented as part of gated, independent inter-domain routing procedures can be adapted to share each other's routing information. IDPR will be, but is not yet, available in gated. Does my domain provide transit service for traffic originating outside of my domain? There are two basic types of Internet domains: transit domains that provide some degree of transit service for inter-domain traffic and stub domains that are only sources and sinks for inter-domain traffic. We expect that transit domains will fall into one of two categories: 3 Internet Draft IDPR Configuration July 1991 1.Those that offer a wide variety of qualities of service to a large number of host flows, depending upon tariff paid. 2.Those that offer transit service to a small number of host flows, depending upon the characteristics of the traffic. In each case, there are specific service offerings and restrictions associated with the transit domain. Resources in such domains can be protected by the policy sensitive routing provided by IDPR. How does IDPR interact with my intra-domain routing procedures? IDPR relies on intra-domain routing to route IDPR traffic across a domain and to provide reachability and quality of service information about the domain. However, IDPR will only use information generated by the intra-domain routing procedure itself; it not use any routing information that the intra-domain routing procedure has learned from an inter-domain routing procedure. The intra-domain routing procedure must supply reachability information for individual entities within the domain; network reachability is not sufficient. If entity reachability information is not available from intra-domain routing, the domain administrator must configure the domain to support the IDPR reachability protocol described in section 3.2 of [2]. Also, IDPR can offer quality of service routing across a domain only if the domain's intra-domain routing procedure itself provides quality of service routing. Must all Internet domains support IDPR? Currently, IDPR can construct a route between source and destination domains only if there is a contiguous set of domains that support IDPR, linking the source and destination domains. Not all Internet domains must support IDPR, but this means that IDPR routes are not currently available between all domains in the Internet. However, once it becomes available in gated, IDPR will be able to use routing information learned through other inter-domain routing procedures, in order to complete routes that must pass through domains that do not support IDPR. In this case, when a pure IDPR route is not available to a particular destination, IDPR will constuct a route until it reaches a domain that does not support IDPR but that can reach the destination through an alternate inter-domain routing procedure. Thus, host flows will reap the benefits of IDPR, at least within the contiguous IDPR domains at the head of IDPR routes. 4 Internet Draft IDPR Configuration July 1991 Does my stub domain need to support IDPR? Hosts in stub domains may have strict service requirements and hence will benefit from the policy sensitive routing provided by IDPR. However, the stub domain itself need not support IDPR in order for its host flows to use IDPR routes. Instead, a proxy domain may perform IDPR functions on behalf of the stub. The administrators of the stub and potential proxy domains must mutually agree on this relationship. Once an agreement is reached, the administrator of the stub domain must configure its hosts' source policies for the proxy domain. Furthermore, there must exist an independent inter-domain routing procedure for transporting traffic from the stub to the proxy. Can IDPR route between domains with different addressing and routing schemes? IDPR can construct routes and forward messages traversing domains that support different intra-domain routing and addressing schemes, thus providing interoperability between heterogenous transit domains. However, the addressing schemes for the source and destination domains must be the same. Interoperability between source and destination addressing schemes requires additional address translation software, which is currently beyond the scope of IDPR. How much effort will it take to install and operate IDPR in my domain? Once IDPR becomes available with gated, installation of IDPR within a domain whose entities can accommodate gated will only require assembling the IDPR configuration parameters according to a set of templates we supply in this document. However, even after IDPR becomes available in gated, a domain administrator may still decide to generate an independent implementation of IDPR, in order to take advantage of special hardware features in its gateways. Anyone intending to generate an independent IDPR implementation should consult both [1] and [2] for details. In either case, once a domain is properly configured, it should be able to support IDPR without further intervention by the domain administrator. If, after considering the above discussion, you have decided to configure your domain to support IDPR, please continue with the following section, describing how to set up the domain topology. If you intend to have a proxy domain provide IDPR functionality for your stub domain, please skip to section 4. 5 Internet Draft IDPR Configuration July 1991 3 Configuring Topology From the IDPR perspective, the Internet consists of a set of administrative domains connected by virtual gateways, which in turn are connected by intra-domain routes supporting the transit policies configured by the domain administrators. The domain administrator configures the set of transit policies that apply across its domain and the virtual gateways between which each transit policy applies. Existence of a virtual gateway between adjoining domains must be sanctioned by the administrators of both domains. 3.1 Virtual Gateways A virtual gateway (VG) is actually a collection of physical gateways residing in two adjoining domains and connected by point to point links or by networks. Each of these physical gateways is called a policy gateway (PG), because it forwards inter-domain transit traffic according to the policies configured by the domain administrator. A virtual gateway contains at least two policy gateways, one in each administrative domain. Policy gateways within a virtual gateway are called peer if they are in the same domain and adjacent if they are in different domains. A single policy gateway may be a member of multiple virtual gateways. Combining multiple policy gateways into a single virtual gateway reduces the amount of IDPR routing information that must be distributed and maintained throughout the Internet, increases the reliability of IDPR routes through redundancy of physical connections between administrative domains, and offers an opportunity for load sharing of IDPR traffic among the policy gateways. 3.1.1 The Adjoining Domain Before you configure a virtual gateway, you must contact the administrator of the adjacent domain. Each of you must agree on the number of virtual gateways that will connect the two domains and on which policy gateways will be part of which virtual gateways. We recommend configuring only a single virtual gateway between domains, for simplicity of management. However, you should configure multiple virtual gateways between the two domains, if you want to connect the domains in at least two distinct places and if either of the following is true. The connecting policy gateways in your domain or in the adjacent domain: 1.Are not proximate. For example, configure two virtual gateways if you want your domain to connect to the adjacent domain at both Boston and 6 Internet Draft IDPR Configuration July 1991 San Francisco. This will make management easier and may also promote the choice of more appropriate intra-domain routes between these and other virtual gateways attached to your domain. 2.Share no intra-domain routes that support all the anticipated transit policies for these connecting points. For example, suppose one policy gateway is attached to a transcontinental T3 intra-domain link that you would like IDPR to advertise as a high capacity service between virtual gateways. However, suppose because of domain topological constraints, the two policy gateways can only communicate over intra-domain routes with maximum capacity of 265kb. These two policy gateways should not reside in the same virtual gateway, since only one policy gateway supports the high capacity service. You, as an administrator of an IDPR domain, should configure at least one virtual gateway for each adjoining domain, regardless of whether that domain supports IDPR. This will provide your domain with the maximum control over inter-domain routing. If the adjoining domain does not support IDPR, you must indicate this in your configuration. Note that in this case, we do not expect the adjacent policy gateways to support the IDPR reachability protocol (see section 3.2 of [2]) that operates between policy gateways in a virtual gateway. Instead, IDPR considers an adjacent policy gateway in a domain that does not support IDPR, to be reachable by default. However, if you wish, you can modify the IDPR software to use a reachability protocol negotiated by you and the administrator of the adjacent domain, so that domain connectivity advertised by IDPR will accurately reflect the current state of the virtual gateway connecting the two domains. Direct Connections. When configuring a virtual gateway, you and the administrator of the adjacent domain must ensure that adjacent policy gateways are directly connected, that is, that the only Internet-addressable entities on the connecting medium are policy gateways in the virtual gateway. Thus, you are not restricted to point to point links between adjacent policy gateways; you may, for example, use an Ethernet to connect all of the policy gateways in a virtual gateway. However, to retain your control of inter-domain connectivity, you should not also connect to the Ethernet gateways that are not policy gateways. Identifiers. For each adjacent IDPR domain, you and the administrator of that domain must together select a unique local identifier for each virtual gateway in the set of virtual gateways connecting the two domains. If each 7 Internet Draft IDPR Configuration July 1991 domain administrator configures a different local identifier for the same virtual gateway, IDPR will not recognize the virtual gateway's existence.(1) For each virtual gateway attached to an adjacent domain that does not support IDPR, you may select the virtual gateway's local identifier yourself. Using the local identifier, IDPR constructs a virtual gateway identifier, unique within the domain. This virtual gateway identifier consists of the identifier of the adjacent domain together with the local identifier of the virtual gateway. At the Internet level, the virtual gateway is known uniquely by the identifiers of the two domains which it connects and the local identifier of the virtual gateway. 3.2 IDPR Entities within a Domain A domain that supports IDPR must contain the following IDPR entities: 1.Policy gateways: collect and distribute IDPR routing information, install IDPR paths across the Internet, forward host flows along the established paths, and maintain the local IDPR forwarding database. 2.Route servers: maintain both the IDPR routing information database and the IDPR route database and generate IDPR routes on behalf of clients in their domain. 3.Configuration servers: manage configured information for all IDPR entities within their domain and distribute configuration updates to these IDPR entities. An IDPR entity is local if it resides within your domain and remote if it resides elsewhere. Some entities may be collocated, that is, share the same address. For example, a policy gateway may also perform the route server functions. Identifiers. You must configure a unique local identifier for each IDPR entity in your domain. Collocated entities require only a single identifier. Using the local identifier, IDPR constructs an entity identifier, unique within the Internet. This entity identifier consists of the domain identifier together with the local identifier of the entity. ____________________________ (1)Unlike most other configuration errors, this one cannot be found by consistency checking during configuration parsing. 8 Internet Draft IDPR Configuration July 1991 Addresses. For each IDPR entity in your domain, you must configure an intra-domain address (or name, if entities in your domain have access to a domain name server) to associate with the entity identifier, so that the intra-domain routing procedure can transport IDPR traffic between IDPR entities. You must also configure the identifier of each policy gateway interface associated with a direct connection to an adjacent policy gateway, as well as the address of the directly-connected adjacent policy gateway. This ensures that the policy gateway will determine the reachability of the adjacent policy gateway via the direct connection and not via some other route. In addition, we recommend that you take the following steps, if your intra-domain routing procedure uses routing information from an inter-domain routing procedure: 1.When configuring a policy gateway's intra-domain address (or name), do not select any address (or name) that refers to any of its interfaces that directly connects to an adjacent policy gateway. 2.If possible, modify your intra-domain routing procedure to refrain from advertising the addresses of policy gateway interfaces associated with direct connections to adjacent policy gateways. These steps reduce the chances of IDPR traffic traversing ``intra-domain routes'' that actually leave and subsequently reenter the domain. 3.2.1 Route Servers You should configure at least two route servers in your domain. Route server redundancy increases fault tolerance and permits load sharing of IDPR route generation. If you wish, you may configure some of your local route servers to serve clients outside your domain as well. Route servers may be collocated with other IDPR entities or may be independent devices. We recommend that you do not collocate your route servers with your policy gateways if either of the following is true: 1.You expect that your route servers will be called upon to generate many routes frequently. 2.The number of IDPR domains in the Internet grows to several hundred. Route generation is computationally intensive, and when frequently performed by a policy gateway, can degrade the message forwarding ability of that policy gateway. Moreover, the amount of memory required to maintain both 9 Internet Draft IDPR Configuration July 1991 the routing information database and the route database can be significant when there are many IDPR domains supporting many transit policies. We also recommend that you configure a route server for each virtual gateway, if either 1. or 2. above is true. Policy gateways are the route servers' clients, and they act on behalf of hosts to establish IDPR routes across the Internet. By locating a route server close to its clients, you will reduce not only the delay incurred in installing your domain's IDPR routes but also the number of your domain's resources involved in IDPR route requests and responses. 3.2.2 Configuration Servers You must configure at least one configuration server for your domain. Each configuration server maintains a copy of the configuration information for each IDPR entity in the domain as well global configuration information that applies to all domains throughout the Internet. When initializing an IDPR entity, you must direct the configuration server to supply the entity with a set of IDPR configuration files; an entity cannot execute IDPR unless it has been properly configured. The configuration server uses SNMP to communicate configuration information to IDPR entities in your domain. Configuration servers usually have only moderate processing and memory requirements and thus may be collocated with other IDPR entities in your domain. If you configure multiple configuration servers, you need only place a copy of the domain's configuration files in one of them. That configuration server will automatically distribute a copy of the configuration files to all other configuration servers. 10 Internet Draft IDPR Configuration July 1991 4 IDPR Configuration Parameters and Files IDPR requires two types of configuration parameters: those you set that pertain to your domain only and those the Internet coordinator sets that pertain to the whole Internet. To help you configure your own domain, we provide a set of configuration files that you may use as templates. The domain configuration files include: idpr.domain, idpr.policies, and idpr.system. You may break down your domain configuration files into sub-files, dependent on type and scope of information, in order to make them more manageable. The global configuration files include: idpr.services, idpr.ad_sets, idpr.host_sets, and idpr.ads. However, in this document, we only provide a copy of the the file idpr.services; the other three global configuration files will be provided by the Internet coordinator. Configuration file syntax adheres to the following general directives: oComments begin with a # sign and continue until the end of the line. oConstant definitions may appear anywhere in a configuration file, provided that each constant is defined before it is used. Constant definitions take the form: name = number; oSub-files may be used with the directive: #include ; In the following sections, we describe all of the IDPR configuration parameters, and we show you how to assign appropriate values to these parameters. 11 Internet Draft IDPR Configuration July 1991 5 Entity Configuration Parameters Each IDPR entity in your domain has an associated set of configuration parameters that must be assigned values. For each entity configuration parameter, we provide a description of how set the value as well as an indication of whether the parameter is mandatory or discretionary. Also, we present a sample domain configuration file, idpr.domain, in section 5.1. Many of these configuration parameters are common to all IDPR entities within a domain. However, we recommend using a different sub-file for each different IDPR entity type, as different groups of configuration parameters apply to different entity types. This makes it clear which entities are affected by a change to a particular parameter and means that configuration files need only be changed for those entities. Domain Names. Discretionary. We recommend that you give names to your domain and the adjacent domains, and any other domains that you may list in your transit policy configuration, so that you can refer to them by name instead of by identifier throughout the configuration. You must specify each domain name as follows: ad_name ; where is a unique string of letters, digits, underscores, and hyphens (_ -), starting with a letter; is a number in the range 0 to 216 1. For example: ad_name bbn 5 ; ad_name dartnet 6 ; ad_name ant 7 ; ad_name widebandnet 8 ; However, you may use domain identifiers throughout the configuration if you prefer. This Domain. Mandatory. You must specify the identifier of this domain as, for example: this_ad bbn ; 12 Internet Draft IDPR Configuration July 1991 or this_ad 5 ; Entity Names. Discretionary. We also recommend that you give a name to each IDPR entity in your domain and to each adjacent policy gateway, so that you can refer to them by name instead of by identifier throughout the configuration. You must specify each entity name as follows: ent_name ; where is a unique string of letters, digits, underscores and hyphens (_ - ) starting with a letter; has the format .; has the format or ; local entity identifieris a number in the range 0 to 216 1. For example: ent_name dart5 bbn.1 ; ent_name dart6 bbn.3 ; ent_name dart1 dartnet.1 ; ent_name server_1 bbn.2 ; ent_name fred bbn.5 ; ent_name config bbn.4 ; However, you may use entity identifiers throughout the configuration if you prefer. Virtual Gateways. Mandatory. For each policy gateway in your domain, you must list all of the virtual gateways to which it belongs, as follows: vg_list ... ; where has the format or ; has the format .; applies to the adjacent domain; 13 Internet Draft IDPR Configuration July 1991 is a number in the range 0 to 255. For example, the following specification shows that dart5 is a member of virtual gateway 1 associated with domain dartnet and virtual gateway 0 associated with domain widebandnet: vg_list dart5 dartnet.1 widebandnet.0 ; Route Servers. Mandatory. You must configure the list of your local route servers as follows: rs_list ... ; For example, the following specification shows that server_1, fred, and dart6 are route servers in your domain: rs_list server_1 fred dart6 ; Configuration Servers. Mandatory. You must configure the list of your local configuration servers as follows: cs_list ... ; For example, the following specification shows that config is a configuration server in your domain: cs_list config ; Addresses. Mandatory. You must specify intra-domain addresses (or names) for all IDPR entities in your domain, as follows:
... ; where
specifies the type of address;
is either
or , whose format depends on
. Each address type has an associated keyword. For example, we use the keyword ip_address for IP addresses. Keywords for other address types will be defined by the Internet coordinator when necessary. You need only specify one address (or name) per entity but may specify more if you wish. 14 Internet Draft IDPR Configuration July 1991 For example, the following specification shows that dart5 has addresses 128.89.5.27 and 192.1.37.5, and dart6 has name dart6.bbn.com: ip_address dart5 128.89.5.27 192.1.37.5 ; ip_address dart6 dart6.bbn.com ; You should not list any intra-domain addresses or names that apply to interfaces associated with direct connections to adjacent policy gateways. Virtual Gateway Membership. Mandatory. For each virtual gateway attached to your domain, you must list the set of policy gateway members, including peer and adjacent policy gateways, as follows: vg_members ... ; where is a member of the set fIDPR; NOTIDPRg and indicates whether or not the adjacent domain supports IDPR. For example, the following specification shows that policy gateways dart5 and dart1 are members of virtual gateway 1 associated with domain dartnet which supports IDPR: vg_members dartnet.1 IDPR dart5 dart1 ; Note that virtual gateway members can be deduced from the information that you configure concerning the set of virtual gateways to which each policy gateway belongs. However, we have chosen to have you configure it this way as well for two reasons: 1.To allow you to maintain a list of the policy gateway members of each virtual gateway attached to your domain, as part of your configuration. 2.To assist IDPR in performing configuration consistency checks. You will receive notification of a configuration error, if the virtual gateway information you configure for vg_list and vg_members is inconsistent. This Entity. Mandatory. You must specify the identifier of this entity as, for example: this_ent dart5 ; or this_ent bbn.1 ; or even 15 Internet Draft IDPR Configuration July 1991 this_ent 5.1 ; You will receive notification of a configuration error, if this entity does not appear in any of the domain information you have already configured. Adjacent Policy Gateways. Mandatory. For each of this policy gateway's interfaces associated with a direct connection to an adjacent policy gateway, you must configure the interface as follows:
; out_interface ; where refers to the adjacent policy gateway;
refers to the address of the adjacent policy gateway; is the number of the interface of this policy gateway associated with the direct connection to the adjacent policy gateway. For example, the following specification shows that this policy gateway, dart5, is directly connected to an adjacent policy gateway, dart1, which is at address 128.89.17.13 and can be reached directly through interface 3: ip_address dart1 128.89.17.13 ; out_interface dart1 3 ; Recipient Route Servers. Mandatory. You must list the set of your local route servers to which this policy gateway should distribute IDPR routing information, as follows: rs_send ... ; For example, the following specification shows that dart5 should distribute IDPR routing information to the route server called server_1: rs_send server_1 ; This policy gateway also considers these the preferred route servers for responding to its route requests, and moreover, it queries route servers in the rs_send list order. Thus, you should configure the route server of highest preference first on the list. 16 Internet Draft IDPR Configuration July 1991 Advertised Route Servers. Discretionary. You may also configure a list of local route servers to serve clients outside of your domain. Policy gateways advertise this list, which you specify as follows: rs_advert ... ; For example, the following specification shows that route server fred is available to clients in other domains: rs_advert fred ; 17 Internet Draft IDPR Configuration July 1991 5.1 The File idpr.domain You may split your file idpr.domain into sub-files according to entity type, where each sub-file has the same scope. # ================= AD CONFIGURATION ================================== # All policy gateways and route servers in a single domain should have # identical domain configurations. #----- # Discretionary. # Give the symbolic names for all domains referenced in this configuration. ad_name bbn = 5 ; ad_name dartnet = 6 ; ad_name ant = 7 ; ad_name widebandnet = 8 ; #----- # Mandatory. # Specify the symbolic name or identifier for this domain. this_ad bbn ; #----- # Discretionary. # List the symbolic names and IDPR identifiers of all entities # referenced in this configuration. ent_name dart5 bbn.1 ; # policy gateway ent_name dart6 bbn.3 ; # policy gateway and route server ent_name dart1 dartnet.1 ; # adjacent policy gateway ent_name server_1 bbn.2 ; # route server ent_name fred bbn.5 ; # route server ent_name config bbn.4 ; # configuration server #----- # Mandatory. # For each policy gateway in this domain, list all the virtual gateways # it belongs to. vg_list dart5 dartnet.1 widebandnet.0 ; 18 Internet Draft IDPR Configuration July 1991 #----- # Mandatory. # List the addresses or names of all entities in this domain. ip_address dart5 128.89.5.27 192.1.37.5 ; ip_address dart6 dart6.bbn.com ; # ============= VG CONFIGURATION ======================================== # All policy gateways in a virtual gateway should have identical # virtual gateway configurations. If a policy gateway is a member # of more than one virtual gateway, then it should have the # configurations for each virtual gateway to which it belongs. #----- # Mandatory. # List all the member policy gateways in each virtual gateway. For # Be sure that all policy gateways in the virtual gateway agree on the # local identifier of that virtual gateway. vg_members dartnet.1 IDPR dart5 dart1 ; # ============ RS CONFIGURATION ====================================== # Mandatory. # List all route servers in the domain. rs_list server_1 fred dart6; # ============ ENTITY CONFIGURATION ================================== # Mandatory. # Description of this entity. If this entity does not appear in the # configuration other than here, then a warning will be printed. this_ent dart5 ; # ============ PG CONFIGURATION ====================================== # Complete this section only if the entity is a policy gateway. 19 Internet Draft IDPR Configuration July 1991 # Mandatory. # List address and outgoing interface for each directly connected # adjacent PG: ip_address dart1 128.89.17.13 ; out_interface dart1 3 ; # Mandatory. # List the route servers to which the policy gateway should distribute # IDPR routing information. This is also the list of preferred route # servers to respond to route requests, listed in preference order. rs_send server_1 ; # Discretionary. # List the route servers in this domain available to clients in other # domains. rs_advert fred ; 20 Internet Draft IDPR Configuration July 1991 6 Policy Configuration Parameters You must configure the source policies that specify the services requested by hosts or groups of hosts in your domain and the transit policies that specify the services offered by intra-domain routes across your domain. After configuring the source and transit policy information, you must install a copy in each policy gateway in your domain. We provide a sample policy configuration file, idpr.policies, in section 6.3.3. We will use the terms requested services and offered services in reference to source policies and transit policies respectively. Requested services apply to a particular set of host flows. Offered services apply to a particular domain. Both requested and offered services must be specified and handled in a uniform manner throughout the Internet, in order for IDPR entities in one domain to understand the policy requirements of another domain. Thus, a single body, the Internet coordinator, must be responsible for choosing the service syntax and semantics and the set of relevant parameters and their possible values and for distributing this configuration information to domain administrators. 6.1 Access Restrictions For each source policy and transit policy, you must configure the access restrictions that apply. In particular, for each of your source host flows, you must specify the set of domains that the flow favor or avoid; for your domain, you must specify the set of host flows (in terms of source and destination domains and hosts) that your domain will or will not transport. You should be aware that when you configure access restrictions in policy specifications, you may cause unanticipated connectivity problems, both for your host flows and for others' host flows. When alternate routes are not available, your restrictive source policies may prevent your host flows from obtaining routes to their destinations, while your restrictive transit policies may prevent other inter-domain host flows from obtaining routes to their destination. Thus, we recommend that you discuss your planned domain access restrictions with the Internet coordinator before configuring them. The Internet coordinator will be able to determine whether there will be potential connectivity problems for the flows whose access you plan to 21 Internet Draft IDPR Configuration July 1991 restrict.(2) 6.1.1 Domain Sets Domain sets are a shorthand method for writing source and transit policy specifications more compactly. When specifying access restrictions, you may list separately each domain to which the restrictions apply, or you may list a single identifier that refers to the set of domains to which the restrictions apply. A domain set is most useful for referring to a collection of domains that have characteristics in common, that are frequently referenced by other domains, and whose membership rarely changes. For example, all university domains may be grouped into a domain set. Also, there exists a special reserved value, ANY, that in the context of domains, refers to the set of all domains in the Internet. Domain set membership lists are suggested by domain administrators but are maintained and distributed by the Internet coordinator. The Internet coordinator supplies the domain sets in the configuration file idpr.ad_sets. Each domain set has the format: ad_set { , , ... }; where is a number in the range 0 to 216 1. The Internet coordinator distributes any new set and its accompanying membership list, when it becomes available, to each domain administrator. 6.1.2 Host Sets Each of your transit policy specifications must include the set of source and destination domains and hosts for which your domain will or will not carry transit traffic. We expect that most domain administrators will not find it necessary to configure transit policies that distinguish on the basis of hosts. However, should you decide to configure a transit policy that does distinguish between hosts, you must list these hosts in your ____________________________ (2)Researchers at the University of Southern California under the direction of D. Estrin are developing a tool that takes as input source policies, transit policies, and domain connectivity and determines the routes that may be generated as a result. 22 Internet Draft IDPR Configuration July 1991 transit policy specification. You must specify hosts by identifiers, each of which refers to a set containing one or more hosts. In the context of hosts, the special value ANY refers to the set of all hosts in the domain specified. Host set membership lists are suggested by domain administrators but are maintained and distributed by the Internet coordinator in the configuration file idpr.host_sets. Each host set has the format: host_set {
; ;
; ; ... }; where is a number in the range 0 to 255; is the type of mask associated with
; is the mask associated
. Using addresses and associated masks, you can, for example, account for all hosts on a given network in one source policy specification. The conventions for configuring the masks are that a bit set to 1 indicates that the corresponding address bit is significant and that a bit set to 0 indicates that the corresponding address bit is a ``don't care'' bit. 6.2 Source Policies For each host in your domain, you must decide which of its inter-domain flows should use IDPR. For each host flow you configure to use IDPR, you must configure the set, possibly empty, of source policies that apply. Thus, the source policy configuration serves two purposes: 1.It specifies the list of host flows in your domain that will use IDPR routes. 2.It specifies the list of source policies that apply to each such host flow. 23 Internet Draft IDPR Configuration July 1991 We provide a mechanism for simultaneously configuring the source policies of many host flows, provided that these host flows have the same set of requested services. When configuring your domain's list of source policies, you should order them such that the source policy applicable to the fewest number of host flows appears first. This convention allows you to treat a few host flows specially and then to handle all other host flows with a single source policy. Note that if you have agreed that your domain will act as proxy for a stub domain, you must obtain the stub domain's source policy specifications and incorporate them into your list of source policies. 6.2.1 Requested Services Below is a list of the requested services thus far defined for IDPR, including for each service, its description and whether it is mandatory or discretionary. We expect that as the number of IDPR users grows, so too will the number of services available. If you desire a service not contained on this list, contact the Internet coordinator to have it added. For the formal definitions of the requested services listed, you should refer to section 6.4. IDPR requested services include: path_life_minsDiscretionary. The maximum path lifetime. Specified as a single value between 0 and 1440, in minutes. Only one of the three path lifetime limits should be set at any one time. If you attempt to configure more than one path lifetime, you will receive notification of a configuration error. Although each of the path lifetime limits are discretionary parameters, IDPR requires a path lifetime; if none is specified the path lifetime defaults to 60 minutes. You can request a best effort attempt to keep a path alive forever by setting any one of the path lifetime limits to 0. path_life_msgsDiscretionary. The maximum path lifetime. Specified as a single value between 0 and 10000, in messages. path_life_bytesDiscretionary. The maximum path lifetime. Specified as a single value between 0 and 108, in bytes. authenticationDiscretionary. The requested data message authentication method. Specified as a single value: public key (MD5), private key (DES), 16-bit CRC, 24-bit CRC, or no authentication. Although data message authentication is a discretionary parameter, IDPR requires some 24 Internet Draft IDPR Configuration July 1991 form of data message authentication; if none is specified, the data message authentication defaults to no authentication. IDPR does not impose any constraints on authentication methods; the list of available methods can be expanded as necessary. Note that the configured authentication will only be computed in those domains that perform per data message authentication; not all transit domains may participate because of the associated processing cost. req_delayDiscretionary. The maximum acceptable average message delay assuming 1024 bytes per message. Specified as a single value in the range 0 - 20000, in milliseconds. IDPR will choose any path with a delay less than or equal to this. req_min_delayDiscretionary. As for req_delay. IDPR will try to choose the path with the minimum delay. req_delay_varDiscretionary. The maximum acceptable message delay variance, assuming 1024 bytes per message and message delay in milliseconds. Specified as a single value in the range 0 - 20000. IDPR will choose any path with a delay variance less than or equal to this. req_min_delay_varDiscretionary. As for req_delay_var. IDPR will try to choose the path with the minimum delay variance. req_bandwidthDiscretionary. The bandwidth required. Specified as a range of values in the range 0 - GIGABIT, in bits per second. The larger number is the maximum bandwidth expected. The smaller number is the minimum bandwidth required. IDPR will choose any path with bandwidth greater than or equal to the minimum value specified and if possible will try to satisfy the maximum as well. req_max_bandwidthDiscretionary. As for req_bandwidth. IDPR will try to choose the path with the highest bandwidth within the specified range. req_min_costDiscretionary. No value. IDPR will try to choose the path with the minimum cost with respect to the requested path lifetime. billing_addrDiscretionary. The billing address. Specified as a string. charge_numberDiscretionary. The charge number. Specified as a string. The qualities of service categories include delay, delay variance, bandwidth, and cost. If you attempt to configure more than one service within a single category, you will receive notification of a configuration error. However, you can configure services from more than one category. The order in which you configure these services determines the order in which IDPR will apply them when choosing your path. 25 Internet Draft IDPR Configuration July 1991 We recommend configuring req_bandwidth for those host flows that you expect will consume large amounts of bandwidth, even if those flows have no minimum bandwidth requirements. In this case, you should configure the lower number as 0 and the upper number according to the maximum burst expected. By explicitly configuring req_bandwidth for such flows, you help IDPR in managing Internet resources and you also improve the service provided to your host flows. 6.2.2 Source Policy Syntax The syntax for each source policy you configure is as follows: source_policy { sources {
; ;
; ; ... } ; destinations {
; ;
; ; ... } ; ad_list [ { [NOT] | ad_set () ; [NOT] | ad_set () ; ... } ] ; 26 Internet Draft IDPR Configuration July 1991 uci [ ] ; requested_services [ { ... } ] ; } ; You must specify all parts of a source policy description. Each parameter enclosed by [ ] will be assigned a default value by IDPR, as described below. To set the parameter to a different value, you must supply that value within the [ ] delimiters. Sources. Mandatory. You must configure your source host flows to which the source policy applies. Here, the format of and are dependent on
. The address and mask conventions described previously apply here as well. For example, the following specification shows that the source policy applies to traffic flows from the hosts on the class B network 128.89.0.0: sources { ip_address 128.89.0.0. ; ip_mask 255.255.0.0 ; } ; Destinations. Mandatory. You must configure the destination hosts associated with the source host flows to which the source policy applies. Here, the format of and are dependent on
. The address and mask conventions described previously apply here as well. For example, the first specification shows that the source policy applies to source host flows to a specific destination host 137.1.34.9: destinations { ip_address 137.1.34.9 ; ip_mask 255.255.255.255 ; } ; 27 Internet Draft IDPR Configuration July 1991 while the second specification shows that the source policy applies to source host flows to any destination host: destinations { ip_address 0.0.0.0 ; ip_mask 0.0.0.0 ; } ; Domain List. Mandatory. You must configure the list of domains that your host flows should favor or avoid when traversing the Internet. The domains listed may be individual domains or domain sets (see section 6.1.1). Moreover, you may precede any domain or domain set with the symbol NOT, which indicates that the source policy refers, with the , to all domains except the one specified. To specify whether or not the host flows should traverse the given domains, you must set the value of , where is one of the following: FAVOR: give preference to routes containing this domain or domain set. AVOID: avoid routes containing this domain or domain set, unless no other routes are available. EXCLUDE: do not select any routes containing this domain or domain set. For example, the first specification shows that the source host flows favor routes that include nsfnet but will never use routes that traverse dartnet: ad_list { nsfnet ( FAVOR ) ; dartnet ( EXCLUDE ) ; } ; while the second specification shows that the source host flows have no constraints on the transit domains that they can traverse: ad_list ; Note that for the first example, you must configure the domain names, nsfnet and dartnet, in the file idpr.domain. 28 Internet Draft IDPR Configuration July 1991 User Class. Mandatory. You must configure the user class for the host flows to which the source policy applies. The constant definitions for each user class are provided by the Internet coordinator in the file idpr.services (see section 6.4). To leave the user class unspecified, you omit the user class altogether. For example, the first specification shows that the user class associated with the host flows to which the source policy applies is the commercial class: uci ( commercial ) ; while the second specification shows that there is no specific user class associated with the source host flows: uci ; Requested Services. Mandatory. You must configure the service requested by the source policy. The syntax for these specifications is provided by the Internet coordinator in the file idpr.services (see section 6.4). To indicate that no special services are requested by the source policy, you omit the set of requested service specifications altogether. For example, the first specification shows that the source policy requests low delay service and a path lifetime of 2 hours: requested services { path_life_mins ( 120 ) ; req_min_delay ( 0 - 100 ) ; } ; while the second specification shows that the source policy requests no special services: requested services ; 6.3 Transit Policies For each pair of virtual gateways attached to your domain, you must configure the set, possibly empty, of transit policies that apply on the intra-domain routes between the virtual gateways. We provide a mechanism for simultaneously configuring the transit policies of many virtual gateway pairs, provided that the intra-domain routes between these pairs have the same set of offered services. 29 Internet Draft IDPR Configuration July 1991 6.3.1 Offered Services Below is a list of the offered services thus far defined for IDPR, including for each service, its description and whether it is mandatory or discretionary. We expect that as the number of IDPR users grows, so too will the number of services available. If you desire a service not contained on this list, contact the Internet coordinator to have it added. For the formal definitions of the offered services listed, you should refer to section 6.4. IDPR offered services include: delayDiscretionary. The average message delay across the domain, assuming a message size of 1024 bytes. Specified as a range (1-20000), in milliseconds. delay_varDiscretionary. The variance of message delay across the domain, assuming a message size of 1024 bytes and a message delay in milliseconds. Specified as a range (1-20000). bandwidthDiscretionary. The average bandwidth. Specified as a range (1 - GIGABIT), in bits/second. mtuDiscretionary. The maximum transfer unit (maximum message size within the domain). Specified as a single value between 0 and 65536, in bytes. charging_methodDiscretionary. The charging method. Specified as a single value: no charge, per message charging, per byte charging, or per second charging. tariffDiscretionary. The cost, depending on charging_method. Specified as a single value between 0 and 10000, in thousandths of a cent. 6.3.2 Transit Policy Syntax The syntax for each transit policy you configure is as follows: transit_policy {}; where is a number in the range 0 to 216 1 that uniquely identifies the transit policy within your domain, and has the following structure: time_spec [ ( - ) ] ; 30 Internet Draft IDPR Configuration July 1991 ad_group_list { ad_group { [NOT] | ad_set | ANY () ; [host_set_list { , , ... } ; ] [NOT] | ad_set | ANY () ; [host_set_list { , , ... } ; ] ... } ; ... } ; uci_list [ , , ... ] ; offered_services [ { ... } ] ; vg_group_list { vg_group { () ; () ; ... } ; ... } ; 31 Internet Draft IDPR Configuration July 1991 You must specify all parts of a transit policy description. Each parameter enclosed by [ ] will be assigned a default value by IDPR, as described below. To set the parameter to a different value, you must supply that value within the [ ] delimiters. Time. Mandatory. You must configure the range of time, within a 24 hour interval, when the transit policy applies. Both and must be specified in GMT as hours:minutes. To indicate that the transit policy applies all of the time, you omit the time range altogether. For example, the first specification shows that the transit policy is applicable overnight, between 5pm and 4am GMT: time_spec ( 17:00 - 19:30 ) ; while the second specification shows that the transit policy is always applicable: time_spec ; Domain Groups. Mandatory. You must configure the groups of domains from which and to which the transit policy applies. The domains in a group may be individual domains, domain sets (see section 6.1.1), or all domains indicated by the symbol ANY. Moreover, you may precede any domain or domain set with the symbol NOT, which indicates that the transit policy applies, with the set of , to all domains except the one specified. To specify whether the transit policy applies to a domain or domain set as source, destination, or both, you must set the value of , where is any non-empty subset of fSOURCE; DESTINATIONg. For example, the following definition shows that the transit policy applies to traffic flows between the nsfnet domain and the set of federal domains, to traffic flows from nsfnet to dartnet, but not to traffic flows between any members of the set of federal domains and dartnet: ad_group_list { ad_group { nsfnet ( SOURCE, DESTINATION ) ; ad_set federal ( SOURCE, DESTINATION ) ; } ; ad_group { 32 Internet Draft IDPR Configuration July 1991 nsfnet ( SOURCE ) ; dartnet ( DESTINATION ) ; } ; } ; Note that for this example, you must configure the domain names, nsfnet and dartnet, in the file idpr.domain and you must have received the domain set federal in the file idpr.ad_sets distributed by the Internet coordinator. Host Sets. Discretionary. We do not expect that most domain administrators will want to specify access restrictions to the level of hosts. To indicate that there are no host level access restrictions, you completely omit the host set specification. To configure host sets, you must use the host set identifiers contained in the file idpr.hostsets; providedbytheInternetcoordinatoranddescribedinsection 6:1:2: User Classes. Mandatory. You must configure the set of user classes for which the transit policy applies. The constant definitions for each user class are provided by the Internet coordinator in the file idpr.services (see section 6.4). To indicate that the transit policy applies to all user classes, you omit the set of user classes altogether. For example, the first specification shows that the transit policy applies to research traffic only: uci_list ( research ) ; while the second specification shows that the transit policy applies to all traffic: uci_list ; Offered Services. Mandatory. You must configure the qualities of service offered with the transit policy. The syntax for these specifications is provided by the Internet coordinator in the file idpr.services (see section 6.4). To indicate that no special qualities of service are offered with the transit policy, you omit the set of offered service specifications altogether. For example, the first specification shows that the transit policy offers high-bandwidth service for a fee: offered services { bandwidth ( 1000000 - 500000000 ) ; 33 Internet Draft IDPR Configuration July 1991 charging_method ( charge_per_byte ) ; tariff ( 5 ) ; } ; while the second specification shows that the transit policy offers no special qualities of service: offered services ; Virtual Gateway Groups. Mandatory. You must configure the groups of virtual gateways between which the transit policy applies. To specify whether the transit policy applies to a virtual gateway as domain entry point, domain exit point, or both, you must set the value of , where is any non-empty subset of fENTRY; EXITg. For example, the following specification shows that the transit policy applies to traffic flows between the virtual gateways associated with the widebandnet domain and the dartnet domain and to traffic flows from the virtual gateway associated with the widebandnet to the virtual gateway associated with nsfnet: vg_group_list { vg_group { widebandnet.0 ( ENTRY, EXIT ) ; dartnet.1 ( ENTRY, EXIT ) ; } ; vg_group { widebandnet.0 ( ENTRY ) ; nsfnet ( EXIT ) ; } ; } ; Note that for this example, you must configure the domain names, widebandnet, dartnet, and nsfnet, in the file idpr.domain. 34 Internet Draft IDPR Configuration July 1991 6.3.3 The File idpr.policies You may split your file idpr.policies into sub-files according to policy type. # ============== POLICY CONFIGURATION ================================ # SOURCE AND TRANSIT POLICY CONFIGURATION # All policy gateways and route servers in a single domain should have # identical policy configurations. # ============== SOURCE POLICIES ===================================== # Mandatory # Configure all source policies # Replicate the structure below as many times as necessary to configure # all the requested services for all of the hosts which may use this policy # gateway to set up paths. We recommend that all policy gateways in # a given AD have the same source policy configuration. # # sources and destination together specify the scope of this source policy. # addresses are normal host or network ip address. mask bits are set # to 1 when the corresponding bit in the address is significant, and are 0 # otherwise. So for example, to specify that all hosts on class B network # 128.89.0.0 are affected, you should set the address to 128.89.0.0 and the # mask to 255.255.0.0. # # You should order your source policies so that the policy with the most # restrictive scope appears first. This will allow you to special-case # a few hosts or networks, and then handle all others with a single policy. # general syntax: source_policy { sources {
; ;
; 35 Internet Draft IDPR Configuration July 1991 ; ... } ; destinations {
; ;
; ; ... } ; ad_list [ { [NOT] | ad_set | ANY () ; [NOT] | ad_set | ANY () ; ... } ] ; uci [ ] ; requested_services [ { ... } ] ; } ; # example: source_policy { sources { ip_address 128.89.3.5 ; ip_mask 255.255.255.255 ; 36 Internet Draft IDPR Configuration July 1991 } ; destinations { ip_address 137.1.34.9 ; ip_mask 255.255.255.255 ; } ; ad_list { dartnet ( EXCLUDE ) ; } ; uci ( commercial ) ; requested_services { path_life_mins ( 120 ) ; req_min_delay ( 0 - 100 ) ; } ; } ; source_policy { sources { ip_address 128.89.0.0 ; ip_mask 255.255.0.0; } ; destinations { ip_address 255.255.255.255 ; ip_mask 0.0.0.0 ; } ; ad_list ; uci ; requested_services ; } ; 37 Internet Draft IDPR Configuration July 1991 # ============== TRANSIT POLICIES ==================================== # Mandatory # Configure all IDPR transit policies # # The structure: # # transit_policy { } ; # # is repeated as many times as necessary to specify all the independent # transit policies. The field should be different for # each policy. # # The transit is as follows: # # time_spec (hh:mm - hh:mm ); # OR time_spec ; # # time_spec specifies the time, within a 24 hour interval, # when the policy is valid. Times are specified in GMT in # hours:minutes, with the starting time specified first, and # the ending time last. If the range is omitted altogether # then there is no time limit. # # ad_group_list { } ; # specifies the AD groups for which the policy is valid. # ADs within a group are mutually reachable using the policy; # ADs in different groups are not. For example, using more # than one group allows you to specify in a single policy # term, that AD X can send traffic to any other AD (SOURCE X, # DEST ANY) and receive traffic from any other AD (SOURCE ANY, # DEST X). # # ad_group { [ [NOT] (SOURCE, DEST) ; ] } ; # OR ad_group { [ ANY (SOURCE, DEST) ; ] } ; # OR ad_group { [ [NOT] ad_set (SOURCE, DEST) ; ] } ; # # specifies a list of domains or sets of domains within the group, # and their associated flags. # # NOT - indicates that the transit policy with the flags # listed applies to any domain or set of domains 38 Internet Draft IDPR Configuration July 1991 # EXCEPT those specified. You should not use # this flag when you specify the wildcard ANY. # ANY - a wildcard, meaning any domain. # # The flags are as follows: # SOURCE - indicates that this policy applies to the specified # domains when they are the source of the traffic. # DEST - indicates that this policy applies to the specified # domains when they are the destination of the traffic. # # uci_list [uci] ; # specifies the list of applicable user classes. # # offered_service { offered_service_spec [offered_service_spec] }; # # vg_group_list { } ; # specifies the group of virtual gateways betwee which the policy # applies. virtual gateways within a group are mutually reachable # via intra-domain routes of this policy. # # vg_group { [ (ENTRY, EXIT); ] }; # specifies the list of virtual gaterways which belong to a # single group. For each virtual gateway, its identifier is # specified, and then one or both of the following flags: # # ENTRY - indicates that traffic using this policy can enter # this domain through the indicated VG. # EXIT - indicates that traffic using this policy can leave # this domain through the indicated VG. # # general syntax: transit_policy { time_spec [ ( - ) ] ; ad_group_list { ad_group { [NOT] 39 Internet Draft IDPR Configuration July 1991 | ad_set | ANY () ; [host_set_list { , , ... } ; ] [NOT] | ad_set | ANY () ; [host_set_list { , , ... } ; ] ... } ; ... } ; uci_list [ , , ... ] ; offered_services [ { ... } ] ; vg_group_list { vg_group { () ; () ; ... } ; ... } ; } ; # example: transit_policy 7 40 Internet Draft IDPR Configuration July 1991 { time_spec ; ad_group_list { ad_group { nsfnet ( SOURCE, DESTINATION ) ; ad_set federal ( SOURCE, DESTINATION ) ; } ; ad_group { nsfnet ( SOURCE ) ; dartnet ( DESTINATION ) ; } ; } ; uci_list ( research ) ; offered services { bandwidth ( 1000000 - 500000000 ) ; } ; vg_group_list { vg_group { widebandnet.0 ( ENTRY, EXIT ) ; dartnet.1 ( ENTRY, EXIT ) ; } ; vg_group { widebandnet.0 ( ENTRY ) ; nsfnet ( EXIT ) ; } ; } ; } ; 41 Internet Draft IDPR Configuration July 1991 6.4 Service Definitions The IDPR requested and offered service definitions are under the jurisdiction of the Internet coordinator who defines the syntax and the semantics and distributes them in the configuration file idpr.services. The service definitions contained in idpr.services describe the syntax of the service specifications and the allowable ranges of parameter values. Included comments describe the semantics. Your service specifications must conform to the syntax described in these definitions. In section 6.4.1, we provide a copy of the file idpr.services. Changes to idpr.services will usually require changes to the software in each IDPR implementation. Thus, we expect new versions of idpr.services to be introduced only after extensive discussion and review by the user community. We also expect distribution of new versions of the file to occur infrequently and to be available well before the domains must support the new services. We now describe the syntax and semantics of the IDPR service definitions. The syntax for offered services and for requested services is identical. Requested and offered services are introduced by the keywords DEF_REQUEST and DEF_OFFERED respectively. char_spec : DEF_OFFERED char_id SINGLE range ; | DEF_OFFERED char_id RANGE range ; | DEF_OFFERED char_id SINGLE set ; | DEF_OFFERED char_id SET set ; | DEF_OFFERED char_id string ; | DEF_OFFERED char_id ; ; range : '(' number '-' number ')' ; set : '(' number ',' number {',' number} ')' ; single : '(' number ')' ; The type number is a sequence of digits, and the type string is a sequence of letters or digits enclosed in double quotes. A double quote inside a string is escaped by doubling it (""). The types range, set, and single have the syntax described above. 42 Internet Draft IDPR Configuration July 1991 The keyword SINGLE means that the parameter takes a single value within the limits of the range or set. The keyword RANGE means that the parameter takes a range value, covering the range of values listed. The keyword SET means that the parameter takes a set value, with members of the set forming a subset of the one listed. A set with one member is indistinguishable from a single value. For example, given the service definitions: DEF_REQUEST counter SET (1000, 2000, 3000); DEF_REQUEST threshold SINGLE (1 - 10); DEF_REQUEST limits RANGE (1 - 20); the following service specifications are valid: counter (1000, 3000); counter (3000); threshold (7); limits (2 - 9); limits (3 - 3); Service definitions also contains constant definitions, which may be used in place of numbers. A constant definition has the form: name = number; For example, with the following offered service definitions: no_charge = 0 ; charge_per_msg = 1 ; charge_per_byte = 2 ; charge_per_sec = 3 ; DEF_OFFERED charging_method SINGLE (charge_per_pkt, charge_per_byte, charge_per_sec, no_charge) ; a valid offered service specification has the form: charging_method ( charge_per_byte ) ; 43 Internet Draft IDPR Configuration July 1991 6.4.1 The File idpr.services # Definitions of Requested and Offered Services # This file should only be changed by the Internet coordinator # after consultation with domain administrators and IDPR software # developers. # The file contains definitions for requested and offered service # specifications. The definitions specify the syntax of the requested # or offered services, and also describe (with the comments) the # semantics and the allowable parameter values. # The syntax of offered service specifications is defined using the # syntax shown below. The syntax of requested service specifications # is identical, except for the use of the keyword DEF_REQUEST instead # of DEF_OFFERED. # # serv_def : DEF_OFFERED char_id SINGLE range ; # | DEF_OFFERED char_id RANGE range ; # | DEF_OFFERED char_id SINGLE set ; # | DEF_OFFERED char_id SET set ; # | DEF_OFFERED char_id string ; # | DEF_OFFERED char_id ; # ; # # range : '(' number '-' number ')' # ; # # set : '(' number ',' number {',' number} ')' # ; # # single : '(' number ')' # ; # # A "number" is a sequence of digits, and a "string" is a sequence of letters # or digits enclosed in double quotes. A double quote inside the string # is escaped by doubling it (""). # The keyword SINGLE means that the value should be expressed as a single # value within the limits of the range or set. The keyword RANGE means that # a range of values should be specified, where both ends of the range are # within the limits given. The keyword SET means that a set of values should 44 Internet Draft IDPR Configuration July 1991 # be specified, where the members of the set form a subset of the one given. # # For example, given the definition: # DEF_REQUEST counter SET (one, two, three); # the following specification would be valid: # counter (one, three); # -------------------------------------------------------------------------- # General Definitions no_charge = 0 ; charge_per_msg = 1 ; charge_per_byt = 2 ; charge_per_sec = 3 ; GIGABIT = 1000000000 ; # 1000 megabits per second auth_none = 0 ; # more of these will be specified. auth_public_key = 1 ; # MD5 algorithm auth_private_key = 2 ; # DES algorithm auth_16bit_crc = 3 ; auth_24bit_crc = 4 ; # -------------------------------------------------------------------------- # UCIs research = 1 ; # research federal = 2 ; # federal commercial = 3 ; # commercial support = 4 ; # support # -------------------------------------------------------------------------- # Quality and Cost of Service Offered Services delay = 1 ; delay_var = 2 ; bandwidth = 3 ; mtu = 4 ; charging_method = 5 ; tariff = 6 ; # Discretionary. 45 Internet Draft IDPR Configuration July 1991 DEF_OFFERED delay RANGE ( 0 - 20000 ) ; # average message delay, assuming a message size of # 1024 bytes. should be specified as a # range. numbers expressed in milliseconds. DEF_OFFERED delay_var RANGE ( 0 - 20000 ) ; # message delay variance, assuming a message size of # 1024 bytes and message delay in milliseconds. # should be specified as a range. DEF_OFFERED bandwidth RANGE ( 0 - GIGABIT ) ; # average bandwidth. should be specified as a # range. numbers expressed in bits/second. DEF_OFFERED mtu SINGLE ( 0 - 65536 ) ; # maximum transfer unit. should be specified as a # single value, between the limits shown. numbers # expressed in bytes. DEF_OFFERED charging_method SINGLE (charge_per_pkt, charge_per_byte, charge_per_sec, no_charge ); # describes how charging is done. should be # specified as a single value which is a member # of the above set. DEF_OFFERED tariff SINGLE ( 0 - 10000 ) ; # cost for service as defined by charging_method. # should be specified in thousandths of a cent. # -------------------------------------------------------------------------- # Requested Services # The maximum requested service number is 255. # IDPR assigns default values to the following services if none are # configured: # path_life_mins # authentication path_life_mins = 1 ; path_life_msgs = 2 ; path_life_bytes = 3 ; 46 Internet Draft IDPR Configuration July 1991 data_version = 4 ; # used internally by IDPR only. authentication = 5 ; req_delay = 6 ; req_min_delay = 7 ; req_delay_var = 8 ; req_min_delay_var = 9 ; req_bandwidth = 10 ; req_max_bandwidth = 11 ; req_min_cost = 12 ; billing_addr = 13 ; charge_number = 14 ; # Discretionary. # Only one of the path lifetime services may be configured at a time. # If none are configured, then the system will default to setting path # lifetime to 60 minutes. An administrator can request a best effort # attempt to keep the path open forever by setting one of the path lifetime # services to zero. DEF_REQUEST path_life_mins SINGLE ( 0 - 1440 ) ; # maximum path lifetime in minutes. should # be specified as a single value within the # range. DEF_REQUEST path_life_msgs SINGLE ( 0 - 10000 ) ; # maximum path lifetime in messages. should # be specified as a single value within the # range. DEF_REQUEST path_life_bytes SINGLE ( 0 - 100000000 ) ; # maximum path lifetime in bytes. should be # specified as a single value within the # range. # Discretionary. # More authentication types may be added in the future. If none is specified, # the authentication defaults to no authentication. DEF_REQUEST authentication SET ( auth_public_key, auth_private_key, auth_16bit_crc, auth_24bit_crc, auth_none ); 47 Internet Draft IDPR Configuration July 1991 # Discretionary. # the next group of "req_xxx" services are related. The administrator # does not have to specify any of these. If none are specified then a # path will be chosen with no regard for these parameters. Only one of # "req_xxx" and "req_min_xxx" or "req_max_xxx" should be chosen. DEF_REQUEST req_delay SINGLE ( 0 - 20000 ) ; # specifies the largest acceptable average # message delay in milliseconds, assuming # 1024 bytes per message. IDPR will # choose any path with a delay less than # or equal to this. DEF_REQUEST req_min_delay SINGLE ( 0 - 20000 ) ; # as for req_delay. IDPR will try to choose # the path with the minimum delay. DEF_REQUEST req_delay_var SINGLE ( 0 - 20000 ) ; # specifies the largest acceptable message # delay variance, assuming 1024 bytes per # message and message delay in milliseconds. # IDPR will choose any path with a delay # variance less than or equal to this. DEF_REQUEST req_min_delay_var SINGLE ( 0 - 20000 ) ; # as for req_delay_var. IDPR will try to # choose the path with the minimum delay # variance. DEF_REQUEST req_bandwidth RANGE ( 0 - GIGABIT ) ; # specifies the bandwidth requirements, in # bits per second. The larger number is the # best estimate of bandwidth requirements. # The smaller number is the lowest bandwidth # acceptable. IDPR will choose any value for # bandwidth which is consistent with this. # specifying 0 at the low end of the range # indicates that the flow will take what it # can get. DEF_REQUEST req_max_bandwidth RANGE ( 0 - GIGABIT ) ; 48 Internet Draft IDPR Configuration July 1991 # as for req_bandwidth. IDPR will try to # choose the path with the highest bandwidth # within the specified range. DEF_REQUEST req_min_cost ; # IDPR will try to choose the minimum cost # path with respect to the requested path # lifetime DEF_REQUEST billing_addr STRING ; DEF_REQUEST charge_number STRING ; 49 Internet Draft IDPR Configuration July 1991 7 System Configuration Parameters In this section, we describe address to destination domain resolution as well as a set of parameters related to the IDPR protocols themselves. 7.1 Destination Domain Resolution To locate an IDPR route for a host flow, IDPR must determine the destination domain based on the destination host address contained in the host messages. Domain Name Server. We recommend using the domain name server, whenever possible, to perform the destination host address to destination domain mapping. The domain name server will be modified in order to provide this function. In particular, a new record, the domain identifier, must be provided for every host, in a manner which permits reverse translation of address to domain identifier. Moreover, for each stub domain using a proxy, the proxy domain be listed, in addition to the host's actual domain. Domain File. If domain name server functionality is not available, IDPR must resort to looking up the destination domain identifier in a configuration file, idpr.ads, provided by the Internet coordinator. The file idpr.ads contains a list of addresses and their corresponding domain identifiers. The addresses are specified with ``don't care'' masks so that only a single entry is necessary for all the hosts on a particular network or subnetwork. Each entry of the file idpr.ads has the format:
The mask conventions described previously apply here as well. We expect the use of an idpr.ads file to be an interim measure only, either for testing or for running IDPR among a small set of domains. 7.2 IDPR Protocol Parameters We provide default values for parameters associated with the IDPR protocols, that must be configured in all IDPR entities in your domain. You should not change these parameter values unless you understand how the IDPR protocols operate. 50 Internet Draft IDPR Configuration July 1991 7.2.1 The File idpr.system # ============ SYSTEM CONFIGURATION ====================================== # This section contains system parameters. We recommend setting all # parameters identically in all entities, although if you need more # control over each entity you need not do this. cmtp_new_sec = 300; # maximum acceptable age discrepancy # in messages that appear too new, # in seconds. vgp_ret = 10; # maximum transmissions of VGP messages. vgp_int_usec = 1000000; # retransmission interval for VGP # messages, in microseconds. vgp_old_sec = 300; # maximum acceptable age of VGP messages, # in seconds. vgp_per_sec = 5; # interval between reachability messages. vgp_reachability = FALSE; # do not run the IDPR reachability protocol # between entities in your domain. ridp_ret = 10; # maximum transmissions for routing # information messages. ridp_int_usec = 1000000; # retransmission interval for routing # information mesages, in microseconds. ridp_send_sec = 200; # maximum interval between when a routing # information message is generated and when # it will be transmitted, in seconds. ridp_con_old_hr = 700; # maximum age of configuration messages, # in hours. ridp_con_per_sec = 0; # interval between periodic configuration # messages in seconds. set to 0 for no # periodic configuration messages. ridp_dyn_old_hr = 170; # maximum age of dynamic messages, in # hours. ridp_dyn_per_sec = 0; # interval between periodic dynamic # messages in seconds. set to 0 for no # periodic dynamic messages. ridp_req_ret = 2; # maximum transmissions for routing # information request messages. ridp_req_int_usec = 2000000; # retransmission interval for routing # information request messages, in 51 Internet Draft IDPR Configuration July 1991 # microseconds. ridp_req_old_sec = 300; # maximum acceptable age of routing # information request messages, in seconds. route_req_ret = 2; # max transmissions for route request # messages. route_req_int_usec = 2000000; # retransmission interval for route # request messages, in microseconds. route_req_old_sec = 300; # maximum acceptable age of route # request messages, in seconds. psp_ret = 5; # maximum transmissions of path setup # protocol messages. psp_int_usec = 1000000; # retransmission interval for path setup # protocol messages, in microseconds. psp_old_sec = 300; # maximum acceptable age of path setup # protocol messages, in seconds. psp_setup_ret = 2; # max transmissions of setup messages. psp_setup_int_usec = 2000000; # retransmission interval for setup # messages, in microseconds. IDPR = TRUE; # used in idpr.domain. indicates that the # adjacent domain supports IDPR. NOTIDPR = FALSE; # used in idpr.domain. indicates that the # adjacent domain does not support IDPR. 52 Internet Draft IDPR Configuration July 1991 References [1]M. Lepp and M. Steenstrup. An architecture for inter-domain policy routing. Internet Draft. July 1991. [2]M. Steenstrup. Inter-domain policy routing protocols: version 1. Internet Draft. July 1991. [3]R. Woodburn. Definitions of managed objects for inter-domain policy routing (version 1). Internet Draft. July 1991. 53