Martha Steenstrup <msteenst@bbn.com> Thu, 14 October 1993 21:02 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14063; 14 Oct 93 17:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14059; 14 Oct 93 17:02 EDT
Received: from PIZZA.BBN.COM by CNRI.Reston.VA.US id aa01998; 14 Oct 93 17:02 EDT
Received: from pizza by PIZZA.BBN.COM id aa12023; 14 Oct 93 16:53 EDT
Received: from KARIBA.BBN.COM by PIZZA.BBN.COM id aa12019; 14 Oct 93 16:50 EDT
To: murayama@theta.iis.u-tokyo.ac.jp
cc: idpr-wg@bbn.com, preference@alan.cs.uec.ac.jp, policy-routing@wide.ad.jp
Date: Thu, 14 Oct 1993 16:51:49 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Martha Steenstrup <msteenst@bbn.com>
Message-ID: <9310141702.aa01998@CNRI.Reston.VA.US>

Hello Yuko,

The answer to your question depends on the interpretation of the word
"monitor".  Woody has provided an answer in the case where "monitor"
is interpreted in the context of network management via SNMP.  Danny's
has provided an answer, in his last paragraph, in the case where
"monitor" is interpreted in the context of obtaining IDPR routing
information.

I will add just a little more detail about IDPR functionality.  With
IDPR, policy gateways distribute routing information, about their
domains and in the style of link states, to other domains in an
internetwork.  (At any one time, there is a single policy gateway
within a domain who is responsible for generating and distributing
routing information about that domain.)  The principal routing
information distribution method is via flooding of link states.

IDPR routing information for a given domain consists of the following
information (although not represented in exactly this form):

- The virtual gateways connecting the given domain to adjacent domains
and whether the virtual gateway is "up" or "down".  Each virtual
gateway contains at least one policy gateway in each of the two
domains, and may contain more for load-balancing or fault-tolerance
reasons.

- The transit policies associated with each pair of virtual gateways
attached to the given domain.  Transit policies describe offered
services and restrictions on their use and include:
  - qualities of service, such as delay,
  - monetary cost of service, such as charge per use time,
  - access restrictions on obtaining service, such as when the service
    is available and which traffic may use the service.

IDPR routing information is at the level of domains, virtual gateways,
and the properties of the "virtual links" (i.e. sets of intra-domain
routes) between virtual gateways.  It is not at the level of policy
gateways (i.e. physical gateways) and the physical links connecting
them.  Entities in one domain can learn this domain-level routing
information about other internetwork domains, through distributed
routing information from those domains.

In your example, suppose W1/S1, W2/S2, W3/X, and W4/Y are the four
virtual gateways attached to domain W.  Routing information about W
would include a mention of these virtual gateways together with the
characteristics of the set of intra-domain routes that connect each
pair of these virtual gateways.  So, for example, a policy gateway in
S or in any other internetwork domain could learn of the "costs" of
intra-domain routes between virtual gateways W2/S2 and W3/X, through
routing information messages distributed by domain W.  These "costs"
would be expressed in terms of transit policies associated with the
"virtual links" (i.e. sets of intra-domain routes) between those two
virtual gateways.

m
  •   Martha Steenstrup