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 <filename> ;
  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   <ad name>  <ad identifier> ;
where

<ad name>is a unique string of letters, digits, underscores, and hyphens (_
   -), starting with a letter;
<ad identifier>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   <entity name> <entity identifier> ;
where

<entity name>is a unique string of letters, digits, underscores and hyphens
   (_ - ) starting with a letter;
<entity identifier>has the format <ad>.<local entity identifier>;
<ad>has the format <ad name> or <ad identifier>;
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   <entity> <vg identifier> <vg identifier> ... ;
where

<entity>has the format <entity name> or <entity identifier>;
<vg identifier>has the format <ad>.<local vg identifier>;
<ad>applies to the adjacent domain;

                                  13




Internet Draft            IDPR Configuration                   July 1991

<local vg identifier>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   <entity> <entity> ... ;
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   <entity> <entity> ... ;
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:
       <address type> <entity> <address/name> <address/name> ... ;
where

<address type>specifies the type of address;
<address/name>is either <address> or <name>, whose format depends on
   <address type>.

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   <vg identifier> <adjacent> <entity> <entity> ... ;
where <adjacent> 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:
       <address type> <entity>  <address> ;
       out_interface  <entity>  <interface id> ;
where

<entity>refers to the adjacent policy gateway;
<address>refers to the address of the adjacent policy gateway;
<interface id>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  <entity> <entity> ... ;
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  <entity> <entity> ... ;
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        <ad set identifier>
       {
          <ad identifier>, <ad identifier>, ...
       };
where <ad set identifier> 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 <host set identifier>
       {
          <address type>    <address> ;
          <mask type>       <mask>;
          <address type>    <address> ;
          <mask type>       <mask>;
                     ...
       };
where

<host set identifier>is a number in the range 0 to 255;
<mask type>is the type of mask associated with <address type>;
<mask>is the mask associated <address>.

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
              {
                 <address type>   <source address> ;
                 <mask type>      <source mask> ;
                 <address type>   <source address> ;
                 <mask type>      <source mask> ;
                             ...
              } ;

              destinations
              {
                 <address type>   <destination address> ;
                 <mask type>      <destination mask> ;
                 <address type>   <destination address> ;
                 <mask type>      <destination mask> ;
                             ...
              } ;

              ad_list [
              {
                 [NOT]
                  <ad identifier> | ad_set <ad set identifier>
                      (<ad flag>) ;
                 [NOT]
                  <ad identifier> | ad_set <ad set identifier>
                      (<ad flag>) ;
                             ...
              } ] ;

                                  26




Internet Draft            IDPR Configuration                   July 1991


              uci [ <uci> ] ;

              requested_services [
              {
                 <requested service specification>
                 <requested service specification>
                             ...
              } ] ;
       } ;
  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 <source address> and <source
mask> are dependent on <address type>.  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 <destination address> and <destination mask> are
dependent on <address type>.  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 <ad flag>, 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 <ad flag>,
where <ad flag> 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  <policy identifier>  {<policy description>};
where <policy identifier> is a number in the range 0 to 216 1 that
uniquely identifies the transit policy within your domain, and <policy
description> has the following structure:
       time_spec [ (<start time> - <end time>) ] ;


                                  30




Internet Draft            IDPR Configuration                   July 1991

       ad_group_list
       {
           ad_group
           {
              [NOT]
               <ad identifier> | ad_set <ad set identifier> | ANY
                   (<ad flags>) ;
               [host_set_list
                    {
                       <host set identifier>, <host set identifier>, ...
                    } ; ]
              [NOT]
               <ad identifier> | ad_set <ad set identifier> | ANY
                   (<ad flags>) ;
               [host_set_list
                    {
                       <host set identifier>, <host set identifier>, ...
                    } ; ]
                      ...
           } ;
              ...
       } ;

       uci_list [ <uci>, <uci>, ... ] ;

       offered_services [
       {
           <offered service specification>
           <offered service specification>
              ...
       } ] ;

       vg_group_list
       {
           vg_group
           {
              <vg identifier> (<vg flags>) ;
              <vg identifier> (<vg flags>) ;
                      ...
           } ;
              ...
       } ;

                                  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 <start time> and <end time>
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 <ad flags>, 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 <ad flags>, where
<ad flags> 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 <vg flags>,
where <vg flags> 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
     {
         <address type>   <source address> ;
         <mask type>      <source mask> ;
         <address type>   <source address> ;


                                  35




Internet Draft            IDPR Configuration                   July 1991

         <mask type>      <source mask> ;
                     ...
      } ;

      destinations
      {
         <address type>   <destination address> ;
         <mask type>      <destination mask> ;
         <address type>   <destination address> ;
         <mask type>      <destination mask> ;
                     ...
      } ;

      ad_list [
      {
         [NOT]
          <ad identifier> | ad_set <ad set identifier> | ANY
             (<ad flag>) ;
         [NOT]
          <ad identifier> | ad_set <ad set identifier> | ANY
             (<ad flag>) ;
                     ...
      } ] ;

      uci [ <uci> ] ;

      requested_services [
      {
         <requested service specification>
         <requested service specification>
                     ...
       } ] ;
} ;

# 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   <policy number>   { <policy description> } ;
#
# is repeated as many times as necessary to specify all the independent
# transit policies.  The field <policy number> should be different for
# each policy.
#
# The transit <policy description> 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] <ad identifier>           (SOURCE, DEST) ; ] } ;
#    OR ad_group { [       ANY                      (SOURCE, DEST) ; ] } ;
#    OR ad_group { [ [NOT] ad_set <ad set identifier> (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 { [<vg identifier> (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 <policy identifier>
       {
          time_spec [ (<start time> - <end time>) ] ;

          ad_group_list
          {
             ad_group
             {
                 [NOT]

                                  39




Internet Draft            IDPR Configuration                   July 1991

                  <ad identifier> | ad_set <ad set identifier> | ANY
                      (<ad flags>) ;
                  [host_set_list
                       {
                         <host set identifier>, <host set identifier>, ...
                       } ; ]
                 [NOT]
                  <ad identifier> | ad_set <ad set identifier> | ANY
                      (<ad flags>) ;
                  [host_set_list
                       {
                         <host set identifier>, <host set identifier>, ...
                       } ; ]
                           ...
             } ;
                     ...
          } ;

          uci_list [ <uci>, <uci>, ... ] ;

          offered_services [
          {
             <offered service specification>
             <offered service specification>
                     ...
          } ] ;

          vg_group_list
          {
             vg_group
             {
                 <vg identifier> (<vg flags>) ;
                 <vg identifier> (<vg flags>) ;
                           ...
             } ;
                     ...
          } ;
       } ;

# 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:
<address type>  <address> <mask> <ad identifier>
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