32] RFC 1479 IDPR Protocol July 1993 connection only if both of the following conditions are true: - The policy gateway receives from the adjacent policy gateway at least j acceptable UP/DOWN messages within the last m consecutive periods. From the recipient policy gateway's perspective, this event up. Hence, the recipient policy gateway indicates the up state in its subsequent UP/DOWN messages. - The UP/DOWN message most recently received from the adjacent policy gateway indicates the up state, signifying that the adjacent policy gateway considers the direct connection to be up. A policy gateway must cease to transport data traffic over a direct connection whenever either of the following conditions is true: - The policy gateway receives from the adjacent policy gateway at most acceptable UP/DOWN messages within the last n consecutive periods. - The UP/DOWN message most recently received from the adjacent policy gateway indicates the down state, signifying that the adjacent policy gateway considers the direct connection to be down. From the recipient policy gateway's perspective, either of these events constitutes a state transition of the direct connection from up to down. Hence, the policy gateway indicates the down state in its subsequent UP/DOWN messages. 3.3. Implementation We recommend implementing the up/down protocol using a sliding window. Each window slot indicates the UP/DOWN message activity during a given period, containing either a "hit" for receipt of an acceptable UP/DOWN message or a "miss" for failure to receive an acceptable UP/DOWN message. In addition to the sliding window, the implementation should include a tally of hits recorded during the current period and a tally of misses recorded over the current window. When the direct connection moves to the down state, the initial values of the up/down protocol parameters must be set as follows: - The sliding window size is equal to m. - Each window slot contains a miss. - The current period hit tally is equal to 0. Steenstrup [Page 33] RFC 1479 IDPR Protocol July 1993 - The current window miss tally is equal to m. When the direct connection moves to the up state, the initial values of the up/down protocol parameters must be set as follows: - The sliding window size is equal to n. - Each window slot contains a hit. - The current period hit tally is equal to 0. - The current window miss tally is equal to 0. At the conclusion of each period, a policy gateway computes the miss tally and determines whether there has been a state transition of the direct connection to the adjacent policy gateway. In the down state, a miss tally of no more than m - j signals a transition to the up state. In the up state, a miss tally of no less than n - k signals a transition to the down state. Computing the correct miss tally involves several steps. First, the policy gateway prepares to slide the window by one slot so that the oldest slot disappears, making room for the newest slot. However, before sliding the window, the policy gateway checks the contents of the oldest window slot. If this slot contains a miss, the policy gateway decrements the miss tally by 1, as this slot is no longer part of the current window. After sliding the window, the policy gateway determines the proper contents. If the hit tally for the current period equals 0, the policy gateway records a miss for the newest slot and increments the miss tally by 1. Otherwise, if the hit tally for the current period is greater than 0, the policy gateway records a hit for the newest slot and decrements the hit tally by 1. Moreover, the policy gateway applies any remaining hits to slots containing misses, beginning with the newest and progressing to the oldest such slot. For each such slot containing a miss, the policy gateway records a hit in that slot and decrements both the hit and miss tallies by 1, as the hit cancels out a miss. The policy gateway continues to apply each remaining hit tallied to any slot containing a miss, until either all such hits are exhausted or all such slots are accounted for. Before beginning the next up/down period, the policy gateway resets the hit tally to 0. Although we expect the hit tally, within any given period, to be no greater than 1, we do anticipate the occasional period in which a policy gateway receives more than one UP/DOWN message from an adjacent policy gateway. The most common reasons for this occurrence are message delay and clock drift. When an UP/DOWN message is Steenstrup [Page 34] RFC 1479 IDPR Protocol July 1993 delayed, the receiving policy gateway observes a miss in one period followed by two hits in the next period, one of which cancels the previous miss. However, excess hits remaining in the tally after miss cancellation indicate a problem, such as clock drift. Thus, whenever a policy gateway accumulates excess hits, it logs the event for network management. When clock drift occurs between two adjacent policy gateways, it causes the period of one policy gateway to grow with respect to the period of the other policy gateway. Let p(X) be the period for PG X, let p(Y) be the period for PG Y, and let g and h be the smallest positive integers such that g * p(X) = h * p(Y). Suppose that p(Y) > p(X) because of clock drift. In this case, PG X observes g - h misses in g consecutive periods, while PG Y observes g - h surplus hits in h consecutive periods. As long as (g - h)/g < (n - k)/n and (g - h)/g < or = (m - j)/m, the clock drift itself will not cause the direct connection to enter or remain in the down state. 3.4. Policy Gateway Connectivity Policy gateways collect connectivity information through the intra- domain routing procedure and through VGP, and they distribute connectivity changes through VGP in both intra-VG messages to peers and inter-VG messages to neighbors. Locally, this connectivity information assists policy gateways in selecting routes, not only across a virtual gateway to an adjacent domain but also across a domain between two virtual gateways. Moreover, changes in connectivity between domains are distributed, in routing information messages, to route servers throughout an internetwork. 3.4.1. Within a Virtual Gateway Each policy gateway within a virtual gateway constantly monitors its connectivity to all adjacent and to all peer policy gateways. To determine the state of its direct connection to an adjacent policy gateway, a policy gateway uses reachability information supplied by the up/down protocol. To determine the state of its intra-domain routes to a peer policy gateway, a policy gateway uses reachability information supplied by either the intra-domain routing procedure or the up/down protocol. A policy gateway generates a PG CONNECT message whenever either of the following conditions is true: - The policy gateway detects a change, in state or in adjacent domain component, associated with its direct connection to an adjacent policy gateway. In this case, the policy gateway distributes a copy of the message to each peer reachable via Steenstrup [Page 35] RFC 1479 IDPR Protocol July 1993 intra-domain routing. - The policy gateway detects that a previously unreachable peer is now reachable. In this case, the policy gateway distributes a copy of the message to the newly reachable peer. A PG CONNECT message is an intra-VG message that includes information about each adjacent policy gateway directly connected to the issuing policy gateway. Specifically, the PG CONNECT message contains the adjacent policy gateway's identifier, status (reachable or unreachable), and domain component identifier. If a PG CONNECT message contains a "request", each peer that receives the message responds to the sender with its own PG CONNECT message. All mutually reachable peers monitor policy gateway connectivity within their virtual gateway, through the up/down protocol, the intra-domain routing procedure, and the exchange of PG CONNECT messages. Within a given virtual gateway, each constituent policy gateway maintains the following information about each configured adjacent policy gateway: - The identifier for the adjacent policy gateway. - The status of the adjacent policy gateway: reachable/unreachable, directly connected/not directly connected. - The local exit interfaces used to reach the adjacent policy gateway, provided it is reachable. - The identifier for the adjacent policy gateway's domain component. - The set of peers to which the adjacent policy gateway is directly-connected. Hence, all mutually reachable peers can detect changes in connectivity across the virtual gateway to adjacent domain components. When the lowest-numbered operational peer policy gateway within a virtual gateway detects a change in the set of adjacent domain components reachable through direct connections across the given virtual gateway, it generates a VGCONNECT message and distributes a copy to a VG representative in all other virtual gateways connected to its domain. A VG CONNECT message is an inter-VG message that includes information about each peer's connectivity across the given virtual gateway. Specifically, the VG CONNECT message contains, for each peer, its identifier and the identifiers of the domain components reachable through its direct connections to adjacent Steenstrup [Page 36] RFC 1479 IDPR Protocol July 1993 policy gateways. Moreover, the VG CONNECT message gives each recipient enough information to determine the state, up or down, of the issuing virtual gateway. The issuing policy gateway, namely the lowest-numbered operational peer, may have to wait up to four times vgp_int microseconds after detecting the connectivity change, before generating and distributing the VGCONNECT message, as described in section 3.1.3. Each recipient VG representative in turn distributes a copy of the VG CONNECT message to each of its peers reachable via intra-domain routing. If a VG CONNECT message contains a "request", then in each recipient virtual gateway, the lowest-numbered operational peer that receives the message responds to the original sender with its own VGCONNECT message. 3.4.2. Between Virtual Gateways At present, we expect transit policies to be uniform over all intra- domain routes between any pair of policy gateways within a domain. However, when tariffed qualities of service become prevalent offerings for intra-domain routing, we can no longer expect uniformity of transit policies throughout a domain. To monitor the transit policies supported on intra-domain routes between virtual gateways requires both a policy-sensitive intra-domain routing procedure and a VGP exchange of policy information between neighbor policy gateways. Each policy gateway within a domain constantly monitors its connectivity to all peer and neighbor policy gateways, including the transit policies supported on intra-domain routes to these policy gateways. To determine the state of its intra-domain connection to a peer or neighbor policy gateway, a policy gateway uses reachability information supplied by either the intra-domain routing procedure or the up/down protocol. To determine the transit policies supported on intra-domain routes to a peer or neighbor policy gateway, a policy gateway uses policy-sensitive reachability information supplied by the intra-domain routing procedure. We note that when transit policies are uniform over a domain, reachability and policy-sensitive reachability are equivalent. Within a virtual gateway, each constituent policy gateway maintains the following information about each configured peer and neighbor policy gateway: - The identifier for the peer or neighbor policy gateway. - The identifiers corresponding to the transit policies configured to be supported by intra-domain routes to the peer or neighbor policy Steenstrup [Page 37] RFC 1479 IDPR Protocol July 1993 gateway. - According to each transit policy, the status of the peer or neighbor policy gateway: reachable/unreachable. - For each transit policy, the local exit interfaces used to reach the peer or neighbor policy gateway, provided it is reachable. - The identifiers for the adjacent domain components reachable through direct connections from the peer or neighbor policy gateway, obtained through VG CONNECT messages. Using this information, a policy gateway can detect changes in its connectivity to an adjoining domain component, with respect to a given transit policy and through a given neighbor. Moreover, combining the information obtained for all neighbors within a given virtual gateway, the policy gateway can detect changes in its connectivity, with respect to a given transit policy, to that virtual gateway and to adjoining domain components reachable through that virtual gateway. All policy gateways mutually reachable via intra-domain routes supporting a configured transit policy need not exchange information about perceived changes in connectivity, with respect to the given transit policy. In this case, each policy gateway can infer another's policy-sensitive reachability to a third, through mutual intra-domain reachability information provided by the intra-domain routing procedure. However, whenever two or more policy gateways are no longer mutually reachable with respect to a given transit policy, these policy gateways can no longer infer each other's reachability to other policy gateways, with respect to that transit policy. In this case, these policy gateways must exchange explicit information about changes in connectivity to other policy gateways, with respect to that transit policy. A policy gateway generates a PG POLICY message whenever either of the following conditions is true: - The policy gateway detects a change in its connectivity to another virtual gateway, with respect to a configured transit policy, or to an adjoining domain component reachable through that virtual gateway. In this case, the policy gateway distributes a copy of the message to each peer reachable via intra-domain routing but not currently reachable via any intra-domain routes of the given transit policy. - The policy gateway detects that a previously unreachable peer is reachable. In this case, the policy gateway distributes a copy of Steenstrup [Page 38] RFC 1479 IDPR Protocol July 1993 the message to the newly reachable peer. A PG POLICY message is an intra-VG message that includes information about each configured transit policy and each virtual gateway configured to be reachable from the issuing policy gateway via intra-domain routes of the given transit policy. Specifically, the PGPOLICY message contains, for each configured transit policy: - The identifier for the transit policy. - The identifiers for the virtual gateways associated with the given transit policy and currently reachable, with respect to that transit policy, from the issuing policy gateway. - The identifiers for the domain components reachable from and adjacent to the members of the given virtual gateways. If a PG POLICY message contains a "request", each peer that receives the message responds to the original sender with its own PG POLICY message. In addition to connectivity between itself and its neighbors, each policy gateway also monitors the connectivity, between domain components adjacent to its virtual gateway and domain components adjacent to other virtual gateways, through its domain and with respect to the configured transit policies. For each member of each of its virtual gateways, a policy gateway monitors: - The set of adjacent domain components currently reachable through direct connections across the given virtual gateway. The policy gateway obtains this information through PG CONNECT messages from reachable peers and through UP/DOWN messages from adjacent policy gateways. - For each configured transit policy, the set of virtual gateways currently reachable from the given virtual gateway with respect to that transit policy and the set of adjoining domain components currently reachable through direct connections across those virtual gateways. The policy gateway obtains this information through PG POLICY messages from peers, VG CONNECT messages from neighbors, and the intra-domain routing procedure. Using this information, a policy gateway can detect connectivity changes, through its domain and with respect to a given transit policy, between adjoining domain components. When the lowest-numbered operational policy gateway within a virtual gateway detects a change in the connectivity between a domain component adjacent to its virtual gateway and a domain component Steenstrup [Page 39] RFC 1479 IDPR Protocol July 1993 adjacent to another virtual gateway in its domain, with respect to a configured transit policy, it generates a VG POLICY message and distributes a copy to a VG representative in selected virtual gateways connected to its domain. In particular, the lowest-numbered operational policy gateway distributes a VG POLICY message to a VG representative in every other virtual gateway containing a member reachable via intra-domain routing but not currently reachable via any routes of the given transit policy. A VG POLICY message is an inter-VG message that includes information about the connectivity between domain components adjacent to the issuing virtual gateway and domain components adjacent to the other virtual gateways in the domain, with respect to configured transit policies. Specifically, the VG POLICY message contains, for each transit policy: - The identifier for the transit policy. - The identifiers for the virtual gateways associated with the given transit policy and currently reachable, with respect to that transit policy, from the issuing virtual gateway. - The identifiers for the domain components reachable from and adjacent to the members of the given virtual gateways. The issuing policy gateway, namely the lowest-numbered operational peer, may have to wait up to four times vgp_int microseconds after detecting the connectivity change, before generating and distributing the VG POLICY message, as described in section 3.1.3. Each recipient VG representative in turn distributes a copy of the VG POLICY message to each of its peers reachable via intra-domain routing. If a VG POLICY message contains a "request", then in each recipient virtual gateway, the lowest-numbered operational peer that receives the message responds to the original sender with its own VG POLICY message. 3.4.3. Communication Complexity We offer an example, to provide an estimate of the number of VGP messages exchanged within a domain, AD X, after a detected change in policy gateway connectivity. Suppose that an adjacent domain, AD Y, partitions such that the partition is detectable through the exchange of UP/DOWN messages across a virtual gateway connecting AD X and AD Y. Let V be the number of virtual gateways in AD X. Suppose each virtual gateway contains P peer policy gateways, and no policy gateway is a member of multiple virtual gateways. Then, within AD X, the detected partition will result in the following VGP message exchanges: - P policy gateways each receive at most P-1 PG CONNECT messages. Steenstrup [Page 40] RFC 1479 IDPR Protocol July 1993 Each policy gateway detecting the adjacent domain partition generates a PG CONNECT message and distributes it to each reachable peer in the virtual gateway. - P * (V-1) policy gateways each receive at most one VG CONNECT message. The lowest-numbered operational policy gateway in the virtual gateway detecting the partition of the adjacent domain generates a VG CONNECT message and distributes it to a VG representative in all other virtual gateways connected to the domain. In turn, each VG representative distributes the VG CONNECT message to each reachable peer within its virtual gateway. - P * (V-1) policy gateways each receive at most P-1 PG POLICY messages, and only if the domain has more than a single uniform transit policy. Each policy gateway in each virtual gateway generates a PG POLICY message and distributes it to all reachable peers not currently reachable with respect to the given transit policy. - P * V policy gateways each receive at most V-1 VG POLICY messages, only if the domain has more than a single uniform transit policy. The lowest-numbered operational policy gateway in each virtual gateway generates a VG POLICY message and distributes it to a VG representative in all other virtual gateways containing at least one reachable member not currently reachable with respect to the given transit policy. In turn, each VG representative distributes a VG POLICY message to each peer within its virtual gateway. 3.5. VGP Message Formats The virtual gateway protocol number is equal to 0. We describe the contents of each type of VGP message below. 3.5.1. UP/DOWN The UP/DOWN message type is equal to 0. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRC CMP | DST AD | +-------------------------------+---------------+---------------+ | DST PG | PERIOD | STATE | +-------------------------------+---------------+---------------+ SRC CMP (16 bits) Numeric identifier for the domain component containing the issuing policy gateway. Steenstrup [Page 41] RFC 1479 IDPR Protocol July 1993 DST AD (16 bits) Numeric identifier for the destination domain. DST PG (16 bits) Numeric identifier for the destination policy gateway. PERIOD (8 bits) Length of the UP/DOWN message generation period, in seconds. STATE (8 bits) Perceived state (1 up, 0 down) of the direct connection from the perspective of the issuing policy gateway, contained in the right-most bit. 3.5.2. PG CONNECT The PG CONNECT message type is equal to 1. PG CONNECT messages are not required for any virtual gateway containing exactly two policy gateways. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADJ AD | VG | RQST | +-------------------------------+---------------+---------------+ | NUM RCH | NUM UNRCH | +-------------------------------+-------------------------------+ For each reachable adjacent policy gateway: +-------------------------------+-------------------------------+ | ADJ PG | ADJ CMP | +-------------------------------+-------------------------------+ For each unreachable adjacent policy gateway: +-------------------------------+ | ADJ PG | +-------------------------------+ ADJ AD (16 bits) Numeric identifier for the adjacent domain. VG (8 bits) Numeric identifier for the virtual gateway. RQST (8 bits) Request for a PG CONNECT message (1 request, 0 no request) from each recipient peer, contained in the right-most bit. NUM RCH (16 bits) Number of adjacent policy gateways within the virtual gateway, which are directly-connected to and currently reachable from the issuing policy gateway. NUM UNRCH (16 bits) Number of adjacent policy gateways within the Steenstrup [Page 42] RFC 1479 IDPR Protocol July 1993 virtual gateway, which are directly-connected to but not currently reachable from the issuing policy gateway. ADJ PG (16 bits) Numeric identifier for a directly-connected adjacent policy gateway. ADJ CMP (16 bits) Numeric identifier for the domain component containing the reachable, directly-connected adjacent policy gateway. 3.5.3. PG POLICY The PG POLICY message type is equal to 2. PG POLICY messages are not required for any virtual gateway containing exactly two policy gateways or for any domain with a single uniform transit policy. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADJ AD | VG | RQST | +-------------------------------+---------------+---------------+ | NUM TP | +-------------------------------+ For each transit policy associated with the virtual gateway: +-------------------------------+-------------------------------+ | TP | NUM VG | +-------------------------------+-------------------------------+ For each virtual gateway reachable via the transit policy: +-------------------------------+---------------+---------------+ | ADJ AD | VG | UNUSED | +-------------------------------+---------------+---------------+ | NUM CMP | ADJ CMP | +-------------------------------+-------------------------------+ ADJ AD (16 bits) Numeric identifier for the adjacent domain. VG (8 bits) Numeric identifier for the virtual gateway. RQST (8 bits) Request for a PG POLICY message (1 request, 0 no request) from each recipient peer, contained in the right-most bit. NUM TP (8 bits) Number of transit policies configured to include the virtual gateway. TP (16 bits) Numeric identifier for a transit policy associated with the virtual gateway. Steenstrup [Page 43] RFC 1479 IDPR Protocol July 1993 NUM VG (16 bits) Number of virtual gateways reachable from the issuing policy gateway, via intra-domain routes supporting the transit policy. UNUSED (8 bits) Not currently used; must be set equal to 0. NUM CMP (16 bits) Number of adjacent domain components reachable via direct connections through the virtual gateway. ADJ CMP (16 bits) Numeric identifier for a reachable adjacent domain component. 3.5.4. VG CONNECT The VG CONNECT message type is equal to 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADJ AD | VG | RQST | +-------------------------------+---------------+---------------+ | NUM PG | +-------------------------------+ For each reach policy gateway in the virtual gateway: +-------------------------------+-------------------------------+ | PG | NUM CMP | +-------------------------------+-------------------------------+ | ADJ CMP | +-------------------------------+ ADJ AD (16 bits) Numeric identifier for the adjacent domain. VG (8 bits) Numeric identifier for the virtual gateway. RQST (8 bits) Request for a VG CONNECT message (1 request, 0 no request) from a recipient in each virtual gateway, contained in the right-most bit. NUM PG (16 bits) Number of mutually-reachable peer policy gateways in the virtual gateway. PG (16 bits) Numeric identifier for a peer policy gateway. NUM CMP (16 bits) Number of components of the adjacent domain reachable via direct connections from the policy gateway. Steenstrup [Page 44] RFC 1479 IDPR Protocol July 1993 ADJ CMP (16 bits) Numeric identifier for a reachable adjacent domain component. 3.5.5. VG POLICY The VG POLICY message type is equal to 4. VG POLICY messages are not required for any domain with a single uniform transit policy. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADJ AD | VG | RQST | +-------------------------------+---------------+---------------+ | NUM TP | +-------------------------------+ For each transit policy associated with the virtual gateway: +-------------------------------+-------------------------------+ | TP | NUM GRP | +-------------------------------+-------------------------------+ For each virtual gateway group reachable via the transit policy: +-------------------------------+-------------------------------+ | NUM VG | ADJ AD | +---------------+---------------+-------------------------------+ | VG | UNUSED | NUM CMP | +---------------+---------------+-------------------------------+ | ADJ CMP | +-------------------------------+ ADJ AD (16 bits) Numeric identifier for the adjacent domain. VG (8 bits) Numeric identifier for the virtual gateway. RQST (8 bits) Request for a VG POLICY message (1 request, 0 no request) from a recipient in each virtual gateway, contained in the right-most bit. NUM TP (16 bits) Number of transit policies configured to include the virtual gateway. TP (16 bits) Numeric identifier for a transit policy associated with the virtual gateway. NUM GRP (16 bits) Number of groups of virtual gateways, such that all members in a group are reachable from the issuing virtual gateway via intra-domain routes supporting the given transit policy. Steenstrup [Page 45] RFC 1479 IDPR Protocol July 1993 NUM VG (16 bits) Number of virtual gateways in a virtual gateway group. UNUSED (8 bits) Not currently used; must be set equal to 0. NUM CMP (16 bits) Number of adjacent domain components reachable via direct connections through the virtual gateway. ADJ CMP (16 bits) Numeric identifier for a reachable adjacent domain component. Normally, each VG POLICY message will contain a single virtual gateway group. However, if the issuing virtual gateway becomes partitioned such that peers are mutually reachable with respect to some transit policies but not others, virtual gateway groups may be necessary. For example, let PG X and PG Y be two peers in VG A which configured to support transit policies 1 and 2. Suppose that PG X and PG Y are reachable with respect to transit policy 1 but not with respect to transit policy 2. Furthermore, suppose that PG X can reach members of VG B via intra-domain routes of transit policy 2 and that PG Y can reach members of VG C via intra-domain routes of transit policy 2. Then the entry in the VG POLICY message issued by VG A will include, for transit policy 2, two groups of virtual gateways, one containing VG B and one containing VG C. 3.5.6. Negative Acknowledgements When a policy gateway receives an unacceptable VGP message that passes the CMTP validation checks, it includes, in its CMTP ACK, an appropriate VGP negative acknowledgement. This information is placed in the INFORM field of the CMTP ACK (described previously in section 2.4); the numeric identifier for each type of VGP negative acknowledgement is contained in the left-most 8 bits of the INFORM field. Negative acknowledgements associated with VGP include the following types: 1. Unrecognized VGP message type. Numeric identifier for the unrecognized message type (8 bits). 2. Out-of-date VGP message. 3. Unrecognized virtual gateway source. Numeric identifier for the unrecognized virtual gateway including the adjacent domain identifier (16 bits) and the local identifier (8 bits). Steenstrup [Page 46] RFC 1479 IDPR Protocol July 1993 4. Routing Information Distribution Each domain participating in IDPR generates and distributes its routing information messages to route servers throughout an internetwork. IDPR routing information messages contain information about the transit policies in effect across the given domain and the virtual gateway connectivity to adjacent domains. Route servers in turn use IDPR routing information to generate policy routes between source and destination domains. There are three different procedures for distributing IDPR routing information: - The flooding protocol. In this case, a representative policy gateway in each domain floods its routing information messages to route servers in all other domains. - Remote route server communication. In this case, a route server distributes its domain's routing information messages to route servers in specific destination domains, by encapsulating these messages within IDPR data messages. Thus, a domain administrator may control the distribution of the domain's routing information by restricting routing information exchange with remote route servers. Currently, routing information distribution restrictions are not included in IDPR configuration information. - The route server query protocol. In this case, a policy gateway or route server requests routing information from another route server, which in turn responds with routing information from its database. The route server query protocol may be used for quickly updating the routing information maintained by a policy gateway or route server that has just been connected or reconnected to an internetwork. It may also be used to retrieve routing information from domains that restrict distribution of their routing information. In this section, we describe the flooding protocol only. In section 5, we describe the route server query protocol, and in section 5.2, we describe communication between route servers in separate domains. Policy gateways and route servers use CMTP for reliable transport of IDPR routing information messages flooded between peer, neighbor, and adjacent policy gateways and between those policy gateways and route servers. The issuing policy gateway must communicate to CMTP the maximum number of transmissions per routing information message, flood_ret, and the interval between routing information message retransmissions, flood_int microseconds. The recipient policy gateway or route server must determine routing information message Steenstrup [Page 47] RFC 1479 IDPR Protocol July 1993 acceptability, as we describe in section 4.2.3 below. 4.1. AD Representatives We designate a single policy gateway, the "AD representative", for generating and distributing IDPR routing information about its domain, to ensure that the routing information distributed is consistent and unambiguous and to minimize the communication required for routing information distribution. There is usually only a single AD representative per domain, namely the lowest-numbered operational policy gateway in the domain. Within a domain, policy gateways need no explicit election procedure to determine the AD representative. Instead, all members of a set of policy gateways mutually reachable via intra-domain routes can agree on set membership and therefore on which member has the lowest number. A partitioned domain has as many AD representatives as it does domain components. In fact, the numeric identifier for an AD representative is identical to the numeric identifier for a domain component. One cannot normally predict when and where a domain partition will occur, and thus any policy gateway within a domain may become an AD representative at any time. To prepare for the role of AD representative in the event of a domain partition, every policy gateway must continually monitor its domain's IDPR routing information, through VGP and through the intra-domain routing procedure. 4.2. Flooding Protocol An AD representative policy gateway uses unrestricted flooding among all domains to distribute its domain's IDPR routing information messages to route servers in an internetwork. There are two kinds of IDPR routing information messages issued by each AD representative: CONFIGURATION and DYNAMIC messages. Each CONFIGURATION message contains the transit policy information configured by the domain administrator, including for each transit policy, its identifier, its specification, and the sets of virtual gateways configured as mutually reachable via intra-domain routes supporting the given transit policy. Each DYNAMIC message contains information about current virtual gateway connectivity to adjacent domains and about the sets of virtual gateways currently mutually reachable via intra- domain routes supporting the configured transit policies. The IDPR Flooding Protocol is similar to the flooding procedures described in [9]-[11]. Through flooding, the AD representative distributes its routing information messages to route servers in its own domain and in adjacent domains. After generating a routing information message, the AD representative distributes a copy to each Steenstrup [Page 48] RFC 1479 IDPR Protocol July 1993 of its peers and to a selected VG representative (see section 3.1.4) in all other virtual gateways connected to the domain. Each VG representative in turn distributes a copy of the routing information message to each of its peers. We note that distribution of routing information messages among virtual gateways and among peers within a virtual gateway is identical to distribution of inter-VG messages in VGP, as described in section 3.1.3. Within a virtual gateway, each policy gateway distributes a copy of the routing information message: - To each route server in its configured set of route servers. A domain administrator should ensure that each route server not contained within a policy gateway appears in the set of configured route servers for at least two distinct policy gateways. Hence, such a route server will continue to receive routing information messages, even when one of the policy gateways becomes unreachable. However, the route server will normally receive duplicate copies of a routing information message. - To certain directly-connected adjacent policy gateways. A policy gateway distributes a routing information message to a directly-connected adjacent policy gateway in an adjacent domain component, only when it is the lowest-numbered operational peer with a direct connection to the given domain component. We note that each policy gateway knows, through information provided by VGP, which peers have direct connections to which components of the adjacent domain. If the policy gateway has direct connections to more than one adjacent policy gateway in that domain component, it selects the routing information message recipient according to the order in which the adjacent policy gateways appear in its database, choosing the first one encountered. This selection procedure ensures that a copy of the routing information message reaches each component of the adjacent domain, while limiting the number of copies distributed. Once a routing information message reaches an adjacent policy gateway, that policy gateway distributes copies of the message throughout its domain. The adjacent policy gateway, acting as the first recipient of the routing information message in its domain, follows the same message distribution procedure as the AD representative in the source domain, as described above. The flooding procedure terminates when all reachable route servers in an internetwork receive a copy of the routing information message. Neighbor policy gateways may receive copies of the same routing information message from different adjoining domains. If two neighbor policy gateways receive the message copies simultaneously, Steenstrup [Page 49] RFC 1479 IDPR Protocol July 1993 they will distribute them to VG representatives in other virtual gateways within their domain, resulting in duplicate message distribution. However, each policy gateway stops the spread of duplicate routing information messages as soon as it detects them, as described in section 4.2.3 below. In the Internet, we expect simultaneous message receptions to be the exception rather than the rule, given the hierarchical structure of the current topology. 4.2.1. Message Generation An AD representative generates and distributes a CONFIGURATION message whenever there is a configuration change in a transit policy or virtual gateway associated with its domain. This ensures that route servers maintain an up-to-date view of a domain's configured transit policies and adjacencies. An AD representative may also distribute a CONFIGURATION message at a configurable period of conf_per (500) hours. A CONFIGURATION message contains, for each configured transit policy, the identifier assigned by the domain administrator, the specification, and the set of associated "virtual gateway groups". Each virtual gateway group comprises virtual gateways configured to be mutually reachable via intra-domain routes of the given transit policy. Accompanying each virtual gateway listed is an indication of whether the virtual gateway is configured to be a domain entry point, a domain exit point, or both according to the given transit policy. The CONFIGURATION message also contains the set of local route servers that the domain administrator has configured to be available to IDPR clients in other domains. An AD representative generates and distributes a DYNAMIC message whenever there is a change in currently supported transit policies or in current virtual gateway connectivity associated with its domain. This ensures that route servers maintain an up-to-date view of a domain's supported transit policies and existing adjacencies and how they differ from those configured for the domain. Specifically, an AD representative generates a DYNAMIC message whenever there is a change in the connectivity, through the given domain and with respect to a configured transit policy, between two components of adjoining domains. An AD representative may also distribute a DYNAMIC message at a configurable period of dyn_per (24) hours. A DYNAMIC message contains, for each configured transit policy, its identifier, associated virtual gateway groups, and domain components reachable through virtual gateways in each group. Each DYNAMIC message also contains the set of currently "unavailable", either down or unreachable, virtual gateways in the domain. We note that each virtual gateway group expressed in a DYNAMIC message may be a proper subset of one of the corresponding virtual gateway groups expressed in a CONFIGURATION message. For example, Steenstrup [Page 50] RFC 1479 IDPR Protocol July 1993 suppose that, for a given domain, the virtual gateway group (VG A,...,VG E) were configured for a transit policy such that each virtual gateway was both a domain entry and exit point. Thus, all virtual gateways in this group are configured to be mutually reachable via intra-domain routes of the given transit policy. Now suppose that VG E becomes unreachable because of a power failure and furthermore that the remaining virtual gateways form two distinct groups, (VG A,VG B) and (VG C,VG D), such that although virtual gateways in both groups are still mutually reachable via some intra- domain routes they are no longer mutually reachable via any intra- domain routes of the given transit policy. In this case, the virtual gateway groups for the given transit policy now become (VG A,VG B) and (VG C,VG D); VG E is listed as an unavailable virtual gateway. A route server uses information about the set of unavailable virtual gateways to determine which of its routes are no longer viable, and it subsequently removes such routes from its route database. Although route servers could determine the set of unavailable virtual gateways using information about configured virtual gateways and currently reachable virtual gateways, the associated processing cost is high. In particular, a route server would have to examine all virtual gateway groups listed in a DYNAMIC message to determine whether there are any unavailable virtual gateways in the given domain. To reduce the message processing at each route server, we have chosen to include the set of unavailable virtual gateways in each DYNAMIC message. In order to construct a DYNAMIC message, an AD representative assembles information gathered from intra-domain routing and from VGP. Specifically, the AD representative uses the following information: - VG CONNECT and UP/DOWN messages to determine the state, up or down, of each of its domain's virtual gateways and the adjacent domain components reachable through a given virtual gateway. - Intra-domain routing information to determine, for each of its domain's transit policies, whether a given virtual gateway in the domain is reachable with respect to that transit policy. - VG POLICY messages to determine the connectivity of adjoining domain components, across the given domain and with respect to a configured transit policy, such that these components are adjacent to virtual gateways not currently reachable from the AD representative's virtual gateway according to the given transit policy. Steenstrup [Page 51] RFC 1479 IDPR Protocol July 1993 4.2.2. Sequence Numbers Each IDPR routing information message carries a sequence number which, when used in conjunction with the timestamp carried in the CMTP message header, determines the recency of the message. An AD representative assigns a sequence number to each routing information message it generates, depending upon its internal clock time: - The AD representative sets the sequence number to 0, if its internal clock time is greater than the timestamp in its previously generated routing information message. - The AD representative sets the sequence number to 1 greater than the sequence number in its previously generated routing information message, if its internal clock time equals the timestamp for its previously generated routing information message and if the previous sequence number is less than the maximum value (currently 2**16 - 1). If the previous sequence number equals the maximum value, the AD representative waits until its internal clock time exceeds the timestamp in its previously generated routing information message and then sets the sequence number to 0. In general, we do not expect generation of multiple distinct IDPR routing information messages carrying identical timestamps, and so the sequence number may seem superfluous. However, the sequence number may become necessary during synchronization of an AD representative's internal clock. In particular, the AD representative may need to freeze the clock value during synchronization, and thus distinct sequence numbers serve to distinguish routing information messages generated during the clock synchronization interval. 4.2.3. Message Acceptance Prior to a policy gateway forwarding a routing information message or a route server incorporating routing information into its routing information database, the policy gateway or route server assesses routing information message acceptability. An IDPR routing information message is "acceptable" if: - It passes the CMTP validation checks. - Its timestamp is less than conf_old (530) hours behind the recipient's internal clock time for CONFIGURATION messages and less than dyn_old (25) hours behind the recipient's internal clock time for DYNAMIC messages. - Its timestamp and sequence number indicate that it is more recent Steenstrup [Page 52] RFC 1479 IDPR Protocol July 1993 than the currently-stored routing information from the given domain. If there is no routing information currently stored from the given domain, then the routing information message contains, by default, the more recent information. Policy gateways acknowledge and forward acceptable IDPR routing information messages, according to the flooding protocol described in section 4.2 above. Moreover, each policy gateway retains the timestamp and sequence number for the most recently accepted routing information message from each domain and uses these values to determine acceptability of routing information messages received in the future. Route servers acknowledge the receipt of acceptable routing information messages and incorporate the contents of these messages into their routing information databases, contingent upon criteria discussed in section 4.2.4 below; however, they do not participate in the flooding protocol. We note that when a policy gateway or route server first returns to service, it immediately updates its routing information database with routing information obtained from another route server, using the route server query protocol described in section 5. An AD representative takes special action upon receiving an acceptable routing information message, supposedly generated by itself but originally obtained from a policy gateway or route server other than itself. There are at least three possible reasons for the occurrence of this event: - The routing information message has been corrupted in a way that is not detectable by the integrity/authentication value. - The AD representative has experienced a memory error. - Some other entity is generating routing information messages on behalf of the AD representative. In any case, the AD representative logs the event for network management. Moreover, the AD representative must reestablish its own routing information messages as the most recent for its domain. To do so, the AD representative waits until its internal clock time exceeds the value of the timestamp in the received routing information message and then generates a new routing information message using the currently-stored domain routing information supplied by VGP and by the intra-domain routing procedure. Note that the length of time the AD representative must wait to generate the new message is at most cmtp_new (300) seconds, the maximum CMTP- tolerated difference between the received message's timestamp and the AD representative's internal clock time. Steenstrup [Page 53] RFC 1479 IDPR Protocol July 1993 IDPR routing information messages that pass the CMTP validity checks but appear less recent than stored routing information are unacceptable. Policy gateways do not forward unacceptable routing information messages, and route servers do not incorporate the contents of unacceptable routing information messages into their routing information databases. Instead, the recipient of an unacceptable routing information message acknowledges the message in one of two ways: - If the routing information message timestamp and sequence number equal to the timestamp and sequence number associated with the stored routing information for the given domain, the recipient assumes that the routing information message is a duplicate and acknowledges the message. - If the routing information message timestamp and sequence number indicate that the message is less recent than the stored routing information for the domain, the recipient acknowledges the message with an indication that the routing information it contains is out-of-date. Such a negative acknowledgement is a signal to the sender of the routing information message to request more up-to- date routing information from a route server, using the route server query protocol. Furthermore, if the recipient of the out- of-date routing information message is a route server, it regenerates a routing information message from its own routing information database and forwards the message to the sender. The sender may in turn propagate this more recent routing information message to other policy gateways and route servers. 4.2.4. Message Incorporation A route server usually stores the entire contents of an acceptable IDPR routing information message in its routing information database, so that it has access to all advertised transit policies when generating a route and so that it can regenerate routing information messages at a later point in time if requested to do so by another route server or policy gateway. However, a route server may elect not to store all routing information message contents. In particular, the route server need not store any transit policy that excludes the route server's domain as a source or any routing information from a domain that the route server's domain's source policies exclude for transit. Selective storing of routing information message contents simplifies the route generation procedure since it reduces the search space of possible routes, and it limits the amount of route server memory devoted to routing information. However, selective storing of routing information also means that the route server cannot always regenerate the original routing information message, if requested to do so by another route Steenstrup [Page 54] RFC 1479 IDPR Protocol July 1993 server or policy gateway. An acceptable IDPR routing information message may contain transit policy information that is not well-defined according to the route server's perception. A CONFIGURATION message may contain an unrecognized domain, virtual gateway, or transit policy attribute, such as user class access restrictions or offered service. In this case, "unrecognized" means that the value in the routing information message is not listed in the route server's configuration database, as described previously in section 1.8.2. A DYNAMIC message may contain an unrecognized transit policy or virtual gateway. In this case, "unrecognized" means that the transit policy or virtual gateway was not listed in the most recent CONFIGURATION message for the given domain. Each route server can always parse an acceptable routing information messsage, even if some of the information is not well-defined, and thus can always use the information that it does recognize. Therefore, a route server can store the contents of acceptable routing information messages from domains in which it is interested, regardless of whether all contents appear to be well-defined at present. If a routing message contains unrecognized information, the route server may attempt to obtain the additional information it needs to decipher the unrecognized information. For a CONFIGURATION message, the route server logs the event for network management; for a DYNAMIC message, the route server requests, from another route server, the most recent CONFIGURATION message for the domain in question. When a domain is partitioned, each domain component has its own AD representative, which generates routing information messages on behalf of that component. Discovery of a domain partition prompts the AD representative for each domain component to generate and distribute a DYNAMIC message. In this case, a route server receives and stores more than one routing information message at a time for the given domain, namely one for each domain component. When the partition heals, the AD representative for the entire domain generates and distributes a DYNAMIC message. In each route server's routing information database, the new DYNAMIC message does not automatically replace all of the currently-stored DYNAMIC messages for the given domain. Instead, the new message only replaces that message whose AD representative matches the AD representative for the new message. The other DYNAMIC messages, generated during the period over which the partition occurred, remain in the routing information database until they attain their maximum lifetime, as described in section 4.2.5 below. Such stale information may lead to the generation of routes that result in path setup failures and hence the Steenstrup [Page 55] RFC 1479 IDPR Protocol July 1993 selection of alternative routes. To reduce the chances of path setup failures, we will investigate, for a future version of IDPR, mechanisms for removing partition-related DYNAMIC messages immediately after a partition disappears. 4.2.5. Routing Information Database We expect that most of the IDPR routing information stored in a routing information database will remain viable for long periods of time, perhaps until a domain reconfiguration occurs. By "viable", we mean that the information reflects the current state of the domain and hence may be used successfully for generating policy routes. To reduce the probability of retaining stale routing information, a route server imposes a maximum lifetime on each database entry, initialized when it incorporates an accepted entry into its routing information database. The maximum lifetime should be longer than the corresponding message generation period, so that the database entry is likely to be refreshed before it attains its maximum lifetime. Each CONFIGURATION message stored in the routing information database has a maximum lifetime of conf_old (530) hours; each DYNAMIC message stored in the routing information database has a maximum lifetime of dyn_old (25) hours. Periodic generation of routing information messages makes it unlikely that any routing information message will remain in a routing information database for its full lifetime. However, a routing information message may attain its maximum lifetime in a route server that is separated from a internetwork for a long period of time. When an IDPR routing information message attains its maximum lifetime in a routing information database, the route server removes the message contents from its database, so that it will not generate new routes with the outdated routing information nor distribute old routing information in response to requests from other route servers or policy gateways. Nevertheless, the route server continues to dispense routes previously generated with the old routing information, as long as path setup (see section 7) for these routes succeeds. The route server treats routing information message lifetime expiration differently, depending on the type of routing information message. When a CONFIGURATION message expires, the route server requests, from another route server, the most recent CONFIGURATION message issued for the given domain. When a DYNAMIC message expires, the route server does not initially attempt to obtain more recent routing information. Instead, if route generation is necessary, the route server uses the routing information contained in the corresponding CONFIGURATION message for the given domain. Only if Steenstrup [Page 56] RFC 1479 IDPR Protocol July 1993 there is a path setup failure (see section 7.4) involving the given domain does the route server request, from another route server, the most recent DYNAMIC message issued for the given domain. 4.3. Routing Information Message Formats The flooding protocol number is equal to 1. We describe the contents of each type of routing information message below. 4.3.1. CONFIGURATION The CONFIGURATION message type is equal to 0. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD CMP | SEQ | +-------------------------------+-------------------------------+ | NUM TP | NUM RS | +-------------------------------+-------------------------------+ | RS | +-------------------------------+ For each transit policy configured for the domain: +-------------------------------+-------------------------------+ | TP | NUM ATR | +-------------------------------+-------------------------------+ For each attribute of the transit policy: +-------------------------------+-------------------------------+ | ATR TYP | ATR LEN | +-------------------------------+-------------------------------+ For the source/destination access restrictions attribute: +-------------------------------+ | NUM AD GRP | +-------------------------------+ For each domain group in the source/destination access restrictions: +-------------------------------+-------------------------------+ | NUM AD | AD | +---------------+---------------+-------------------------------+ | AD FLGS | NUM HST | HST SET | +---------------+---------------+-------------------------------+ For the temporal access restrictions attribute: +-------------------------------+ | NUM TIM | +-------------------------------+ Steenstrup [Page 57] RFC 1479 IDPR Protocol July 1993 For each set of times in the temporal access restrictions: +---------------+-----------------------------------------------+ | TIM FLGS | DURATION | +---------------+-----------------------------------------------+ | START | +-------------------------------+-------------------------------+ | PERIOD | ACTIVE | +-------------------------------+-------------------------------+ For the user class access restrictions attribute: +-------------------------------+ | NUM UCI | +-------------------------------+ For each UCI in the user class access restrictions: +---------------+ | UCI | +---------------+ For each offered service attribute: +---------------------------------------------------------------+ | OFR SRV | +---------------------------------------------------------------+ For the virtual gateway access restrictions attribute: +-------------------------------+ | NUM VG GRP | +-------------------------------+ For each virtual gateway group in the virtual gateway access restrictions: +-------------------------------+-------------------------------+ | NUM VG | ADJ AD | +---------------+---------------+-------------------------------+ | VG | VG FLGS | +---------------+---------------+ AD CMP (16 bits) Numeric identifier for the domain component containing the AD representative policy gateway. SEQ (16 bits) Routing information message sequence number. NUM TP (16 bits) Number of transit policy specifications contained in the routing information message. NUM RS (16 bits) Number of route servers advertised to serve clients outside of the domain. RS (16 bits) Numeric identifier for a route server. TP (16 bits) Numeric identifier for a transit policy specification. Steenstrup [Page 58] RFC 1479 IDPR Protocol July 1993 NUM ATR (16 bits) Number of attributes associated with the transit policy. ATR TYP (16 bits) Numeric identifier for a type of attribute. Valid attributes include the following types: - Set of virtual gateway access restrictions (see section 1.4.2) associated with the transit policy (variable). This attribute must be included. - Set of source/destination access restrictions (see section 1.4.2) associated with the transit policy (variable). This attribute may be omitted. Absence of this attribute implies that traffic from any source to any destination is acceptable. - Set of temporal access restrictions (see section 1.4.2) associated with the transit policy (variable). This attribute may be omitted. Absence of this attribute implies that the transit policy applies at all times. - Set of user class access restrictions (see section 1.4.2) associated with the transit policy (variable). This attribute may be omitted. Absence of this attribute implies that traffic from any user class is acceptable. - Average delay in milliseconds (16 bits). This attribute may be omitted. - Delay variation in milliseconds (16 bits). This attribute may be omitted. - Average available bandwidth in bits per second (48 bits). This attribute may be omitted. - Available bandwidth variation in bits per second (48 bits). This attribute may be omitted. - MTU in bytes (16 bits). This attribute may be omitted. - Charge per byte in thousandths of a cent (16 bits). This attribute may be omitted. - Charge per message in thousandths of a cent (16 bits). This attribute may be omitted. - Charge for session time in thousandths of a cent per second (16 bits). This attribute may be omitted. Absence of any charge attribute implies that the domain provides free transit service. Steenstrup [Page 59] RFC 1479 IDPR Protocol July 1993 ATR LEN (16 bits) Length of an attribute in bytes, beginning with the subsequent field. NUM AD GRP (16 bits) Number of source/destination domain groups (see section 1.4.2) associated with the source/destination access restrictions. NUM AD (16 bits) Number of domains or sets of domains in a domain group. AD (16 bits) Numeric identifier for a domain or domain set. AD FLGS (8 bits) Set of five flags indicating how to interpret the AD field, contained in the right-most bits. Proceeding left to right, the first flag indicates whether the transit policy applies to all domains or to specific domains (1 all, 0 specific), and when set to 1, causes the second and third flags to be ignored. The second flag indicates whether the domain identifier signifies a single domain or a domain set (1 single, 0 set). The third flag indicates whether the transit policy applies to the given domain or domain set (1 applies, 0 does not apply) and is used for representing complements of sets of domains. The fourth flag indicates whether the domain is a source (1 source, 0 not source). The fifth flag indicates whether the domain is a destination (1 destination, 0 not destination). At least one of the fourth and fifth flags must be set to 1. NUM HST (8 bits) Number of "host sets" (see section 1.4.2) associated with a particular domain or domain set. The value 0 indicates that all hosts in the given domain or domain set are acceptable sources or destinations, as specified by the fourth and fifth AD flags. HST SET (16 bits) Numeric identifier for a host set. NUM TIM (16 bits) Number of time specifications associated with the temporal access restrictions. Each time specification is split into a set of continguous identical periods, as we describe below. TIM FLGS (8 bits) Set of two flags indicating how to combine the time specifications, contained in the right-most bits. Proceeding left to right, the first flag indicates whether the transit policy applies during the periods specified in the time specification (1 applies, 0 does not apply) and is used for representing complements of policy applicability intervals. The second flag indicates whether the time specification takes precedence over the previous time specifications listed (1 precedence, 0 no precedence). Precedence is equivalent to the boolean OR and AND operators, in the following sense. At any given instant, a transit policy either applies or does not apply, according to a given time specification, and we can assign a boolean Steenstrup [Page 60] RFC 1479 IDPR Protocol July 1993 value to the state of policy applicability according to a given time specification. If the second flag assumes the value 1 for a given time specification, that indicates the boolean operator OR should be applied to the values of policy applicability, according to the given time specification and to all previously listed time specifications. If the second flag assumes the value 0 for a given time specification, that indicates the boolean operator AND should be applied to the values of policy applicability, according to the given time specification and to all previously listed time specifications. DURATION (24 bits) Length of the time specification duration, in minutes. A value of 0 indicates an infinite duration. START (32 bits) Time at which the time specification first takes effect, in seconds elapsed since 1 January 1970 0:00 GMT. PERIOD (16 bits) Length of each time period within the time specification, in minutes. ACTIVE (16 bits) Length of the policy applicable interval during each time period, in minutes from the beginning of the time period. NUM UCI (16 bits) Number of user classes associated with the user class access restrictions. UCI (8 bits) Numeric identifier for a user class. NUM VG GRP (16 bits) Number of virtual gateway groups (see section 1.4.2) associated with the virtual gateway access restrictions. NUM VG (16 bits) Number of virtual gateways in a virtual gateway group. ADJ AD (16 bits) Numeric identifier for the adjacent domain to which a virtual gateway connects. VG (8 bits) Numeric identifier for a virtual gateway. VG FLGS (8 bits) Set of two flags indicating how to interpret the VG field, contained in the right-most bits. Proceeding left to right, the first flag indicates whether the virtual gateway is a domain entry point (1 entry, 0 not entry). The second flag indicates whether the virtual gateway is a domain exit point (1 exit, 0 not exit). At least one of the first and second flags must be set to 1. Steenstrup [Page 61] RFC 1479 IDPR Protocol July 1993 4.3.2. DYNAMIC The DYNAMIC message type is equal to 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD CMP | SEQ | +-------------------------------+-------------------------------+ | UNAVL VG | NUM PS | +-------------------------------+-------------------------------+ For each unavailable virtual gateway in the domain: +-------------------------------+---------------+---------------+ | ADJ AD | VG | UNUSED | +-------------------------------+---------------+---------------+ For each set of transit policies for the domain: +-------------------------------+-------------------------------+ | NUM TP | NUM VG GRP | +-------------------------------+-------------------------------+ | TP | +-------------------------------+ For each virtual gateway group associated with the transit policy set: +-------------------------------+-------------------------------+ | NUM VG | ADJ AD | +---------------+---------------+-------------------------------+ | VG | VG FLGS | NUM CMP | +---------------+---------------+-------------------------------+ | ADJ CMP | +-------------------------------+ AD CMP (16 bits) Numeric identifier for the domain component containing the AD representative policy gateway. SEQ (16 bits) Routing information message sequence number. UNAVL VG (16 bits) Number of virtual gateways in the domain component that are currently unavailable via any intra-domain routes. NUM PS (16 bits) Number of sets of transit policies listed. Transit policy sets provide a mechanism for reducing the size of DYNAMIC messages. A single set of virtual gateway groups applies to all transit policies in a given set. ADJ AD (16 bits) Numeric identifier for the adjacent domain to which a virtual gateway connects. Steenstrup [Page 62] RFC 1479 IDPR Protocol July 1993 VG (8 bits) Numeric identifier for a virtual gateway. UNUSED (8 bits) Not currently used; must be set equal to 0. NUM TP (16 bits) Number of transit policies in a set. NUM VGGRP (16 bits) Number of virtual gateway groups currently associated with the transit policy set. TP (16 bits) Numeric identifier for a transit policy. NUM VG (16 bits) Number of virtual gateways in a virtual gateway group. VG FLGS (8 bits) Set of two flags indicating how to interpret the VG field, contained in the right-most bits. Proceeding left to right, the first flag indicates whether the virtual gateway is a domain entry point (1 entry, 0 not entry). The second flag indicates whether the virtual gateway is a domain exit point (1 exit, 0 not exit). At least one of the first and second flags must be set to 1. NUM CMP (16 bits) Number of adjacent domain components reachable via direct connections through the virtual gateway. ADJ CMP (16 bits) Numeric identifier for a reachable adjacent domain component. 4.3.3. Negative Acknowledgements When a policy gateway or route server receives an unacceptable IDPR routing information message that passes the CMTP validation checks, it includes, in its CMTP ACK, an appropriate negative acknowledgement. This information is placed in the INFORM field of the CMTP ACK (described previously in section 2.4); the numeric identifier for each type of routing information message negative acknowledgement is contained in the left-most 8 bits of the INFORM field. Negative acknowledgements associated with routing information messages include the following types: 1. Unrecognized IDPR routing information message type. Numeric identifier for the unrecognized message type (8 bits). 2. Out-of-date IDPR routing information message. This is a signal to the sender that it may not have the most recent routing information for the given domain. Steenstrup [Page 63] RFC 1479 IDPR Protocol July 1993 5. Route Server Query Protocol Each route server is responsible for maintaining both the routing information database and the route database and for responding to database information requests from policy gateways and other route servers. These requests and their responses are the messages exchanged via the Route Server Query Protocol (RSQP). Policy gateways and route servers normally invoke RSQP to replace absent, outdated, or corrupted information in their own routing information or route databases. In section 4, we discussed some of the situations in which RSQP may be invoked; in this section and in section 7, we discuss other such situations. 5.1. Message Exchange Policy gateways and route servers use CMTP for reliable transport of route server requests and responses. RSQP must communicate to CMTP the maximum number of transmissions per request/response message, rsqp_ret, and the interval between request/response message retransmissions, rsqp_int microseconds. A route server request/response message is "acceptable" if: - It passes the CMTP validation checks. - Its timestamp is less than rsqp_old (300) seconds behind the recipient's internal clock time. With RSQP, a requesting entity expects to receive an acknowledgement from the queried route server indicating whether the route server can accommodate the request. The route server may fail to fill a given request for either of the following reasons: - Its corresponding database contains no entry or only a partial entry for the requested information. - It is governed by special message distribution rules, imposed by the domain administrator, that preclude it from releasing the requested information. Currently, such distribution rules are not included in IDPR configuration information. For all requests that it cannot fill, the route server responds with a negative acknowledgement message carried in a CMTP acknowledgement, indicating the set of unfulfilled requests (see section 5.5.4). If the requesting entity either receives a negative acknowledgement or does not receive any acknowledgement after rsqp_ret attempts directed at the same route server, it queries a different route Steenstrup [Page 64] RFC 1479 IDPR Protocol July 1993 server, as long as the number of attempted requests to different route servers does not exceed rsqp_try (3). Specifically, the requesting entity proceeds in round-robin order through its list of addressable route servers. However, if the requesting entity is unsuccessful after rsqp_try attempts, it abandons the request altogether and logs the event for network management. A policy gateway or a route server can request information from any route server that it can address. Addresses for local route servers within a domain are part of the configuration for each IDPR entity within a domain; addresses for remote route servers in other domains are obtained through flooded CONFIGURATION messages, as described previously in section 4.2.1. However, requesting entities always query local route servers before remote route servers, in order to contain the costs associated with the query and response. If the requesting entity and the queried route server are in the same domain, they can communicate over intra-domain routes, whereas if the requesting entity and the queried route server are in different domains, they must obtain a policy route and establish a path before they can communicate, as we describe below. 5.2. Remote Route Server Communication RSQP communication involving a remote route server requires a policy route and accompanying path setup (see section 7) between the requesting and queried entities, as these entities reside in different domains. After generating a request message, the requesting entity hands to CMTP its request message along with the remote route server's entity and domain identifiers. CMTP encloses the request in a DATAGRAM and hands the DATAGRAM and remote route server information to the path agent. Using the remote route server information, the path agent obtains, and if necessary sets up, a path to the remote route server. Once the path to the remote route server has been successfully established, the path agent encapsulates the DATAGRAM within an IDPR data message and forwards the data message along the designated path. When the path agent in the remote route server receives the IDPR data message, it extracts the DATAGRAM and hands it to CMTP. In addition, the path agent, using the requesting entity and domain identifiers contained in the path identifier, obtains, and if necessary sets up, a path back to the requesting entity. If the DATAGRAM fails any of the CMTP validation checks, CMTP returns a NAK to the requesting entity. If the DATAGRAM passes all of the CMTP validation checks, the remote route server assesses the acceptability of the request message. Provided the request message is acceptable, the remote route server determines whether it can Steenstrup [Page 65] RFC 1479 IDPR Protocol July 1993 fulfill the request and directs CMTP to return an ACK to the requesting entity. The ACK may contain a negative acknowledgement if the entire request cannot be fulfilled. The remote route server generates responses for all requests that it can fulfill and returns the responses to the requesting entity. Specifically, the remote route server hands to CMTP its response and the requesting entity information. CMTP in turn encloses the response in a DATAGRAM. When returning an ACK, a NAK, or a response to the requesting entity, the remote route server hands the corresponding CMTP message and requesting entity information to the path agent. Using the requesting entity information, the path agent retrieves the path to the requesting entity, encapsulates the CMTP message within an IDPR data message, and forwards the data message along the designated path. When the path agent in the requesting entity receives the IDPR data message, it extracts the ACK, NAK, or response to its request and performs the CMTP validation checks for that message. In the case of a response messsage, the requesting entity also assesses message acceptability before incorporating the contents into the appropriate database. 5.3 Routing Information Policy gateways and route servers request routing information from route servers, in order to update their routing information databases. To obtain routing information from a route server, the requesting entity issues a ROUTING INFORMATION REQUEST message containing the type of routing information requested - CONFIGURATION messages, DYNAMIC messages, or both - and the set of domains from which the routing information is requested. Upon receiving a ROUTING INFORMATION REQUEST message, a route server first assesses message acceptability before proceeding to act on the contents. If the ROUTING INFORMATION REQUEST message is deemed acceptable, the route server determines how much of the request it can fulfill and then instructs CMTP to generate an acknowledgement, indicating its ability to fulfill the request. The route server proceeds to fulfill as much of the request as possible by reconstructing individual routing information messages, one per requested message type and domain, from its routing information database. We note that only a regenerated routing information message whose entire contents match that of the original routing information message may pass the CMTP integrity/authentication checks. Steenstrup [Page 66] RFC 1479 IDPR Protocol July 1993 5.4. Routes Path agents request routes from route servers when they require policy routes for path setup. To obtain routes from a route server, the requesting path agent issues a ROUTE REQUEST message containing the destination domain and applicable service requirements, the maximum number of routes requested, a directive indicating whether to generate the routes or retrieve them from the route database, and a directive indicating whether to refresh the routing information database with the most recent CONFIGURATION or DYNAMIC message from a given domain, before generating the routes. To refresh its routing information database, a route server must obtain routing information from another route server. The path agent usually issues routing information database refresh directives in response to a failed path setup. We discuss the application of these directives in more detail in section 7.4. Upon receiving a ROUTE REQUEST message, a route server first assesses message acceptability before proceeding to act on the contents. If the ROUTE REQUEST message is deemed acceptable, the route server determines whether it can fulfill the request and then instructs CMTP to generate an acknowledgement, indicating its ability to fulfill the request. The route server proceeds to fulfill the request with policy routes, either retrieved from its route database or generated from its routing information database if necessary, and returns these routes in a ROUTE RESPONSE message. 5.5. Route Server Message Formats The route server query protocol number is equal to 2. We describe the contents of each type of RSQP message below. 5.5.1. ROUTING INFORMATION REQUEST The ROUTING INFORMATION REQUEST message type is equal to 0. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QRY AD | QRY RS | +-------------------------------+-------------------------------+ | NUM AD | AD | +---------------+---------------+-------------------------------+ | RIM FLGS | UNUSED | +---------------+---------------+ QRY AD (16 bits) Numeric identifier for the domain containing the Steenstrup [Page 67] RFC 1479 IDPR Protocol July 1993 queried route server. QRY RS (16 bits) Numeric identifier for the queried route server. NUM AD (16 bits) Number of domains about which routing information is requested. The value 0 indicates a request for routing information from all domains. AD (16 bits) Numeric identifier for a domain. This field is absent when NUM AD equals 0. RIM FLGS (8 bits) Set of two flags indicating the type of routing information messages requested, contained in the right-most bits. Proceeding left to right, the first flag indicates whether the request is for a CONFIGURATION message (1 CONFIGURATION, 0 no CONFIGURATION). The second flag indicates whether the request is for a DYNAMIC message (1 DYNAMIC, 0 no DYNAMIC). At least one of the first and second flags must be set to 1. UNUSED (8 bits) Not currently used; must be set equal to 0. 5.5.2. ROUTE REQUEST The ROUTE REQUEST message type is equal to 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QRY AD | QRY RS | +-------------------------------+-------------------------------+ | SRC AD | HST SET | +---------------+---------------+-------------------------------+ | UCI | UNUSED | NUM RQS | +---------------+---------------+-------------------------------+ | DST AD | PRX AD | +---------------+---------------+-------------------------------+ | NUM RTS | GEN FLGS | RFS AD | +---------------+---------------+-------------------------------+ | NUM AD | +-------------------------------+ For each domain to be favored, avoided, or excluded: +-------------------------------+---------------+---------------+ | AD | AD FLGS | UNUSED | +-------------------------------+---------------+---------------+ Steenstrup [Page 68] RFC 1479 IDPR Protocol July 1993 For each requested service: +-------------------------------+-------------------------------+ | RQS TYP | RQS LEN | +-------------------------------+-------------------------------+ | RQS SRV | +---------------------------------------------------------------+ QRY AD (16 bits) Numeric identifier for the domain containing the queried route server. QRY RS (16 bits) Numeric identifier for the queried route server. SRC AD (16 bits) Numeric identifier for the route's source domain. HST SET (16 bits) Numeric identifier for the source's host set. UCI (8 bits) Numeric identifier for the source user class. The value 0 indicates that there is no particular source user class. UNUSED (8 bits) Not currently used; must be set equal to 0. NUM RQS (16 bits) Number of requested services. The value 0 indicates that the source requests no special services. DST AD (16 bits) Numeric identifier for the route's destination domain. PRX AD (16 bits) Numeric identifier for the destination domain's proxy (see section 1.3.1). If the destination domain provides the path agent function for its hosts, then the destination and proxy domains are identical. A route server constructs routes between the source domain's proxy and the destination domain's proxy. We note that the source domain's proxy is identical to the domain issuing the CMTP message containing the ROUTE REQUEST message, and hence available in the CMTP header. NUM RTS (8 bits) Number of policy routes requested. GEN FLGS (8 bits) Set of three flags indicating how to obtain the requested routes, contained in the right-most bits. Proceeding left to right, the first flag indicates whether the route server should retrieve existing routes from its route database or generate new routes (1 retrieve, 0 generate). The second flag indicates whether the route server should refresh its routing information database before generating the requested routes (1 refresh, 0 no refresh) and when set to 1, causes the third flag and the RFS AD field to become significant. The third flag Steenstrup [Page 69] RFC 1479 IDPR Protocol July 1993 indicates whether the routing information database refresh should include CONFIGURATION messages or DYNAMIC messages (1 configuration, 0 dynamic). RFS AD (16 bits) Numeric identifier for the domain for which routing information should be refreshed. This field is meaningful only if the second flag in the GEN FLGS field is set to 1. NUM AD (16 bits) Number of transit domains that are to be favored, avoided, or excluded during route selection (see section 1.4.1). AD (16 bits) Numeric identifier for a transit domain to be favored, avoided, or excluded. AD FLGS (8 bits) Three flags indicating how to interpret the AD field, contained in the right-most bits. Proceeding left to right, the first flag indicates whether the domain should be favored (1 favored, 0 not favored). The second flag indicates whether the domain should be avoided (1 avoided, 0 not avoided). The third flag indicates whether the domain should be excluded (1 excluded, 0 not excluded). No more than one of the first, second, and third flags must set to 1. RQS TYP (16 bits) Numeric identifier for a type of requested service. Valid requested services include the following types: 1. Upper bound on delay, in milliseconds (16 bits). This attribute may be omitted. 2. Minimum delay route. This attribute may be omitted. 3. Upper bound on delay variation, in milliseconds (16 bits). This attribute may be omitted. 4. Minimum delay variation route. This attribute may be omitted. 5. Lower bound on bandwidth, in bits per second (48 bits). This attribute may be omitted. 6. Maximum bandwidth route. This attribute may be omitted. 7. Upper bound on monetary cost, in cents (32 bits). This attribute may be omitted. 8. Minimum monetary cost route. This attribute may be omitted. 9. Path lifetime in minutes (16 bits). This attribute may be omitted but must be present if types 7 or 8 are present. Route servers Steenstrup [Page 70] RFC 1479 IDPR Protocol July 1993 use path lifetime information together with domain charging method to compute expected session monetary cost over a given domain. 10. Path lifetime in messages (16 bits). This attribute may be omitted but must be present if types 7 or 8 are present. 11. Path lifetime in bytes (48 bits). This attribute may be omitted but must be present if types 7 or 8 are present. RQS LEN (16 bits) Length of the requested service, in bytes, beginning with the next field. RQS SRV (variable) Description of the requested service. 5.5.3. ROUTE RESPONSE The ROUTE RESPONSE message type is equal to 2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NUM RTS | +---------------+ For each route provided: +---------------+---------------+ | NUM AD | RTE FLGS | +---------------+---------------+ For each domain in the route: +---------------+---------------+-------------------------------+ | AD LEN | VG | ADJ AD | +---------------+---------------+-------------------------------+ | ADJ CMP | NUM TP | +-------------------------------+-------------------------------+ | TP | +-------------------------------+ NUM RTS (16 bits) Number of policy routes provided. RTE FLGS (8 bits) Set of two flags indicating the directions in which a route can be used, contained in the right-most bits. Refer to sections 6.2, 7, and 7.2 for detailed discussions of path directionality. Proceeding left to right, the first flag indicates whether the route can be used from source to destination (1 from source, 0 not from source). The second flag Steenstrup [Page 71] RFC 1479 IDPR Protocol July 1993 indicates whether the route can be used from destination to source (1 from destination, 0 not from destination). At least one of the first and second flags must be set to 1, if NUM RTS is greater than 0. NUM AD (8 bits) Number of domains in the policy route, not including the first domain on the route. AD LEN (8 bits) Length of the information associated with a particular domain, in bytes, beginning with the next field. VG (8 bits) Numeric identifier for an exit virtual gateway. ADJ AD (16 bits) Numeric identifier for the adjacent domain connected to the virtual gateway. ADJ CMP (16 bits) Numeric identifier for the adjacent domain component. Used by policy gateways to select a route across a virtual gateway connecting to a partitioned domain. NUM TP (16 bits) Number of transit policies that apply to the section of the route traversing the domain component. TP (16 bits) Numeric identifier for a transit policy. 5.5.4. Negative Acknowledgements When a policy gateway receives an unacceptable RSQP message that passes the CMTP validation checks, it includes, in its CMTP ACK, an appropriate negative acknowledgement. This information is placed in the INFORM field of the CMTP ACK (described previously in section 2.4); the numeric identifier for each type of RSQP negative acknowledgement is contained in the left-most 8 bits of the INFORM field. Negative acknowledgements associated with RSQP include the following types: 1. Unrecognized RSQP message type. Numeric identifier for the unrecognized message type (8 bits). 2. Out-of-date RSQP message. 3. Unable to fill requests for routing information from the following domains. Number of domains for which requests cannot be filled (16 bits); a value of 0 indicates that the route server cannot fill any of the requests. Numeric identifier for each domain for which a request cannot be filled (16 bits). Steenstrup [Page 72] RFC 1479 IDPR Protocol July 1993 4. Unable to fill requests for routes to the following destination domain. Numeric identifier for the destination domain (16 bits). 6. Route Generation Route generation is the most computationally complex part of IDPR, because of the number of domains and the number and heterogeneity of policies that it must accommodate. Route servers must generate policy routes that satisfy the requested services of the source domains and respect the offered services of the transit domains. We distinguish requested qualities of service and route generation with respect to them as follows: - Requested service limits include upper bounds on route delay, route delay variation, and session monetary cost and lower bounds on available route bandwidth. Generating a route that must satisfy more than one quality of service constraint, for example route delay of no more than X seconds and available route bandwidth of no less than Y bits per second, is an NP-complete problem. - Optimal requested services include minimum route delay, minimum route delay variation, minimum session monetary cost, and maximum available route bandwidth. In the worst case, the computational complexity of generating a route that is optimal with respect to a given requested service is O((N + L) log N) for Dijkstra's shortest path first (SPF) search and O(N + (L * L)) for breadth-first (BF) search, where N is the number of nodes and L is the number of links in the search graph. Multi-criteria optimization, for example finding a route with minimal delay variation and minimal session monetary cost, may be defined in several ways. One approach to multi-criteria optimization is to assign each link a single value equal to a weighted sum of the values of the individual offered qualities of service and generate a route that is optimal with respect to this new criterion. However, selecting the weights that yield the desired route generation behavior is itself an optimization procedure and hence not trivial. To help contain the combinatorial explosion of processing and memory costs associated with route generation, we supply the following guidelines for generation of suitable policy routes: - Each route server should only generate policy routes from the perspective of its own domain as source; it need not generate policy routes for arbitrary source/destination domain pairs. Thus, we can distribute the computational burden over all route servers. - Route servers should precompute routes for which they anticipate Steenstrup [Page 73] RFC 1479 IDPR Protocol July 1993 requests and should generate routes on demand only in order to satisfy unanticipated route requests. Hence, a single route server can distribute its computational burden over time. - Route servers should cache the results of route generation, in order to minimize the computation associated with responding to future route requests. - To handle requested service limits, a route server should always select the first route generated that satisfies all of the requested service limits. - To handle multi-criteria optimization in route selection, a route server should generate routes that are optimal with respect to the first optimal requested service listed in the ROUTE REQUEST message. The route server should resolve ties between otherwise equivalent routes by evaluating these routes according to the other optimal requested services contained in the ROUTE REQUEST message, in the order in which they are listed. With respect to the route server's routing information database, the selected route is optimal according to the first optimal requested service listed in the ROUTE REQUEST message but is not necessarily optimal according to any other optimal requested service listed in the ROUTE REQUEST message. ti 2 - To handle a mixture of requested service limits and optimal requested services, a route server should generate routes that satisfy all of the requested service limits. The route server should resolve ties between otherwise equivalent routes by evaluating these routes as described in the multi-criteria optimization case above. ti 2 - All else being equal, a route server should always prefer minimum-hop routes, because they minimize the amount of network resources consumed by the routes. ti 2 - A route server should generate at least one route to each component of a partitioned destination domain, because it may not know in which domain component the destination host resides. Hence, a route server can maximize the chances of providing a feasible route to a destination within a partitioned domain. 6.1 Searching All domains need not execute the identical route generation procedure. Each domain administrator is free to specify the IDPR route generation procedure for route servers in its own domain, making the procedure as simple or as complex as desired. Steenstrup [Page 74] RFC 1479 IDPR Protocol July 1993 We offer an IDPR route generation procedure as a model. With slight modification, this procedure can be made to search in either BF or SPF order. The procedure can be used either to generate a single policy route from the source to a specified destination domain or to generate a set of policy routes from the source domain to all destination domains. If the source or destination domain has a proxy, then the source or destination endpoint of the policy route is a proxy domain and not the actual source or destination domain. For high-bandwidth traffic flows, BF search is the recommended search technique, because it produces minimum-hop routes. For low- bandwidth traffic flows, the route server may use either BF search or SPF search. The computational complexity of BF search is O(N + L) and hence it is the search procedure of choice, except when generating routes with optimal requested services. We recommend using SPF search only for optimal requested services and never in response to a request for a maximum bandwidth route. 6.1.1. Implementation Data Structures: The routing information database contains the graph of an internetwork, in which virtual gateways are the nodes and intra- domain routes between virtual gateways are the links. During route generation, each route is represented as a sequence of virtual gateways, domains, and relevant transit policies, together with a list of route characteristics, stored in a temporary array and indexed by destination domain. - Execute the Policy Consistency routine, first with the source domain the given domain and second with the destination domain as the given domain. If any policy inconsistency precludes the requested traffic flow, go to Exit. - For each domain, initialize a null route, set the route bandwidth to and set the following route characteristics to infinity: route delay, route delay variation, session monetary cost, and route length in hops. - With each operational virtual gateway in the source or source proxy domain, associate the initial route characteristics. - Initialize a next-node data structure which will contain, for each route in progress, the virtual gateway at the current endpoint of the route together with the associated route characteristics. The next-node data structure determines the order in which routes get expanded. Steenstrup [Page 75] RFC 1479 IDPR Protocol July 1993 BF: A fifo queue. SPF: A heap, ordered according to the first optimal requested service listed in the ROUTE REQUEST message. Remove Next Node: These steps are performed for each virtual gateway in the next-node data structure. - If there are no more virtual gateways in the next-node data structure, go to Exit. - Extract a virtual gateway and its associated route characteristics from the next-node data structure, obtain the adjacent domain, and: SPF: Remake the heap. - If there is a specific destination domain and if for the primary optimal service: BF: Route length in hops. SPF: First optimal requested service listed in the ROUTE REQUEST message. the extracted virtual gateway's associated route characteristic is no better than that of the destination domain, go to Remove Next Node. - Execute the Policy Consistency routine with the adjacent domain as given domain. If any policy inconsistency precludes the requested traffic flow, go to Remove Next Node. - Check that the source domain's transit policies do not preclude traffic generated by members of the source host set with the specified user class and requested services, from flowing to the adjacent domain as destination. This check is necessary because the route server caches what it considers to be all feasible routes, to intermediate destination domains, generated during the computation of the requested route. If there are no policy inconsistencies, associate the route and its characteristics with the adjacent domain as destination. - If there is a specific destination domain and if the adjacent domain is the destination or destination proxy domain, go to Remove Next Node. - Record the set of all exit virtual gateways in the adjacent Steenstrup [Page 76] RFC 1479 IDPR Protocol July 1993 domain which the adjacent domain's transit policies permit the requested traffic flow and which are currently reachable from the entry virtual gateway. Next Node: These steps are performed for all exit virtual gateways in the above set. - If there are no exit virtual gateways in the set, go to Remove Next Node. - Compute the characteristics for the route to the exit virtual gateway, and check that all of the route characteristics are within the requested service limits. If any of the route characteristics are outside of these limits, go to Next Node. - Compare these route characteristics with those already associated with the exit virtual gateway (there may be none, if this is the first time the exit virtual gateway has been visited in the search), according to the primary optimal service. - Select the route with the optimal value of the primary optimal service, resolve ties by considering optimality according to any other optimal requested services in the order in which they are listed in the ROUTE REQUEST message, and associate the selected route and its characteristics with the exit virtual gateway. - Add the virtual gateway to the next-node structure: BF: Add to the end of the fifo queue. SPF: Add to the heap. and go to Next Node. Exit: Return a response to the route request, consisting of either a set of candidate policy routes or an indication that the route request cannot be fulfilled. Policy Consistency: Check policy consistency for the given domain. - Check that the given domain is not specified as an excluded domain in the route request. - Check that the given domain's transit policies do not preclude traffic generated by members of the source host set with the Steenstrup [Page 77] RFC 1479 IDPR Protocol July 1993 specified user class and requested services, from flowing to the destination domain. During the computation of the requested routes, a route server also caches what it considers to be all feasible routes to intermediate destination domains, thus increasing the chances of being able to respond to a future route request without having to generate a new route. The route server does perform some policy consistency checks on the routes, as they are generated, to intermediate destinations. However, these routes may not in fact be feasible; the transit domains contained on the routes may not permit traffic between the source and the given intermediate destinations. Hence, before dispensing such a route in response to a route request, a route server must check that the transit policies of the constituent domains are consistent with the source and destination of the traffic flow. 6.2. Route Directionality A path agent may wish to set up a bidirectional path using a route supplied by a route server. (Refer to sections 7.2 and 7.4 for detailed discussions of path directionality.) However, a route server can only guarantee that the routes it supplies are feasible if used in the direction from source to destination. The reason is that the route server, which resides in the source or source proxy domain, does not have access to, and thus cannot account for, the source policies of the destination domain. Nevertheless, the route server can provide the path agent with an indication of its assessment of route feasibility in the direction from destination to source. A necessary but insufficient condition for a route to be feasible in the direction from destination to source is as follows. The route must be consistent, in the direction from destination to source, with the transit policies of the domains that compose the route. The transit policy consistency checks performed by the route server during route generation account for the direction from source to destination but not for the direction from destination to source. Only after a route server generates a feasible route from source to destination does it perform the transit policy consistency checks for the route in the direction from destination to source. Following these checks, the route server includes in its ROUTE RESPONSE message to the path agent an indication of its assessment of route feasibility in each direction. Steenstrup [Page 78] RFC 1479 IDPR Protocol July 1993 6.3. Route Database A policy route, as originally specified by a route server, is an ordered list of virtual gateways, domains, and transit policies: VG 1 - AD 1 - TP 1 - ... - VG n - AD n - TP n. where VG i is the virtual gateway that serves as exit from AD i-1 and entry to AD i, and TP i is the set of transit policies associated with AD i and relevant to the particular route. Each route is indexed by source and destination domain. Route servers and paths agents store policy routes in route databases maintained as caches whose entries must be periodically flushed to avoid retention of stale policy routes. A route server's route database is the set of all routes it has generated on behalf of its domain as source or source proxy; associated with each route in the database are its route characteristics. A path agent's route database is the set of all routes it has requested and received from route servers on behalf of hosts for which it is configured to act. When attempting to locate a feasible route for a traffic flow, a path agent first consults its own route database before querying a route server. If the path agent's route database contains one or more routes between the given source and destination domains and accommodating the given host set and UCI, then the path agent checks each such route against the set of excluded domains listed in the source policy. The path agent either selects the first route encountered that does not include the excluded domains, or, if no such route exists in its route database, requests a route from a route server. A path agent must query a route server for routes when it is unable to fulfill a route request from its own route database. Moreover, we recommend that a path agent automatically forward to a route server, all route requests with non-null requested services. The reason is that the path agent retains no route characteristics in its route database. Hence, the path agent cannot determine whether an entry in its route database satisfies the requested services. When responding to a path agent's request for a policy route, a route server first consults its route database, unless the ROUTE REQUEST message contains an explicit directive to generate a new route. If its route database contains one or more routes between the given source and destination domains and accommodating the given host set and UCI, the route server checks each such route against the set of excluded domains listed in the ROUTE REQUEST message. The route server either selects all routes encountered that do not include the excluded domains, or, if no such route exists in its route database, attempts to generate such a route. Once the route server selects a set of routes, it then checks each such route against the services Steenstrup [Page 79] RFC 1479 IDPR Protocol July 1993 requested by the path agent and the services offered by the domains composing the route. To obtain the offered services information, the route server consults its routing information database. The route server either selects the first route encountered that is consistent with both the requested and offered services, or, if no such route exists in its route database, attempts to generate such a route. 6.3.1. Cache Maintenance Each route stored in a route database has a maximum cache lifetime equal to rdb_rs minutes for a route server and rdb_ps minutes for a path agent. Route servers and path agents reclaim cache space by flushing entries that have attained their maximum lifetimes. Moreover, paths agents reclaim cache space for routes whose paths have failed to be set up successfully or have been torn down (see section 7.4). Nevertheless, cache space may become scarce, even with reclamation of entries. If a cache fills, the route server or path agent logs the event for network management. To obtain space in the cache when the cache is full, the route server or path agent deletes from the cache the oldest entry. 7. Path Control Protocol and Data Message Forwarding Procedure Two entities in different domains may exchange IDPR data messages, only if there exists an IDPR path set up between the two domains. Path setup requires cooperation among path agents and intermediate policy gateways. Path agents locate policy routes, initiate the Path Control Protocol (PCP), and manage existing paths between administrative domains. Intermediate policy gateways verify that a given policy route is consistent with their domains' transit policies, establish the forwarding information, and forward messages along existing paths. Each policy gateway and each route server contains a path agent. The path agent that initiates path setup in the source or source proxy domain is the "originator", and the path agent that handles the originator's path setup message in the destination or destination proxy domain is the "target". Every path has two possible directions of traffic flow: from originator to target and from target to originator. Path control messages are free to travel in either direction, but data messages may be restricted to only one direction. Once a path for a policy route is set up, its physical realization is a set of consecutive policy gateways, with policy gateways or route servers forming the endpoints. Two successive entities in this set belong to either the same domain or the same virtual gateway. A Steenstrup [Page 80] RFC 1479 IDPR Protocol July 1993 policy gateway or route server may, at any time, recover the resources dedicated to a path that goes through it by tearing down that path. For example, a policy gateway may decide to tear down a path that has not been used for some period of time. PCP may build multiple paths between source and destination domains, but it is not responsible for managing such paths as a group or for eliminating redundant paths. 7.1. An Example of Path Setup We illustrate how path setup works by stepping through an example. Suppose host Hx in domain AD X wants to communicate with host Hy in domain AD Y and that both AD X and AD Y support IDPR. Hx need not know the identity of its own domain or of Hy's domain in order to send messages to Hy. Instead, Hx simply forwards a message bound for Hy to one of the gateways on its local network, according to its local forwarding information only. If the recipient gateway is a policy gateway, the resident path agent determines how to forward the message outside of the domain. Otherwise, the recipient gateway forwards the message to another gateway in AD X, according to its local forwading information. Eventually, the message will arrive at a policy gateway in AD X, as policy gateways are the only egress points to other domains, in domains that support IDPR. The path agent resident in the recipient policy gateway uses the message header, including source and destination addresses and any requested service information (for example, type of service), in order to determine whether it is an intra-domain or inter-domain message, and if inter-domain, whether it requires an IDPR policy route. Specifically, the path agent attempts to locate a forwarding information database entry for the given traffic flow, from the information contained in the message header. In the future, for IP messages, the relevant header information may also include special service-specific IP options or even information from higher layer protocols. Forwarding database entries exist for all of the following: - All intra-domain traffic flows. Intra-domain forwarding information is integrated into the forwarding information database as soon as it is received. - Inter-domain traffic flows that do not require IDPR policy routes. Non-IDPR forwarding information is integrated into the forwarding database as soon as it is received. - IDPR inter-domain traffic flows for which a path has already been Steenstrup [Page 81] RFC 1479 IDPR Protocol July 1993 set up. IDPR forwarding information is integrated into the forwarding database only during path setup. The path agent uses the message header contents to guide the search for a forwarding information database entry for a given traffic flow. We recommend a radix search to locate such an entry. When the search terminates, it produces either an entry, or, in the case of a new IDPR traffic flow, a directive to generate an entry. If the search terminates in an existing forwarding information database entry, the path agent forwards the message according to that entry. Suppose that the search terminates indicating that the traffic flow from Hx to Hy requires an IDPR policy route and that no entry in the forwarding information database yet exists for that traffic flow. In this case, the path agent first determines the source and destination domains associated with the message's source and destination addresses, before attempting to obtain a policy route. The path agent relies on the mapping servers to supply the domain information, but it caches all mapping server responses locally to limit the number of future queries. When attempting to resolve an address to a domain, the path agent always checks its local cache before contacting a mapping server. After obtaining the domain information, the path agent attempts to obtain a policy route to carry the traffic from Hx to Hy. The path agent relies on route servers to supply policy routes, but it caches all route server responses locally to limit the number of future queries. When attempting to locate a suitable policy route, the path agent usually consults its local cache before contacting a route server, as described previously in section 6.3. If no suitable cache entry exists, the path agent queries the route server, providing it with the source and destination domains together with source policy information carried in the host message or specified through configuration. Upon receiving a policy route query, a route server consults its route database. If it cannot locate a suitable route in its route database, the route server attempts to generate at least one route to AD Y, consistent with the requested services for Hx. The route server always returns a response to the path agent, regardless of whether it is successful in locating a suitable policy route. The response to a successful route query consists of a set of candidate routes, from which the path agent makes its selection. We expect that a path agent will normally choose a single route from a candidate set. Nevertheless, IDPR does not preclude a path agent from selecting multiple routes from the candidate set. A path agent may desire multiple routes to support features such as fault Steenstrup [Page 82] RFC 1479 IDPR Protocol July 1993 tolerance or load balancing; however, IDPR does not currently specify how the path agent should use multiple routes. If the policy route is a new route provided by the route server, there will be no existing path for the route, and thus the path agent must set up such a path. However, if the policy route is an existing route extracted from the path agent's cache, there may well be an existing path for the route, set up to accommodate a host traffic flow. IDPR permits multiple traffic flows to use the same path, provided that all traffic flows sharing the path travel between the same endpoint domains and have the same service requirements. Nevertheless, IDPR does not preclude a path agent from setting up distinct paths along the same policy route to preserve the distinction between host traffic flows. The path agent associates an identifier with the path, which is included in each message that travels down the path and is used by the policy gateways along the path in order to determine how to forward the message. If the path already exists, the path agent uses the preexisting identifier. However, for new paths, the path agent chooses a path identifier that is different from those of all other paths that it manages. The path agent also updates its forwarding information database to reference the path identifier and modifies its search procedure to yield the correct entry in the forwarding information database given the data message header. For new paths, the path agent initiates path setup, communicating the policy route, in terms of requested services, constituent domains, relevant transit policies, and the connecting virtual gateways, to policy gateways in intermediate domains. Using this information, an intermediate policy gateway determines whether to accept or refuse the path and to which next policy gateway to forward the path setup information. The path setup procedure allows policy gateways to set up a path in both directions simultaneously. Each intermediate policy gateway, after path acceptance, updates its forwarding information database to include an entry that associates the path identifier with the appropriate previous and next hop policy gateways. When a policy gateway in AD Y accepts a path, it notifies the source path agent in AD X. We expect that the source path agent will normally wait until a path has been successfully established before using it to transport data traffic. However, PCP does not preclude a path agent from forwarding messages along a path prior to confirmation of successful path establishment. Paths remain in place until they are torn down because of failure, expiration, or when resources are scarce, preemption in favor of other paths. Steenstrup [Page 83] RFC 1479 IDPR Protocol July 1993 We note that data communication between Hx and Hy may occur over two separate IDPR paths: one from AD X to AD Y and one from AD Y to AD X. The reasons are that within a domain, hosts know nothing about path agents nor IDPR paths, and path agents know nothing about other path agents' existing IDPR paths. Thus, in AD Y, the path agent that terminates the path from AD X may not be the same as the path agent that receives traffic from Hy destined for Hx. In this case, receipt of traffic from Hy forces the second path agent to set up an independent path from AD Y to AD X. 7.2. Path Identifiers Each path has an associated path identifier, unique throughout an internetwork. Every IDPR data message travelling along that path includes the path identifier, used for message forwarding. The path identifier is the concatenation of three items: the identifier of the originator's domain, the identifier of the originator's policy gateway or route server, and a 32-bit local path identifier specified by the originator. The path identifier and the CMTP transaction identifier have analogous syntax and play analogous roles in their respective protocols. When issuing a new path identifier, the originator always assigns a local path identifier that is different from that of any other active or recently torn-down path originally set up by that path agent. This helps to distinguish new paths from replays. Hence, the originator must keep a record of each extinct path for long enough that all policy gateways on the path will have eliminated any reference to it from their memories. The right-most 30 bits of the local identifier are the same for each path direction, as they are assigned by the originator. The left-most 2 bits of the local identifier indicate the path direction. At path setup time, the originator specifies which of the path directions to enable contingent upon the information received from the route server in the ROUTE RESPONSE message. By "enable", we mean that each path agent and each intermediate policy gateway establishes an association between the path identifier and the previous and next policy gateways on the path, which it uses for forwarding data messages along that path. IDPR data messages may travel in the enabled path directions only, but path control messages are always free to travel in either path direction. The originator may enable neither path direction, if the entire data transaction can be carried in the path setup message itself. In this case, the path agents and the intermediate policy gateways do not establish forwarding associations for the path, but they do verify consistency of the policy information contained in the path setup message, with their own transit policies, before forwarding the setup message on to the Steenstrup [Page 84] RFC 1479 IDPR Protocol July 1993 next policy gateway. The path direction portion of the local path identifier has different interpretations, depending upon message type. In an IDPR path setup message, the path direction indicates the directions in which the path should be enabled: the value 01 denotes originator to target, the value 10 denotes target to originator, the value 11 denotes both directions, and the value 00 denotes neither direction. Each policy gateway along the path interprets the path direction in the setup message and sets up the forwarding information as directed. In an IDPR data message, the path direction indicates the current direction of traffic flow: either 01 for originator to target or 10 for target to originator. Thus, if for example, an originator sets up a path enabling only the direction from target to originator, the target sends data messages containing the path identifier selected by the originator together with the path direction set equal to 10. Instead of using path identifiers that are unique throughout an internetwork, we could have used path identifiers that are unique only between a pair of consecutive policy gateways and that change from one policy gateway pair to the next. The advantage of locally unique path identifiers is that they may be much shorter than globally unique identifiers and hence consume less transmission bandwidth. However, the disadvantage is that the path identifier carried in each IDPR data message must be modified at each policy gateway, and hence if the integrity/authentication information covers the path identifier, it must be recomputed at each policy gateway. For security reasons, we have chosen to include the path identifier in the set of information covered by the integrity/authentication value, and moreover, we advocate public-key based signatures for authentication. Thus, it is not possible for intermediate policy gateways to modify the path identifier and then recompute the correct integrity/authentication value. Therefore, we have decided in favor of path identifiers that do not change from hop to hop and hence must be globally unique. To speed forwarding of IDPR data messages with long path identifiers, policy gateways should hash the path identifiers in order to index IDPR forwarding information. 7.3. Path Control Messages Messages exchanged by the path control protocol are classified into "requests": SETUP, TEARDOWN, REPAIR; and "responses": ACCEPT, REFUSE, ERROR. These messages have significance for intermediate policy gateways as well as for path agents. SETUP: Establishes a path by linking together pairs of policy gateways. The SETUP message is generated by the originator and propagates Steenstrup [Page 85] RFC 1479 IDPR Protocol July 1993 to the target. In response to a SETUP message, the originator expects to receive an ACCEPT, REFUSE, or ERROR message. The SETUP message carries all information necessary to set up the path including path identifier, requested services, transit policy information relating to each domain traversed, and optionally, expedited data. ACCEPT: Signals successful path establishment. The ACCEPT message is generated by the target, in response to a SETUP message, and propagates back to the originator. Reception of an ACCEPT message by the originator indicates that the originator can now safely proceed to send data along the path. The ACCEPT message contains the path identifier and an optional reason for conditional acceptance. REFUSE: Signals that the path could not be successfully established, either because resources were not available or because there was an inconsistency between the services requested by the source and the services offered by a transit domain along the path. The REFUSE message is generated by the target or by any intermediate policy gateway, in response to a SETUP message, and propagates back to the originator. All recipients of a REFUSE message recover the resources dedicated to the given path. The REFUSE message contains the path identifier and the reason for path refusal. TEARDOWN: Tears down a path, typically when a non-recoverable failure is detected. The TEARDOWN message may be generated by any path agent or policy gateway in the path and usually propagates in both path directions. All recipients of a TEARDOWN message recover the resources dedicated to the given path. The TEARDOWN message contains the path identifier and the reason for path teardown. REPAIR: Establishes a repaired path by linking together pairs of policy gateways. The REPAIR message is generated by a policy gateway after detecting that the next policy gateway on one of its existing paths is unreachable. A policy gateway that generates a REPAIR message propagates the message forward at most one virtual gateway. In response to a REPAIR message, the policy gateway expects to receive an ACCEPT, REFUSE, TEARDOWN, or ERROR message. The REPAIR message carries the original SETUP message. ERROR: Transports information about a path error back to the originator, when a PCP message contains unrecognized information. The ERROR message may be generated by the target or by any intermediate policy gateway and propagates back to the Steenstrup [Page 86] RFC 1479 IDPR Protocol July 1993 originator. Most, but not all, ERROR messages are generated in response to errors encountered during path setup. The ERROR message includes the path identifier and an explanation of the error detected. Policy gateways use CMTP for reliable transport of PCP messages, between path agents and policy gateways and between consecutive policy gateways on a path. PCP must communicate to CMTP the maximum number of transmissions per path control message, pcp_ret, and the interval between path contol message retransmissions, pcp_int microseconds. All path control messages, except ERROR messages, may be transmitted up to pcp_ret times; ERROR messages are never retransmitted. A path control message is "acceptable" if: - It passes the CMTP validation checks. - Its timestamp is less than pcp_old (300) seconds behind the recipient's internal clock time. - It carries a recognized path identifier, provided it is not a SETUP message. An intermediate policy gateway on a path forwards acceptable PCP messages. As we describe in section 7.4 below, SETUP messages must undergo additional tests at each intermediate policy gateway prior to forwarding. Moreover, receipt of an acceptable ACCEPT, REFUSE, TEARDOWN, or ERROR message at either path agent or at any intermediate policy gateway indirectly cancels any active local CMTP retransmissions of the original SETUP message. When a path agent or intermediate policy gateway receives an unacceptable path control message, it discards the message and logs the event for network management. The path control message age limit reduces the likelihood of denial of service attacks based on message replay. 7.4. Setting Up and Tearing Down a Path Path setup begins when the originator generates a SETUP message containing: - The path identifier, including path directions to enable. - An indication of whether the message includes expedited data. - The source user class identifier. - The requested services (see section 5.5.2) and source-specific information (see section 7.6.1) for the path. Steenstrup [Page 87] RFC 1479 IDPR Protocol July 1993 - For each domain on the path, the domain component, applicable transit policies, and entry and exit virtual gateways. The only mandatory requested service is the maximum path lifetime, pth_lif, and the only mandatory source-specific information is the data message integrity/authentication type. If these are not specified in the path setup message, each recipient policy gateway assigns them default values, (60) minutes for pth_lif and no authentication for integrity/authentication type. Each path agent and intermediate policy gateway tears down a path when the path lifetime is exceeded. Hence, no single source can indefinitely monopolize policy gateway resources or still functioning parts of partially broken paths. After generating the SETUP message and establishing the proper local forwarding information, the originator selects the next policy gateway on the path and forwards the SETUP message to the selected policy gateway. The next policy gateway selection procedure, described below, applies when either the originator or an intermediate policy gateway is making the selection. We have elected to describe the procedure from the perspective of a selecting intermediate policy gateway. The policy gateway selects the next policy gateway on a path, in round-robin order from its list of policy gateways contained in the present or next virtual gateway, as explained below. In selecting the next policy gateway, the policy gateway uses information contained in the SETUP message and information provided by VGP and by the intra-domain routing procedure. If the selecting policy gateway is a domain entry point, the next policy gateway must be: - A member of the next virtual gateway listed in the SETUP message. - Reachable according to intra-domain routes supporting the transit policies listed in the SETUP message. - Able to reach, according to VGP, the next domain component listed in the SETUP message. In addition, the selecting policy gateway may use quality of service information supplied by intra-domain routing to resolve ties between otherwise equivalent next policy gateways in the same domain. In particular, the selecting policy gateway may select the next policy gateway whose connecting intra-domain route is optimal according to the requested services listed in the SETUP message. Steenstrup [Page 88] RFC 1479 IDPR Protocol July 1993 If the selecting policy gateway is a domain exit point, the next policy gateway must be: - A member of the current virtual gateway listed in the SETUP message (which is also the selecting policy gateway's virtual gateway). - Reachable according to VGP. - A member of the next domain component listed in the SETUP message. Once the originator or intermediate policy gateway selects a next policy gateway, it forwards the SETUP message to the selected policy gateway. Each recipient (policy gateway or target) of an acceptable SETUP message performs several checks on the contents of the message, in order to determine whether to establish or reject the path. We describe these checks in detail below from the perspective of a policy gateway as SETUP message recipient. 7.4.1. Validating Path Identifiers The recipient of a SETUP message first checks the path identifier, to make sure that it does not correspond to that of an already existing or recently extinct path. To detect replays, malicious or otherwise, path agents and policy gateways maintain a record of each path that they establish, for max{pth_lif, pcp_old} seconds. If the path identifier and timestamp carried in the SETUP message match a stored path identifier and timestamp, the policy gateway considers the message to be a retransmission and does not forward the message. If the path identifier carried in the SETUP message matches a stored path identifier but the two timestamps do not agree, the policy gateway abandons path setup, logs the event for network management, and returns an ERROR message to the originator via the previous policy gateway. 7.4.2. Path Consistency with Configured Transit Policies Provided the path identifier in the SETUP message appears to be new, the policy gateway proceeds to determine whether the information contained within the SETUP message is consistent with the transit policies configured for its domain. The policy gateway must locate the source and destination domains, the source host set and user class identifier, and the domain-specific information for its own domain, within the SETUP message, in order to evaluate path consistency. If the policy gateway fails to recognize the source user class (or one or more of the requested services), it logs the event for network management but continues with path setup. If the policy gateway fails to locate its domain within the SETUP message, it abandons path setup, logs the event for network management, and Steenstrup [Page 89] RFC 1479 IDPR Protocol July 1993 returns an ERROR message to the originator via the previous policy gateway. The originator responds by tearing down the path and subsequently removing the route from its cache. Once the policy gateway locates its domain-specific portion of the SETUP message, it may encounter the following problems with the contents: - The domain-specific portion lists a transit policy not configured for the domain. - The domain-specific portion lists a virtual gateway not configured for the domain. In each case, the policy gateway abandons path setup, logs the event for network management, and returns an ERROR message to the originator via the previous policy gateway. These types of ERROR messages indicate to the originator that the route may have been generated using information from an out-of-date CONFIGURATION message. The originator reacts to the receipt of such an ERROR message as follows. First, it tears down the path and removes the route from its cache. Then, it issues to a route server a ROUTE REQUEST message containing a directive to refresh the routing information database, with the most recent CONFIGURATION message from the domain that issued the ERROR message, before generating a new route. Once it verifies that its domain-specific information in the SETUP message is recognizable, the policy gateway then checks that the information contained within the SETUP message is consistent with the transit policies configured for its domain. A policy gateway at the entry to a domain checks path consistency in the direction from originator to target, if the enabled path directions include originator to target. A policy gateway at the exit to a domain checks path consistency in the direction from target to originator, if the enabled path directions include target to originator. When evaluating the consistency of the path with the transit policies configured for the domain, the policy gateway may encounter any of the following problems with SETUP message contents: - A transit policy does not apply in the given direction between the virtual gateways listed in the SETUP message. - A transit policy denies access to traffic from the given host set between the source and destination domains listed in the SETUP message. Steenstrup [Page 90] RFC 1479 IDPR Protocol July 1993 - A transit policy denies access to traffic from the source user class listed in the SETUP message. - A transit policy denies access to traffic at the current time. In each case, the policy gateway abandons path setup, logs the event for network management, and returns a REFUSE message to the originator via the previous policy gateway. These types of REFUSE messages indicate to the originator that the route may have been generated using information from an out-of-date CONFIGURATION message. The REFUSE message also serves to teardown the path. The originator reacts to the receipt of such a REFUSE message as follows. First, it removes the route from its cache. Then, it issues to a route server a ROUTE REQUEST message containing a directive to refresh the routing information database, with the most recent CONFIGURATION message from the domain that issued the REFUSE message, before generating a new route. 7.4.3. Path Consistency with Virtual Gateway Reachability Provided the information contained in the SETUP message is consistent with the transit policies configured for its domain, the policy gateway proceeds to determine whether the path is consistent with the reachability of the virtual gateway containing the potential next hop. To determine virtual gateway reachability, the policy gateway uses information provided by VGP and by the intra-domain routing procedure. When evaluating the consistency of the path with virtual gateway reachability, the policy gateway may encounter any of the following problems: - The virtual gateway containing the potential next hop is down. - The virtual gateway containing the potential next hop is not reachable via any intra-domain routes supporting the transit policies listed in the SETUP message. - The next domain component listed in the SETUP message is not reachable. Each of these determinations is made from the perspective of a single policy gateway and may not reflect actual reachability. In each case, the policy gateway encountering such a problem returns a REFUSE message to the previous policy gateway which then selects a different next policy gateway, in round-robin order, as described in previously. If the policy gateway receives the same response from Steenstrup [Page 91] RFC 1479 IDPR Protocol July 1993 all next policy gateways selected, it abandons path setup, logs the event for network management, and returns the REFUSE message to the originator via the previous policy gateway. These types of REFUSE messages indicate to the originator that the route may have been generated using information from an out-of-date DYNAMIC message. The REFUSE message also serves to teardown the path. The originator reacts to the receipt of such a REFUSE message as follows. First, it removes the route from its cache. Then, it issues to a route server a ROUTE REQUEST message containing a directive to refresh the routing information database, with the most recent DYNAMIC message from the domain that issued the REFUSE message, before generating a new route. 7.4.4. Obtaining Resources Once the policy gateway determines that the SETUP message contents are consistent with the transit policies and virtual gateway reachability of its domain, it attempts to gain resources for the new path. For this version of IDPR, path resources consist of memory in the local forwarding information database. However, in the future, path resources may also include reserved link bandwidth. If the policy gateway does not have sufficient resources to establish the new path, it uses the following algorithm to determine whether to generate a REFUSE message for the new path or a TEARDOWN message for an existing path in favor of the new path. There are two cases: - No paths have been idle for more than pcp_idle (300) seconds. In this case, the policy gateway returns a REFUSE message to the previous policy gateway. This policy gateway then tries to select a different next policy gateway, as described previously, provided the policy gateway that issued the REFUSE message was not the target. If the REFUSE message was issued by the target or if there is no available next policy gateway, the policy gateway returns the REFUSE message to the originator via the previous policy gateway and logs the event for network management. The REFUSE message serves to tear down the path. - At least one path has been idle for more than pcp_idle seconds. In this case, the policy gateway tears down an older path in order to accommodate the newer path and logs the event for network management. Specifically, the policy gateway tears down the least recently used path among those that have been idle for longer than pcp_idle seconds, resolving ties by choosing the oldest such path. If the policy gateway has sufficient resources to establish the path, Steenstrup [Page 92] RFC 1479 IDPR Protocol July 1993 it attempts to update its local forwarding information database with information about the path identifier, previous and next policy gateways on the path, and directions in which the path should be enabled for data traffic transport. 7.4.5 Target Response When an acceptable SETUP message successfully reaches an entry policy gateway in the destination or destination proxy domain, this policy gateway performs all of the SETUP message checks described in the above sections. The policy gateway's path agent then becomes the target, provided no checks fail, unless there is an explicit target specified in the SETUP message. For example, remote route servers act as originator and target during RSQP message exchanges (see section 5.2). If the recipient policy gateway is not the target, it attempts to forward the SETUP message to the target along an intra- domain route. However, if the target is not reachable via intra- domain routing, the policy gateway abandons path setup, logs the event for network management, and returns a REFUSE message to the originator via the previous policy gateway. The REFUSE message serves to tear down the path. Once the SETUP message reaches the target, the target determines whether it has sufficient path resources. The target generates an ACCEPT message, provided it has sufficient resources to establish the path. Otherwise, it generates a REFUSE message. The target may choose to use the reverse path to transport data traffic to the source domain, if the enabled path directions include 10 or 11. However, the target must first verify the consistency of the reverse path with its own domain's configured transit policies, before sending data traffic over that path. 7.4.6. Originator Response The originator expects to receive an ACCEPT, REFUSE, or ERROR message in response to a SETUP message and reacts as follows: - The originator receives an ACCEPT message, confirming successful path establishment. To expedite data delivery, the originator may forward data messages along the path prior to receiving an ACCEPT message, with the understanding that there is no guarantee that the path actually exists. - The originator receives a REFUSE message or an ERROR message, implying that the path could not be successfully established. In response, the originator attempts to set up a different path to the same destination, as long as the number of selected different paths Steenstrup [Page 93] RFC 1479 IDPR Protocol July 1993 does not exceed setup_try (3). If the originator is unsuccessful after setup_try attempts, it abandons path setup and logs the event for network management. - The originator fails to receive any response to the SETUP message within setup_int microseconds after transmission. In this case, the originator attempts path setup using the same policy route and a new path identifier, as long as the number of path setup attempts using the same route does not exceed setup_ret (2). If the originator fails to receive a response to a SETUP message after setup_ret attempts, it logs the event for network management and then proceeds as though it received a negative response, namely a REFUSE or an ERROR, to the SETUP message. Specifically, it attempts to set up a different path to the same destination, or it abandons path setup altogether, depending on the value of setup_try. 7.4.7. Path Life Once set up, a path does not live forever. A path agent or policy gateway may tear down an existing path, provided any of the following conditions are true: - The maximum path lifetime (in minutes, bytes, or messages) has been exceeded at the originator, the target, or an intermediate policy gateway. In each case, the IDPR entity detecting path expiration logs the event for network management and generates a TEARDOWN message as follows: o The originator path agent generates a TEARDOWN message for propagation toward the target. o The target path agent generates a TEARDOWN message for propagation toward the originator. o An intermediate policy gateway generates two TEARDOWN messages, one for propagation toward the originator and one for propagation toward the target. - The previous or next policy gateway becomes unreachable, across a virtual gateway or across a domain according to a given transit policy, and the path is not reparable. In either case, the policy gateway detecting the reachability problem logs the event for network management and generates a TEARDOWN message as follows: o If the previous policy gateway is unreachable, an intermediate policy gateway generates a TEARDOWN message for propagation to the target. Steenstrup [Page 94] RFC 1479 IDPR Protocol July 1993 o If the next policy gateway is unreachable, an intermediate policy gateway generates a TEARDOWN message for propagation to the originator. - All of the policy gateway's path resources are in use at the originator, the target, or an intermediate policy gateway, a new path requires resources, and the given existing path is expendable, according to the least recently used criterion discussed in section 7.4.4 above. In each case, the IDPR entity initiating path preemption logs the event for network management and generates a TEARDOWN message as follows: o The originator path agent generates a TEARDOWN message for propagation toward the originator. o The target path agent generates a TEARDOWN message for propagation toward the originator. o An intermediate policy gateway generates two TEARDOWN messages, one for propagation toward the originator and one for propagation toward the target. Path teardown at a path agent or policy gateway, whether initiated by one of the above events, by receipt of a TEARDOWN message, or by receipt of a REFUSE message during path setup (as discussed in the previous sections), results in the path agent or policy gateway releasing all resources devoted to both directions of the path. 7.5. Path Failure and Recovery When a policy gateway fails, it may not be able to save information pertaining to its established paths. Thus, when the policy gateway returns to service, it may have no recollection of the paths set up through it and hence may no longer be able to forward data messages along these paths. We expect that when a policy gateway fails, it will usually be out of service for long enough that the up/down protocol and the intra-domain routing procedure can detect that the particular policy gateway is no longer reachable. In this case, adjacent or neighbor policy gateways that have set up paths through the failed policy gateway and that have detected the failure, attempt local path repair (see section 7.5.2 below), and if unsuccessful, issue TEARDOWN messages for all affected paths. Steenstrup [Page 95] RFC 1479 IDPR Protocol July 1993 7.5.1. Handling Implicit Path Failures Nevertheless, policy gateways along a path must be able to handle the case in which a policy gateway fails and subsequently returns to service without either the up/down protocol or the intra-domain routing procedure detecting the failure; we do not expect this event to occur often. If the policy gateway, prior to failure, contained forwarding information for several established paths, it may now receive many IDPR data messages containing unrecognized path identifiers. The policy gateway should alert the data sources that their paths through it are no longer viable. Policy gateways that receive IDPR data messages with unrecognized path identifiers take one of the following two actions, depending upon their past failure record: - The policy gateway has not failed in the past pg_up (24) hour period. In this case, there are at least four possible reasons for the unrecognized path identifier in the data message: o The data message path identifier has been corrupted in a way that is not detectable by the integrity/authentication value, if one is present. o The policy gateway has experienced a memory error. o The policy gateway failed sometime during the life of the path and source sent no data on the path for a period of pg_up hours following the failure. Although paths may persist for more than pg_up hours, we expect that they will also be used more frequently than once every pg_up hours. o The path was not successfully established, and the originator sent data messages down the path prior to receiving a response to its SETUP message. In all cases, the policy gateway discards the data message and logs the event for network management. - The policy gateway has failed at least once in the past pg_up hour period. Thus, the policy gateway assumes that the unrecognized path identifier in the data message may be attributed to its failure. In response to the data message, the policy gateway generates an ERROR message containing the unrecognized path identifier. The policy gateway then sends the ERROR message back to the entity from which it received the data message, which should be equivalent to the previous policy gateway on the path. Steenstrup [Page 96] RFC 1479 IDPR Protocol July 1993 When the previous policy gateway receives such an ERROR message, it decides whether the message is acceptable. If the policy gateway does not recognize the path identifier contained in the ERROR message, it does not find the ERROR message acceptable and subsequently discards the message. However, if the policy gateway does find the ERROR message acceptable, it then determines whether it has already received an ACCEPT message for the given path. If the policy gateway has not received an ACCEPT message for that path, it discards the ERROR message and takes no further action. If the policy gateway has received an ACCEPT message for that path, it then attempts path repair, as described in section 7.5.2 below. Only if path repair is unsuccessful does the previous policy gateway generate a TEARDOWN message for the path and return it to the originator. The TEARDOWN message includes the domain and virtual gateway containing the policy gateway that failed, which aids the originator in selecting a new path that does not include the domain containing the failed policy gateway. This mechanism ensures that path agents quickly discover and recover from disrupted paths, while guarding against unwarranted path teardown. 7.5.2. Local Path Repair Failure of one of more entities on a given path may render the path unusable. If the failure is within a domain, IDPR relies on the intra-domain routing procedure to find an alternate route across the domain, which leaves the path unaffected. If the failure is in a virtual gateway, policy gateways must bear the responsibility of repairing the path. Policy gateways nearest to the failure are the first to recognize its existence and hence can react most quickly to repair the path. Relinquishing control over path repair to policy gateways in other domains may be unacceptable to some domain administrators. The reason is that these policy gateways cannot guarantee construction of a path that satisfies the source policies of the source domain, as they have no knowledge of other domains' source policies. Nevertheless, limited local path repair is feasible, without distributing either source policy information throughout an internetwork or detailed path information among policy gateways in the same domain or in the same virtual gateway. We say that a path is "locally reparable" if there exists an alternate route between two policy gateways, separated by at most one virtual gateway, on the path. This definition covers path repair in the presence of failed routes between consecutive policy gateways as well as failed policy gateways themselves. Steenstrup [Page 97] RFC 1479 IDPR Protocol July 1993 An IDPR entity attempts local repair of an established path, in the direction from originator to target, immediately after detecting that the next policy gateway on the path is no longer reachable. To prevent multiple path repairs in response to the same failure, we have stipulated that path repair can only be initiated in the direction from originator to target. The IDPR entity initiating local path repair attempts to find an alternate path to the policy gateway immediately following the unreachable policy gateway on the path. Local path repair minimizes the disruption of data traffic flow caused by certain types of failures along an established path. Specifically, local path repair can accommodate an individual failed policy gateway or failed direct connection between two adjacent policy gateways. However, it can only be attempted through virtual gateways containing multiple peer policy gateways. Local path repair is not designed to repair paths traversing failed virtual gateways or domain partitions. Whenever local path repair is impossible, the failing path must be torn down. 7.5.3. Repairing a Path When an IDPR entity detects through an ERROR message that the next policy gateway has no knowledge of a given path, it generates a REPAIR message and forwards it to the next policy gateway. This REPAIR message will reestablish the path through the next policy gateway. When an entity detects that the next policy gateway on a path is no longer reachable, it takes one of the following actions, depending upon whether the entity is a member of the next policy gateway's virtual gateway. - If the entity is not a member of the next policy gateway's virtual gateway, then one of the following two conditions must be true: o The next policy gateway has a peer that is reachable via an intra-domain route consistent with the requested services. In this case, the entity generates a REPAIR message containing the original SETUP message and forwards it to the next policy gateway's peer. o The next policy gateway has no peers that are reachable via intra-domain routes consistent with the requested services. In this case, the entity tears down the path back to the originator. - If the entity is a member of the next policy gateway's virtual Steenstrup [Page 98] RFC 1479 IDPR Protocol July 1993 gateway, then one of the following four conditions must be true: o The next policy gateway has a peer that belongs to the same domain component and is directly-connected to and reachable from the entity. In this case, the entity generates a REPAIR message and forwards it to the next policy gateway's peer. o The next policy gateway has a peer that belongs to the same domain component, is not directly-connected to the entity, but is directly-connected to and reachable from one of the entity's peers, which in turn is reachable from the entity via an intra- domain route consistent with the requested services. In this case, the entity generates a REPAIR message and forwards it to its peer. o The next policy gateway has no operational peers within its domain component, but is directly-connected to and reachable from one of the entity's peers, which in turn is reachable from the entity via an intra-domain route consistent with the requested services. In this case, the entity generates a REPAIR message and forwards it to its peer. o The next policy gateway has no operational peers within its domain component, and the entity has no operational peers which are both reachable via intra-domain routes consistent with the requested services and directly-connected to and reachable from the next policy gateway. In this case, the entity tears down the path back to the originator. A recipient of a REPAIR message takes the following steps, depending upon its relationship to the entity that issued the REPAIR message. - The recipient and the issuing entity are in the same domain or in same virtual gateway. In this case, the recipient extracts the SETUP message contained within the REPAIR message and treats the message as it would any other SETUP message. Specifically, the recipient checks consistency of the path with its domain's transit policies and virtual gateway reachability. If there are unrecognized portions of the SETUP message, the recipient generates an ERROR message, and if there are path inconsistencies, the recipient generates a REFUSE message. In either case, the recipient returns the corresponding message to the policy gateway from which it received the REPAIR message. Otherwise, if the recipient accepts the REPAIR message, it updates its local forwarding information database accordingly and forwards the REPAIR message to a potential next policy gateway, according to the information contained in the enclosed SETUP message. Steenstrup [Page 99] RFC 1479 IDPR Protocol July 1993 - The recipient and the issuing entity are in different domains and different virtual gateways. In this case, the recipient extracts the SETUP message from the REPAIR message and determines whether the associated path matches any of its established paths. If the path does not match an established path, the recipient generates a REFUSE message and returns it to the policy gateway from which it received the REPAIR message. In response to the receipt of a REFUSE message, the policy gateway tries a different next policy gateway. The path is reparable, if a path match is discovered. In this case, the recipient updates the path entry in the local forwarding information database and issues an ACCEPT message to the policy gateway from which it received the REPAIR message, which in turn returns the message to the entity that issued the REPAIR message. The path is irreparable if all potential next policy gateways have been exhausted and a path match has yet to be discovered. In this case, the policy gateway that fails to locate a next policy gateway issues a TEARDOWN message to return to the originator. An IDPR entity expects to receive an ACCEPT, TEARDOWN, REFUSE, or ERROR message in response to a REPAIR message and reacts to these responses differently as follows: - The entity always returns a TEARDOWN message to the originator via previous policy gateway. - The entity does not return an ACCEPT message to the originator, but receipt of such a message indicates that the path has been successfully repaired. - The entity infers that the path is irreparable and subsequently tears down the path and logs the event for network management, upon receipt of a REFUSE or ERROR message or when no response to the REPAIR message arrives within setup_int microseconds. When an entity detects that the previous policy gateway on a path becomes unreachable, it expects to receive a REPAIR message within setup_wait microseconds. If the entity does not receive a REPAIR message for the path within that time, it infers that the path is irreparable and subsequently tears down the path and logs the event for network management. 7.6. Path Control Message Formats The path control protocol number is equal to 3. We describe the contents of each type of PCP message below. Steenstrup [Page 100] RFC 1479 IDPR Protocol July 1993 7.6.1. SETUP The SETUP message type is equal to 0. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH ID | | | +-------------------------------+-------------------------------+ | SRC AD | HST SET | +---------------+---------------+-------------------------------+ | UCI | UNUSED | NUM RQS | +---------------+---------------+-------------------------------+ | DST AD | TGT ENT | +-------------------------------+-------------------------------+ | AD PTR | +-------------------------------+ For each requested service for the path: +-------------------------------+-------------------------------+ | RQS TYP | RQS LEN | +-------------------------------+-------------------------------+ | RQS SRV | +---------------------------------------------------------------+ For each domain contained in the path: +---------------+---------------+-------------------------------+ | AD LEN | VG | ADJ AD | +---------------+---------------+-------------------------------+ | ADJ CMP | NUM TP | +-------------------------------+-------------------------------+ | TP | +-------------------------------+ PATH ID (64 bits) Path identifier consisting of the numeric identifier for the originator's domain (16 bits), the numeric identifier for the originator policy gateway or route server (16 bits), the path direction (2 bits), and the local path identifier (30 bits). SRC AD (16 bits) Numeric identifier for the source domain, which may be different from the originator domain if the originator domain is a proxy for the source. HST SET (16 bits) Numeric identifier for the source's host set. UCI (8 bits) Numeric identifier for the source user class. The value 0 indicates that there is no particular source user class. Steenstrup [Page 101] RFC 1479 IDPR Protocol July 1993 UNUSED (8 bits) Not currently used; must be set equal to 0. NUM RQS (16 bits) Number of requested services. DST AD (16 bits) Numeric identifier for the destination domain, which may be different from the target domain if the target domain is a proxy for the destination. TGT ENT (16 bits) Numeric identifier for the target entity. A value of 0 indicates that there is no specific target entity. AD PTR (16 bits) Byte offset from the beginning of the message indicating the location of the beginning of the domain-specific information, contained in the right-most 15 bits. The left-most bit indicates whether the message includes expedited data (1 expedited data, 0 no expedited data). RQS TYP (16 bits) Numeric identifier for a type of requested service or source-specific information. Valid requested services are described in section 5.5.2. Valid source source-specific information includes the following types: 12. MD4/RSA data message authentication (see [16]). 13. MD5/RSA data message authentication (see [17]). 14. Billing address (variable). 15. Charge number (variable). RQS LEN (16 bits) Length of the requested service or source-specific information, in bytes, beginning with the next field. RQS SRV (variable) Description of the requested service or source- specific information. AD LEN (8 bits) Length of the information associated with a particular domain on the route, in bytes, beginning with the next field. VG (8 bits) Numeric identifier for an exit virtual gateway. ADJ AD (16 bits) Numeric identifier for an adjacent domain. ADJ CMP (16 bits) Numeric identifier for a component of the adjacent domain. Used to aid a policy gateway in routing across a virtual gateway connected to a partitioned domain. Steenstrup [Page 102] RFC 1479 IDPR Protocol July 1993 NUM TP (16 bits) Number of transit policies that apply to the section of the path traversing the given domain component. TP (16 bits) Numeric identifier for a transit policy. 7.6.2. ACCEPT The ACCEPT message type is equal to 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH ID | | | +---------------+-----------------------------------------------+ | RSN TYP | REASON | +---------------+-----------------------------------------------+ PATH ID (64 bits) Path identifier contained in the original SETUP message. RSN TYP (optional, 8 bits) Numeric identifier for the reason for conditional path acceptance. REASON (optional, variable) Description of the reason for conditional path acceptance. Currently, no reasons have been defined. 7.6.3 REFUSE The REFUSE message type is equal to 2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH ID | | | +---------------+-----------------------------------------------+ | RSN TYP | REASON | +---------------+-----------------------------------------------+ PATH ID (64 bits) Path identifier contained in the original SETUP message. RSN TYP (8 bits) Numeric identifier for the reason for path refusal. REASON (variable) Description of the reason for path refusal. Valid Steenstrup [Page 103] RFC 1479 IDPR Protocol July 1993 reasons include the following types: 1. Transit policy does not apply between the virtual gateways in a given direction. Numeric identifier for the transit policy (16 bits). 2. Transit policy denies access to traffic from the host set between the source and destination domains. Numeric identifier for the transit policy (16 bits). 3. Transit policy denies access to traffic from the source user class. Numeric identifier for the transit policy (16 bits). 4. Transit policy denies access to traffic at the current time. Numeric identifier for the transit policy (16 bits). 5. Virtual gateway is down. Numeric identifier for the virtual gateway (8 bits) and associated adjacent domain (16 bits). 6. Virtual gateway is not reachable according to the given transit policy. Numeric identifier for the virtual gateway (8 bits), associated adjacent domain (16 bits), and transit policy (16 bits). 7. Domain component is not reachable. Numeric identifier for the domain (16 bits) and the component (16 bits). 8. Insufficient resources to establish the path. 9. Target is not reachable via intra-domain routing. 10. No existing path with the given path identifier, in response to a REPAIR message only. 7.6.4. TEARDOWN The TEARDOWN message type is equal to 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH ID | | | +---------------+-----------------------------------------------+ | RSN TYP | REASON | +---------------+-----------------------------------------------+ Steenstrup [Page 104] RFC 1479 IDPR Protocol July 1993 PATH ID (64 bits) Path identifier contained in the original SETUP message. RSN TYP (8 bits) Numeric identifier for the reason for path teardown. REASON (variable) Description of the reason for path teardown. Valid reasons include the following types: 1. Virtual gateway is down. Numeric identifier for the virtual gateway (8 bits) and associated adjacent domain (16 bits). 2. Virtual gateway is not reachable according to the given transit policy. Numeric identifier for the virtual gateway (8 bits), associated adjacent domain (16 bits), and transit policy (16 bits). 3. Domain component is not reachable. Numeric identifier for the domain (16 bits) and the component (16 bits). 4. Maximum path lifetime exceeded. 5. Preempted path. 6. Unable to repair path. 7.6.5. ERROR The ERROR message type is equal to 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH ID | | | +---------------+---------------+-------------------------------+ | MSG | RSN TYP | REASON | +---------------+---------------+-------------------------------+ PATH ID (64 bits) Path identifier contained in the path control or data message in error. MSG (8 bits) Numeric identifier for the type of path control message in error. This field is ignored for error type 5. RSN TYP (8 bits) Numeric identifier for the reason for the PCP message error. Steenstrup [Page 105] RFC 1479 IDPR Protocol July 1993 REASON (variable) Description of the reason for the PCP message error. Valid reasons include the following types: 1. Path identifier is already currently active. 2. Domain does not appear in the SETUP message. 3. Transit policy is not configured for the domain. Numeric identifer for the transit policy (16 bits). 4. Virtual gateway not configured for the domain. Numeric identifier for the virtual gateway (8 bits) and associated adjacent domain (16 bits). 5. Unrecognized path identifier in an IDPR data message. 7.6.6. REPAIR The REPAIR message type is equal to 5. A REPAIR message contains the original SETUP message only. 7.6.7. Negative Acknowledgements When a policy gateway receives an unacceptable PCP message that passes the CMTP validation checks, it includes, in its CMTP ACK, an appropriate negative acknowledgement. This information is placed in the INFORM field of the CMTP ACK (described previously in section 2.4); the numeric identifier for each type of PCP negative acknowledgement is contained in the left-most 8 bits of the INFORM field. Negative acknowledgements associated with PCP include the following types: 1. Unrecognized PCP message type. Numeric identifier for the unrecognized message type (8 bits). 2. Out-of-date PCP message. 3. Unrecognized path identifier (for all PCP messages except SETUP). Numeric identifier for the unrecognized path (64 bits). 8. Security Considerations Refer to sections 1.6, 1.7, and 2.3 for details on security in IDPR. Steenstrup [Page 106] RFC 1479 IDPR Protocol July 1993 9. Author's Address Martha Steenstrup BBN Systems and Technologies 10 Moulton Street Cambridge, MA 02138 Phone: (617) 873-3192 Email: msteenst@bbn.com References [1] Clark, D., "Policy Routing in Internet Protocols", RFC 1102, May 1989. [2] Estrin, D., "Requirements for Policy Based Routing in the Research Internet", RFC 1125, November 1989. [3] Little, M., "Goals and Functional Requirements for Inter- Autonomous System Routing", RFC 1126, July 1989. [4] Breslau, L. and Estrin, D., "Design of Inter-Administrative Domain Routing Protocols", Proceedings of the ACM SIGCOMM '90 Symposium, September 1990. [5] Steenstrup, M., "An Architecture for Inter-Domain Policy Rout- ing", RFC 1478, July 1993. [6] Austein, R., "DNS Support for IDPR", Work in Progress, March 1993. [7] Bowns, H. and Steenstrup, M., "Inter-Domain Policy Routing Con- figuration and Usage", Work in Progress, July 1991. [8] Woodburn, R., "Definitions of Managed Objects for Inter-Domain Policy Routing (Version 1)", Work in Progress, March 1993. [9] McQuillan, J., Richer, I., Rosen, E., and Bertsekas, D., "ARPANET Routing Algorithm Improvements: Second Semiannual Technical Report", BBN Report No. 3940, October 1978. [10] Moy, J., "The OSPF Specification", RFC 1131, October 1989. [11] Oran, D. (editor), "Intermediate System to Intermediate System Routeing Exchange Protocol for Use in Conjunction with the Pro- tocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC JTC1/SC6/WG2, October 1989. Steenstrup [Page 107] RFC 1479 IDPR Protocol July 1993 [12] Estrin, D., and Tsudik, G., "Secure Control of Transit Internet- work Traffic, TR-89-15, Computer Science Department, University of Southern California. [13] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I - Message Encipherment and Authentication Procedures", RFC 1113, August 1989. [14] Kent, S., and Linn, J., "Privacy Enhancement for Internet Elec- tronic Mail: Part II - Certificate-based Key Management", RFC 1114, August 1989. [15] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part III - Algorithms, Modes, and Identifiers", RFC 1115, August 1989. [16] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, April 1992. [17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. Steenstrup [Page 108] Network Working Group A. Cooper Request for Comments: 1480 J. Postel Obsoletes: 1386 June 1993 The US Domain Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Table of Contents 1. Introduction ................................................ 2 1.1 The Internet Domain Name System......................... 2 1.2 Top-Level Domains....................................... 3 1.3 The US Domain .......................................... 4 2. Naming Structure ............................................ 4 2.1 State Codes ............................................ 8 2.2 Locality Names.......................................... 8 2.3 Schools ................................................ 10 2.4 State Agencies.......................................... 15 2.5 Federal Agencies ....................................... 15 2.6 Distributed National Institutes......................... 15 2.7 General Independent Entities............................ 16 2.8 Examples of Names....................................... 17 3. Registration ................................................ 20 3.1 Requirements ........................................... 20 3.2 Direct Entries ......................................... 21 3.2.1 IP-Hosts............................................. 21 3.2.2 Non-IP Hosts ........................................ 21 3.3 Delegated Subdomains ................................... 24 3.3.1 Delegation Requirement............................... 26 3.3.2 Delegation Procedures ............................... 28 3.3.3 Subdomain Contacts................................... 29 4. Database Information......................................... 30 4.1 Name Servers ........................................... 30 4.2 Zone files ............................................. 30 4.3 Resource Records ....................................... 31 4.3.1 "A" Records ......................................... 32 4.3.2 CNAME Records ....................................... 32 4.3.3 MX Records .......................................... 33 4.3.4 HINFO Records ....................................... 33 4.3.5 PTR Records ......................................... 33 4.4 Wildcards .............................................. 34 5. References .................................................. 35 Cooper & Postel [Page 1] RFC 1480 The US Domain June 1993 6. Security Considerations ..................................... 35 7. Authors' Addresses .......................................... 36 Appendix-I: US Domain Names BNF................................. 37 Appendix-II: US Domain Questionnaire ............................ 42 1. INTRODUCTION 1.1 The Internet Domain Name System The Domain Name System (DNS) provides for the translation between hostnames and addresses. Within the Internet, this means translating from a name such as "venera.isi.edu", to an IP address such as "128.9.0.32". The DNS is a set of protocols and databases. The protocols define the syntax and semantics for a query language to ask questions about information located by DNS-style names. The databases are distributed and replicated. There is no dependence on a single central server, and each part of the database is provided in at least two servers. The assignment of the 32-bit IP addresses is a separate activity. IP addresses are delegated by the central Internet Registry to regional authorities (such as the RIPE NCC for Europe) and the network providers. To have a network number assigned please contact your network service provider or regional registration authority. To determine who this is (or as a last resort), you can contact the central Internet Registry at Hostmaster@INTERNIC.NET. In addition to translating names to addresses for hosts that are on the Internet, the DNS provides for registering DNS-style names for other hosts reachable (via electronic mail) through gateways or mail relays. The records for such name registrations point to an Internet host (one with an IP address) that acts as a mail forwarder for the registered host. For example, the host "bah.rochester.ny.us" is registered in the DNS with a pointer to the mail relay "relay1.uu.net". This type of pointer is called an MX record. This gives electronic mail users a uniform mail addressing syntax and avoids making users aware of the underlying network boundaries. The reason for the development of the domain system was growth in the Internet. The hostname to address mappings were maintained by the InterNIC in a single file, called HOSTS.TXT, which was FTP'd by all the hosts on the Internet. The network population was changing in character. The time-share hosts that made up the original ARPANET were being replaced with local networks of workstations. Local organizations were administering their own names and addresses, but Cooper & Postel [Page 2] RFC 1480 The US Domain June 1993 had to wait for the NIC to make changes in HOSTS.TXT to make the changes visible to the Internet at large. Organizations also wanted some local structure on the name space. The applications on the Internet were getting more sophisticated and creating a need for general purpose name service. The idea of a hierarchical name space, with the hierarchy roughly corresponding to organizational structure, and names using "." as the character to mark the boundary between hierarchy levels was developed. A design using a distributed database and generalized resources was implemented. The DNS provides standard formats for resource data, standard methods for querying the database, and standard methods for name servers to refresh local data from other name servers. 1.2 Top-Level Domains The top-level domains in the DNS are EDU, COM, GOV, MIL, ORG, INT, and NET, and all the 2-letter country codes from the list of countries in ISO-3166. The establishment of new top-level domains is managed by the Internet Assigned Numbers Authority (IANA). The IANA may be contacted at IANA@ISI.EDU. Even though the original intention was that any educational institution anywhere in the world could be registered under the EDU domain, in practice, it has turned out with few exceptions, only those in the United States have registered under EDU, similarly with COM (for commercial). In other countries, everything is registered under the 2-letter country code, often with some subdivision. For example, in Korea (KR) the second level names are AC for academic community, CO for commercial, GO for government, and RE for research. However, each country may go its own way about organizing its domain, and many have. There are no current plans of putting all of the organizational domains EDU, GOV, COM, etc., under US. These name tokens are not used in the US Domain to avoid confusion. Currently, only four year colleges and universities are being registered in the EDU domain. All other schools are being registered in the US Domain. There are also concerns about the size of the other top-level domains (especially COM) and ideas are being considered for restructuring. Other names sometimes appear as top-level domain names. Some people have made up names in the DNS-style without coordinating or registering with the DNS management. Some names that typically appear are BITNET, UUCP, and two-letter codes for continents, such as Cooper & Postel [Page 3] RFC 1480 The US Domain June 1993 "NA" for North America (this conflicts with the official Internet code for Namibia). For example, the DNS-style name "KA7EEJ.CO.USA.NA" is used in the amateur radio network. These addresses are never supposed to show up on the Internet but they do occasionally. The amateur radio network people created their own naming scheme, and it interferes sometimes with Internet addresses. 1.3 The US Domain The US Domain is an official top-level domain in the DNS of the Internet community. The domain administrators are Jon Postel and Ann Westine Cooper at the Information Sciences Institute of the University of Southern California (USC-ISI). US is the ISO-3166 2-letter country code for the United States and thus the US Domain is established as a top-level domain and registered with the InterNIC the same way other country domains are. Because organizations in the United States have registered primarily in the EDU and COM domains, little use was initially made of the US domain. In the past, the computers registered in the US Domain were primarily owned by small companies or individuals with computers at home. However, the US Domain has grown and currently registers hosts in federal government agencies, state government agencies, K12 schools, community colleges, technical/vocational schools, private schools, libraries, city and county government agencies, to name a few. Initially, the administration of the US Domain was managed solely by the Domain Registrar. However, due to the increase in registrations, administration of subdomains is being delegated to others. Any computer in the United States may be registered in the US Domain. 2. NAMING STRUCTURE The US Domain hierarchy is based on political geography. The basic name space under US is the state name space, then the "locality" name space, (like a city, or county) then organization or computer name and so on. For example: BERKELEY.CA.US PORTLAND.WA.US Cooper & Postel [Page 4] RFC 1480 The US Domain June 1993 There is of course no problem with running out of names. The things that are named are individual computers. If you register now in one city and then move, the database can be updated with a new name in your new city, and a pointer can be set up from your old name to your new name. This type of pointer is called a CNAME record. The use of unregistered names is not effective and causes problems for other users. Inventing your own name and using it without registering is not a good idea. In addition to strictly geographically names, some special names are used, such as FED, STATE, AGENCY, DISTRICT, K12, LIB, CC, CITY, and COUNTY. Several new name spaces have been created, DNI, GEN, and TEC, and a minor change under the "locality" name space was made to the existing CITY and COUNTY subdomains by abbreviating them to CI and CO. A detailed description follows. Below US, Parallel to States: ----------------------------- "FED" - This branch may be used for agencies of the federal government. For example: ..FED.US "DNI" - DISTRIBUTED NATIONAL INSTITUTES - The "DNI" branch was created directly under the top-level US. This branch is to be used for distributed national institutes; organizations that span state, regional, and other organizational boundaries; that are national in scope, and have distributed facilities. For example: .DNI.US. Name Space Within States: ------------------------ "locality" - cities, counties, parishes, and townships. Subdomains under the "locality" would be like CI...US, CO...US, or businesses. For example: Petville.Marvista.CA.US. "CI" - This branch is used for city government agencies and is a subdomain under the "locality" name (like Los Angeles). For example: Fire-Dept.CI.Los-Angeles.CA.US. "CO" - This branch is used for county government agencies and is a subdomain under the "locality" name (like Los Angeles). For example: Fire-Dept.CO.San-Diego.CA.US. Cooper & Postel [Page 5] RFC 1480 The US Domain June 1993 "K12" - This branch may be used for public school districts. A special name "PVT" can be used in the place of a school district name for private schools. For example: .K12..US and .PVT.K12..US. "CC" - COMMUNITY COLLEGES - This branch was established for all state wide community colleges. For example: .CC..US. "TEC" - TECHNICAL AND VOCATIONAL SCHOOLS - The branch "TEC" was established for technical and vocational schools and colleges. For example: .TEC..US. "LIB" - LIBRARIES (STATE, REGIONAL, CITY, COUNTY) - This branch may be used for libraries only. For example: .LIB..US. "STATE" - This branch may be used for state government agencies. For example: .STATE..US. "GEN" - GENERAL INDEPENDENT ENTITY - This branch is for the things that don't fit easily into any other structure listed -- things that might fit in to something like ORG at the top-level. It is best not to use the same keywords (ORG, EDU, COM, etc.) that are used at the top-level to avoid confusion. GEN would be used for such things as, state-wide organizations, clubs, or domain parks. For example: .GEN..US. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ VIEW OF SECOND LEVEL DOMAINS UNDER US +-------+ | US | +-------+ | +----------------------------------+ | | | | | +-----+ +-----+ +-----+ +-----+ +-----+ | FED | | DNI | | TX | | SD | | CA | +-----+ +-----+ +-----+ +-----+ +-----+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Cooper & Postel [Page 6] RFC 1480 The US Domain June 1993 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ SCHOOL AND LIBRARY VIEW +-----+ | CA | +-----+ | +------------------------------------------------+ | | | | | +-----+ +-----+ +-----+ +-------------+ +-----+ | K12 | | CC | | TEC | | LOS ANGELES | | LIB | +-----+ +-----+ +-----+ +-------------+ +-----+ / \ /|\ /|\ /|\ /|\ +--------+ +---+ +---+ +--------+ +----------+ +------+ |sch dist| |PVT| |SJC| |WM TRADE| |pvt school| |MALIBU| +--------+ +---+ +---+ +--------+ +----------+ +------+ /|\ /|\ +--------+ +--------+ |sch name| |sch name| +--------+ +--------+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ VIEW OF STATE, REGIONAL, and GENERAL AGENCIES +-----+ | CA | +-----+ | +-------------------------+ | | | +-------+ +--------+ +-----+ | STATE | |DISTRICT| | GEN | +-------+ +--------+ +-----+ /|\ /|\ /|\ +--------+ +------+ +---------+ |CALTRANS| |SCAQMD| |domain pk| ---------+ +------+ +---------+ | +--------+ |TCEW100E| +--------+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Cooper & Postel [Page 7] RFC 1480 The US Domain June 1993 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ VIEW OF LOCALITY +-----+ | CA | +-----+ | +-----------------------------------+ | | +-------------------------+ +----------------+ | LOS ANGELES | | SANTA MONICA | +-------------------------+ +----------------+ / | | /|\ | /|\ / | | | | | +---+ +--+ +--+ +-----------+ +--+ +---+ |bus| |CI| |CO| | pvt school| |CI| |bus| +---+ +--+ +--+ +-----------+ +--+ +---+ /\ | | / \ | +------------+ / \ | |HARBOR GUARD| / \ | +------------+ +-----+ +-----+ +-----+ +----+ |FIRE | |ADMIN| |PARKS| |FIRE| +-----+ +-----+ +-----+ +----+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2.1 State Codes The state codes are the two letter US Postal abbreviations. For example: "CA" California. 2.2 Locality Names Within the state name space there are "locality" names, some may be cities, some may be counties, some may be local names, but not incorporated entities. Registered names under "locality" could be like: .CI...US ==> city gov't agency .CO...US, ==> county gov't agency ...US ==> businesses In the cases where the locality name is a county, there is a branch under the locality name, called "county" or "CO", that is used by the county government. Businesses are registered directly under the locality name. Cooper & Postel [Page 8] RFC 1480 The US Domain June 1993 Under the city locality name space there is a "city" or "CI" branch for city government agencies. As usual, businesses and private schools may register directly under the city name. In the case where there is both a county and a city with the same locality name there is no problem, since the names will be unique with the "CO" or "CI" keyword. In our area the county has a fire department and the city has its own fire department. They could have names like: Fire-Dept.CI.Los-Angeles.CA.US Fire-Dept.CO.Los-Angeles.CA.US Cities may be named (designated) by their full name (spelled out with hyphens replacing spaces (e.g., Los-Angeles or Fort-Collins), or by a city code. The first choice is the full city name. In some cases it may be appropriate to use the well-known city abbreviation known throughout a locality. However, it is very desirable that all users in the same city use the same designator for the city. That is, any particular locality should have just one DNS name. Some users would like names associated with a greater metropolitan area or region like the "Bay Area" or "Tri-Cities". One problem with this is that these names are not necessarily unique within a state. The best thing to do in this case is to use the larger metropolitan city in your hostname. Cities and counties are used. Should all the names be obvious? Trying to do this is desirable and also impossible. There will come a point when the obviously right name for an organization is already taken. As the system grows this will happen with increasing frequency. While ease of use to the end user is desirable, a higher priority must be placed on having a system that operates. This means that the manageability of the system must have high consideration. The reason the DNS was created was to subdivide the problem of maintaining a list of hosts in the Internet into manageable portions. The happy result is that this subdivision makes name uniqueness easier and promotes logical grouping. What is a "logical grouping" though, always depends on the viewer. Many levels of delegation are needed to keep the zone files manageable. Many sections of the name space are needed to allow unique names to be easily added. Cooper & Postel [Page 9] RFC 1480 The US Domain June 1993 Way back in the olden days, when the Internet was invented, some thought that an 8-bit network number would be more than enough to number all the networks that would ever exist. Today, there are over 10,000 networks operating in the Internet, and arguments are made about the doubling time being 2 years versus 4 years. One concern is that things will continue to grow dramatically, and this will require more subdivision of the domain name management. Maybe the plan for the US Domain is overkill on growth planning, but there has never been overplanning for growth yet. When things are bigger, names have to be longer. There is an argument that with only 8-character names, and in each position allow a-z, 0-9, and -, you get 37**8 = 3,512,479,453,921 or 3.5 trillion possible names. It is a great argument, but how many of us want names like "xs4gp-7q". It is like license plate numbers, sure some people get the name they want on a vanity plate, but a lot more people who want something specific on a vanity plate can't get it because someone else got it first. Structure and longer names also let more people get their "obviously right" name. 2.3 Schools K12 schools are connecting to the Internet and registering in the Internet DNS. A decision has been made by the IANA (after consultation with the new InterNIC Internet Registry and the Federal Networking Council (FNC)) to direct these school registrations to the US domain using the naming structure described here. There is a need for competent, experienced, volunteers to come forward to act as third and perhaps fourth level registries and to operate delegated portions of the DNS. There are two reasons for registering schools in the US Domain. (1) uniqueness of names, and (2) management of the database. 1. Name Uniqueness: There are many "Washington" high schools, only one can be "Washington.EDU" (actually none can be, since that name is used by a University. There will be many name conflicts if all schools attempt to register directly under EDU. In addition, in some districts, the same school name is used at different levels, for example, Washington Elementary School and Washington High School. We suggest that when necessary, the keywords "Elementary", "Middle", and "High" be used to distinguish these schools. These keywords would only be used Cooper & Postel [Page 10] RFC 1480 The US Domain June 1993 when they are needed, if the school's name is unique without such keywords, don't use them. 2. Database Management: One goal of the DNS is to divide up the management of the name database in to small pieces. Each piece (or "zone" in DNS terminology) could be managed by a distinct administrator. Adding all the high schools to the EDU domain will make the already large zone file for EDU even larger, possibly to the point of being unmanageable. For both these reasons it is necessary to introduce structure into names. Structure provides a basis for making common names unique in context, and for dividing the management responsibility. The US Domain has a framework established and has registered many schools already in this structured scheme. The general form is: ..K12..US. For example: Hamilton.LA-Unified.K12.CA.US Public schools are usually organized by districts which can be larger or smaller than a city or county. For example, the Portland school district in Oregon, is in three or four counties. Each of those counties also has non-Portland districts. It makes sense to name schools within districts. However districts often have the same name as a city or county so there has to be a way to distinguish a public school district name from some other type of locality name. The keyword "K12" is used for this. For example, typical K12 school names currently used are: IVY.PRS.K12.NJ.US DMHS.JCPS.K12.KY.US OHS.EUNION.K12.CA.US BOHS.BREA.K12.CA.US These names are generally longer than the old alternative of shorter names in the EDU domain, but that would not have lasted long without a significant number of schools finding that their "obviously correct" name has already been used by some other school. Cooper & Postel [Page 11] RFC 1480 The US Domain June 1993 When there are many things to name some of the names will be long. In some cases there may be appropriate abbreviations that can be used. For example Hamilton High School in Los Angeles could be: Hami.Hi.LA.K12.CA.US If a school has a number of PCs, then each PC should have a name. Suppose they are named "alpha", "beta", ... then if they belong to a school named "Lincoln.High.Lakewood.K12.CA.US" their names would be: alpha.Lincoln.High.Lakewood.K12.CA.US. beta.Lincoln.High.Lakewood.K12.CA.US ... The K12 subdomain provides two points at which to delegate a branch of the database to distinct administrators -- the K12 Administrator for each state, and the district administrator for each district within a state. The US Domain Administrator will delegate a branch of the US domain to an appropriate party. In some cases, this may be a particular school, a school district, or ever all of K12 for a state. The responsibility for managing a K12 branch or sub-branch may be delegated to an appropriate volunteer. We envision that such delegations of the schools' DNS service may eventually migrate to someone else "more appropriate" from an administrative organizational point of view. The "obvious" state agency to manage the schools' DNS branch may take some time to get up to speed on Internetting. In the meantime, we can have the more advanced schools up and running. Special Schools and Service Units In many states, there are special schools that are not in districts that are run directly by the state or by consortiums. There are also service units that provide "educational services" ranging from books and computers to janitorial supplies and building maintenance. Often these service units do not have a one-to-one relationship with districts. There is some concern about naming these schools and service units within the naming structure for schools established in this memo. There are several possibilities. For a state with many service units creating a "pseudo district" ESU (or whatever, the common terminology is in that state) is a possibility. For example, the Johnson service unit could be JOHNSON.ESU.K12.CA.US. For a state with a few such service units (and avoiding conflicts with district names) the service units could be directly under K12. For example, Cooper & Postel [Page 12] RFC 1480 The US Domain June 1993 TIES.K12.MN.US. The special public funded schools can be handled in a similar fashion. If there are many special schools in a state, a "pseudo district" should be established and all the special schools listed under it. For example, suppose there is a "pseudo district" in Massachusetts called SPCL, and there is a special school called the Progressive Computer Institute, then that school could have the name PCI.SPCL.K12.MA.US. If there are only a few special schools, they can be listed directly under K12 (avoiding name conflicts with district names). For example, the California Academy of Math and Science is CAMS.K12.CA.US. CAMS is sponsored by seven schools, the California Department of Education, and a University. "PVT" Private Schools Private schools may be thought of as businesses. Public schools are in districts, and districts provide a natural organizational structure for naming and delegation. For private schools there are no districts and they really do operate like businesses. But, many people are upset to think about their children in a private school being in a business category and not in K12 with the rest of the children. To accommodate both public and private schools, in each state's K12 branch, we've added an artificial district called private or "PVT". This gives a private school the option of registering like a business under "locality" or in the PVT.K12..US branch. For example: Crossroads.PVT.K12.CA.US Crossroads-Santa-Monica.CA.US A public school "Oak High" in the "Woodward" school district in California would have a name like "Oak-High.Woodward.K12.CA.US". A private school "Old Trail" in Pasadena, California could have the based name "Old-Trail.Pasadena.CA.US" or the private school base name "Old-Trail.PVT.K12.CA.US". Some suggest that for private schools instead of a special pseudo district PVT to use a locality name. One reason to use district names is that, in time, it seems likely that school district administrators will take over the operation of the DNS for their district. One needs to be able to delegate at that branch point. One implication of delegation is that the delegatee is now in charge of a chunk of the name space and will be registering new names. To keep names unique one can't have two different people registering new things below identically named branches. Cooper & Postel [Page 13] RFC 1480 The US Domain June 1993 For example, if there is a school district named Pasadena and a city named Pasadena, the branch of the name space PASADENA.K12.CA.US might be delegated to the administrator of that public school district. If a private school in Pasadena wanted to be registered in the DNS, it would have to get the public school district administrator to do it (perhaps unlikely) or not be in the K12 branch at all (unless there is the PVT pseudo district). So, if private schools are registered by ..K12..US and public schools are registered by ..K12..US, there can't be any locality names that are the same as district names or the delegation of these will get very tricky later. If it is all done by locality names rather than district names, and public and private schools are mixed together, then finding an appropriate party to delegate the locality to may be difficult. Another suggestion was that private schools be registered directly under K12, while public schools must be under a district under K12. This would require the operator of the K12 branch to register all districts and private schools himself (checking for name uniqueness), he couldn't easily delegate the registration of the private schools to anyone else. Community Colleges and Technical Schools To distinguish Community Colleges and Technical/Vocational schools, the keywords "CC" and "TEC" have been created. Some School Examples Hamilton.High.LA-Unified.K12.CA.US <== a public school Sherman-Oaks.Elem.LA-Unified.K12.CA.US <== a public school John-Muir.Middle.Santa-Monica.K12.CA.US <== a public school Crossroads-School.Santa-Monica.CA.US <== a private school SMCC.CC.CA.US <== a community college TECMCC.CC.CA.US <== a community college Brick-and-Basket-Institute.TEC.CA.US <== a technical college Northridge.CSU.STATE.CA.US <== a state university Cooper & Postel [Page 14] RFC 1480 The US Domain June 1993 2.4 State Agencies Several states are setting up networks to interconnect the offices of state government agencies. The hosts in such networks should be registered under the STATE..US branch. A US Domain name space has been established for the state government agencies. For example, in the State of Minnesota, the subdomain is STATE.MN.US. State Agencies: --------------- Senate.STATE.MN.US <== State Senate MDH.STATE.MN.US <== Dept. of Health CALTRANS.STATE.CA.US <== Dept. of Transportation DMV.STATE.CA.US <== Dept. of Motor Vehicles 2.5 Federal Agencies A federal name space has been established for the federal government agencies. For example, the subdomain for the Federal Reserve Bank of Minneapolis is MNPL.FRB.FED.US. Other examples are listed below. Federal Government Agencies: --------------------------- Senate.FED.US <==== US Senate DOD.FED.US <==== US Defense Dept. USPS.FED.US <==== US Postal Service VA.FED.US <==== US Veterans Administration IRS.FED.US <==== US Internal Revenue Service Yosemite.NPS.Interior.FED.US <==== A Federal agency 2.6 Distributed National Institutes The "DNI" branch was created directly under the top-level US. This is to be used for organizations that span state, regional, and other organizational boundaries; are national in scope, and have distributed facilities. An example would be: Distributed National Institutes: -------------------------------- MetaCenter.DNI.US <==== The MetaCenter Supercomputer Centers Cooper & Postel [Page 15] RFC 1480 The US Domain June 1993 The MetaCenter domain encompasses the four NSF sponsored supercomputer centers. These are: San Diego Supercomputer Center (SDSC) National Center for Supercomputing Applications (NCSA) Pittsburgh Supercomputing Center (PSC) Cornell Theory Center (CTC) The MetaCenter Network will enable applications and services like file systems and archival storage to be operated in a distributed fashion; thus, allowing the resources at the four centers to appear integrated and "seamless" to users of the centers. 2.7 General Independent Entities This name space was created for organizations that don't really fit anywhere else, such as state-wide associations, clubs, and "domain parks". Think of this as the miscellaneous category. The examples are state-wide clubs. For example, the Garden Club of Arizona, might want to be "GARDEN.GEN.AZ.US". Such a club has membership from all over the state and is not associated with any one city (or locality). Another example is "domain parks" that have been established up-to-now as entities in ORG. For example, there is "LONESTAR.ORG", which is a kind of computer club in Texas that has lots of dial-in computers registered. In the US Domain such an entity might have a name like "LONESTAR.GEN.TX.US". The organizations registered in GEN may typically be non-profit entities. These organizations don't fit in a and are not a school, library, or state agency. Ordinary businesses are not registered in GEN. Some suggest that these kinds of organizations are just like all the other things and ought to be registered under some . This may be true, but sometimes one just can't find any way to convince the applicant that it is the right thing to do. One can argue that any organization has to have a headquarters, or an office, or something about it that is in a fixed place, and thus the organization could be registered in that place. Some suggest that no token is needed, these entities could be directly under the . The problem with not having a token, is that you can't delegate the responsibility for registering these entities to someone separate from whoever is responsible for the . You want to be able to delegate for both name- uniqueness reasons, and operational management reasons. Having a token there makes both easy. Cooper & Postel [Page 16] RFC 1480 The US Domain June 1993 General Independent Entities: ----------------------------- CAL-Comp-Club.GEN.CA.US <==== The Computer Club of California 2.8 Examples of Names For small entities like individuals or small businesses, there is usually no problem with selecting locality based names. For example: Zuckys.Santa-Monica.CA.US For large entities like large corporations with multiple facilities in several cities or states this often seems like an unreasonable constraint (especially when compared with the alternative of registering directly in the COM domain). However, a company does have a headquarters office in a particular locality and so could register with that name. Example: IBM.Armonk.NY.US PRIVATE (business or individual) ================================ Camp-Curry.Yosemite.CA.US <==== a business IBM.Armonk.NY.US <==== a business Dogwood.atl.GA.US <==== a business Geo-Petrellis.Culver-City.CA.US <==== a restaurant Zuckys.Santa-Monica.CA.US <==== a restaurant Joe-Josts.Long-Beach.CA.US <==== a bar Holodek.Santa-Cruz.CA.US <==== a personal computer FEDERAL ======= Senate.FED.US <==== US Senate DOD.FED.US <==== US Defense Dept. DOT.FED.US <==== US Transportation Dept. USPS.FED.US <==== US Postal Service VA.FED.US <==== US Veterans Administration IRS.FED.US <==== US Internal Revenue Service Yosemite.NPS.Interior.FED.US <==== a federal agency MNPL.FRB.FED.US. <==== US Fed. Reserve Bank of Minneapolis Cooper & Postel [Page 17] RFC 1480 The US Domain June 1993 STATE ===== Senate.STATE.MN.US <==== state Senate House.STATE.MN.US <==== state House of Reps MDH.STATE.MN.US <==== state Health Dept. HUD.STATE.CA.US <==== state House and Urban Dev. Dept. DOT.STATE.MN.US <==== state Transportation Dept. CALTRANS.STATE.CA.US <==== state Transportation Dept. DMV.STATE.CA.US <==== state Motor Vehicles Dept. Culver-City.DMV.STATE.CA.US <==== a local office of DMV DNI (distributed national Institutes) ====================================== METACENTER.DNI.US <==== a distributed nat'l Inst. GEN (General Independent Entities) ================================== GARDEN.GEN.AZ.US <==== a garden club of Arizona CITY | CI | COUNTY | CO (locality) ================================== Parks.CI.Culver-City.CA.US <==== a city department Fire-Dept.CI.Los-Angeles.CA.US <==== a city department Fire-Dept.CO.Los-Angeles.CA.US <==== a county department Planning.CO.Fulton.GA.US. <==== a county department Main.Library.CI.Los-Angeles.CA.US <==== a city department MDR.Library.CO.Los-Angeles.CA.US <==== a county department TOWNSHIP | PARISH (locality) ============================ Police.TOWNSHIP.Green.OH.US <==== a township department Administration.PARISH.Lafayette.LA.US <==== a parish department Cooper & Postel [Page 18] RFC 1480 The US Domain June 1993 DISTRICT | LIBRARY (agency) ============================ SCAQMD.DISTRICT.CA.US <==== a regional district Bunker-Hill-Improvement.DISTRICT.LA.CA.US <==== a local district Huntington.LIB.CA.US <==== a private library Venice.LA-City.LIB.CA.US <==== a city library MDR.LA-County.LIB.CA.US <==== a county library K12 | PRIVATE SCHOOLS (PVT) | CC | TEC ====================================== Hamilton.High.LA-Unified.K12.CA.US <==== a public school Sherman-Oaks.Elem.LA-Unified.K12.CA.US <==== a public K12 school John-Muir.Middle.Santa-Monica.K12.CA.US <==== a public K12 school Culver-High.CCSD.K12.CA.US <==== a public K12 school St-Monica.High.Santa-Monica.CA.US <==== a private school Crossroads-School.Santa-Monica.CA.US <==== a private school Mary-Ellens.Montessori-School.LA.CA.US <==== a private school Progress-Learning-Center.PVT.K12.CA.US <==== a private school SMCC.Santa-Monica.CC.CA.US <==== a public community college Trade-Tech.Los-Angeles.CC.CA.US <==== a public community college Valley.Los-Angeles.CC.CA.US <==== a public community college Brick-and-Basket-Institute.TEC.CA.US <== a technical college When appropriate, subdomains are delegated and partioned in various categories, such as: ..US = city/locality based names K12..US = kindergarten thru 12th grade PVT.K12..US = community colleges TEC..US = technical or vocational schools LIB..US = libraries STATE..US = state government agencies .FED.US = federal government agencies .DNI.US = distributed national institutes .GEN..US. = statewide assoc,clubs,domain parks The Appendix-I contains the current US Domain Names BNF. Cooper & Postel [Page 19] RFC 1480 The US Domain June 1993 3. REGISTRATION There are two types of registrations (1) Delegation, where a branch of the US Domain is delegated to an organization running name servers to support that branch; or (2) Direct Registration, in which the information is put directly into the main database. In Direct Registration there are two cases: (a) an IP-host (with an IP address), and (b) non-IP host (for example, a UUCP host). Any particular registration will involve any one of these three situations. 3.1 Requirements Anyone requesting to register a host in the US Domain is sent a copy of the "Instructions for the US Domain Template", and must fill out a US Domain template. The US Domain template, is similar to the InterNIC Domain template, but it is not the same. To request a copy of the US Domain template, send a message to the US Domain registrar (us-domain@isi.edu). If you are registering a name in a delegated zone, please register with the contact for that zone. You can FTP the file "in-notes/us- domain-delegated.txt" from venera.isi.edu, via anonymous FTP. This information is also available via email from RFC-INFO@ISI.EDU (include as the only text in the message "Help: us_domain_delegated_domains"). The key people must have electronic mailboxes (that work). Please provide all the information indicated in the "Administrator" and "Technical Contact" slots. The administrator will be the point of contact for any administrative and policy questions about the domain. The administrator is usually the person who manages the organization being registered. The technical contact can also be administrator, or the systems person, or someone who is familiar with the technical details of the Internet. The technical contact should have a valid working email address. This is necessary in case something goes wrong. It is important that your "Return-Path" and "From" field indicate an Internet-style address. UUCP-style addresses such as "host1!user" will not work. This is fine within the UUCP world, but not the Internet. If you want people on the Internet to be able to send mail to you, your return path needs to be an Internet-style address such as: host1!user@Internet.gateway.host or user@Internet.gateway.host. Cooper & Postel [Page 20] RFC 1480 The US Domain June 1993 It is also possible to register through one of the Internet service providers that have established working relationships with the US Domain Administrator. If everything checks out, the turn around time for registering a host is usually a few days. The name servers are updated anywhere from 12 to 24 hours later. There are two ways to be registered in the US Domain, directly, or by delegation. 3.2 Direct Entries Direct entry in the database of the US Domain appeals most to individuals and small companies. You may fill out the application and send it directly to the US Domain Administrator. If you are in an area where the zone is delegated to someone else your request will be forwarded to the zone administrator for your registration. Or, you may send the form directly to the manager of a delegated zone (see Section 3.1). 3.2.1 IP-Hosts These are hosts with IP addresses which correspond to "A" records in the DNS database. 3.2.2 Non-IP Hosts Many applicants have hosts in the UUCP world. Some are one hop away, some two and three hops away from their "Internet Forwarder", this is acceptable. What is important is getting an Internet host to be your forwarder. If you do not already have an Internet forwarder, there are several businesses that provide this service for a fee, such as UUNET.UU.NET (postmaster@uunet.uu.net), PSI (postmaster@UU2.PSI.COM) and CERFNET (help@cerf.net). Sometimes local colleges in your area are already on the Internet and may be willing to act as an Internet Forwarder. You would need to work this out with the systems administrator as we cannot make these arrangements for you. Although we work with UUCP service providers, the Internet US Domain registration is not affiliated with the registration of UUCP Map entries. The UUCP map entry does not provide us with sufficient information. If you do not have a copy of the US Domain questionnaire template, please send a message to: us-domain@isi.edu and request one. See Appendix-II. Cooper & Postel [Page 21] RFC 1480 The US Domain June 1993 The example below is not an appropriate registration for the US Domain. #N starl #S Amiga 2500; AmigaDOS 2.04; Dillon's AmigaUUCP 1.15D #O Starlight BBS #C Stephen Baker #E starl!sbaker #T +1 305 378 1161 #P 1107 SW 200th St #303B Miami, Fl. 33157 #L 25 47 N / 88 10 W [city] #R #U mthvax #W starl!sbaker (Stephen Baker); Mon Feb 24 19:58:24 EST 1992 starl mthvax(DAILY) If you are registering your host as a central site for a USENET group where other UUCP sites will feed from you, that's fine. These UUCP sites do not need to register. If however, the other sites become a subdomain of your hostname, then we will need to register them individually or add a wildcard record. (See Section 4.4. Wildcards). For example: bah.rochester.ny.us host1.bah.rochester.ny.us host2.bah.rochester.ny.us To use US Domain names for non-IP hosts, there must be a forwarder host that is an IP host. There must be an administrative agreement and a technical procedure for relaying mail between the non-IP host and the forwarder host. Case 1: ------- Your host is not an IP host but does talk directly with a host that is an IP host. +-----------------+ +----------+ +---------+ | | |your-host |---UUCP-----|forwarder|----IP/TCP--| INTERNET | +----------+ +---------+ | | +-----------------+ "Forwarder" must be an IP host on the Internet. You must ask "forwarder" if they are willing to be the Internet forwarder for "your-host". In the US Domain of the DNS data base there must be an entry like this: "your-host" MX 10 "forwarder" Cooper & Postel [Page 22] RFC 1480 The US Domain June 1993 This must be entered by the US Domain Administrator. In the "forwarder" routing tables there must be information about "your-host" with a rule like: If I see mail for "your-host" I will send it via uucp by calling phone number "123-4567". Case 2: ------- In this case your hosts talks to another host that ... that talks to an IP host. In other words, there are multiple hops between your host and the Internet. +-----------------+ +----------+ +---------+ | | |path-host |---UUCP-----|forwarder|----IP/TCP--| INTERNET | +----------+ +---------+ | | | +-----------------+ UUCP | +----------+ |your-host | +----------+ "Forwarder" must be an IP host on the Internet. You must ask "forwarder" if they are willing to be the Internet Forwarder for "Your-Host". You must ask "path-host" to relay your mail. In the US Domain of the DNS Database there must be an entry like this: "your-host" MX 10 "forwarder" This must be entered by the US Domain Administrator. In the "forwarder" routing tables there must be information about "your-host" with a rule like: If I see mail for "your-host" I will send it via UUCP to "path-host" by calling phone number "123-4567". and "path-host" must also know how to relay the mail to "your-host". Note: It is assumed that "path-host" is already MXed to "forwarder". It is not appropriate to ask to MX "your-host" to "path-host" (this is sometimes called double MXing). The host on the right hand side of an MX entry must be a host on the Internet with an IP address (e.g., 128.9.2.32). Cooper & Postel [Page 23] RFC 1480 The US Domain June 1993 3.3 Delegated Subdomains Many branches of the US Domain are delegated. There must be a knowledgeable and competent technical contact, familiar with the Internet DNS. This requirement is easily satisified if the technical contact already runs some other name servers. Examples of delegations are K12.TX.US for the Kindergarten through 12th Grade public schools in Texas, the locality "berkeley.ca.us", or the LIB.MN.US branch for the libraries in Minnesota. The administrator of the US Domain is responsible for the assignment of all the DNS names that end with ".US". Of course, one person or even one group can't handle all this in the long run so portions of the name space are delegated to others. The major concern in selecting a designated manager for a domain is that it be able to carry out the necessary responsibilities, and have the ability to do an equitable, just, honest, and competent job. The key requirement is that for each domain there be a designated manager for supervising that domain's name space. These designated authorities are trustees for the delegated domain, and have a duty to serve the community. The designated manager is the trustee of the domain for the domain itself and the global Internet community. Concerns about "rights" and "ownership" of domains are inappropriate. It is appropriate to be concerned about "responsibilities" and "service" to the community. The designated manager must be equitable to all groups in the domain that request domain names. This means that the same rules are applied to all requests. All requests must be processed in a nondiscriminatory fashion, and academic and commercial (and other) users are treated on an equal basis. No bias shall be shown regarding requests that may come from customers of some other business related to the manager -- e.g., no preferential service for customers of a particular data network provider. There can be no requirement that a particular mail system (or other application), protocol, or product be used. There are no requirements on subdomains beyond the requirements on higher-level domains themselves. That is, the requirements are applied recursively. In particular, all subdomains shall be allowed Cooper & Postel [Page 24] RFC 1480 The US Domain June 1993 to operate their own domain name servers, providing in them whatever information the subdomain manager sees fit (as long as it is true and correct). Significantly interested parties in the domain should agree that the designated manager is the appropriate party. The US Domain Administrator tries to have any contending parties reach agreement among themselves, and generally takes no action to change things unless all the contending parties agree; only in cases where the designated manager has substantially neglected their responsibilities would the US Domain Administrator step in. The designated manager must do a satisfactory job of operating the DNS service for the domain. That is, the actual management of the assigning of domain names, delegating subdomains and operating name servers must be done with technical competence. This includes keeping the US Domain Administrator or other higher-level domain managers advised of the status of the domain, responding to requests in a timely manner, and operating the database with accuracy, robustness, and resilience. There must be a primary and a secondary name server that have IP connectivity to the Internet and can be easily checked for operational status and database accuracy by the US Domain Administrator. One of the aspects of having two name servers for each domain (or zone), is for robustness. One concern under this heading is that the name service not go out entirely if there is a local power failure (earthquake, tornado, or other disaster). Name Servers should be in distinctly separate physical locations. It is appropriate to have more than two name servers, but there must be at least two. For any transfer of the designated manager trusteeship from one organization to another, the higher-level domain manager must receive communications from both the old organization and the new organization that assures the US Domain Administrator that the transfer in mutually agreed, and that the new organization understands its responsibilities. It is also very helpful for the US Domain Administrator to receive communications from other parties that may be concerned or affected by the transfer. Cooper & Postel [Page 25] RFC 1480 The US Domain June 1993 Delegation of cities, companies within cities, schools (K12), community colleges (CC), libraries (LIB), state government (STATE), and federal government agencies (FED), etc., is acceptable and practical. For a delegated portion of the name space, for example a city, no alterations can be made to that name, no abbreviations added, etc. unless applied for. Sometimes there may be two people running name servers in the same city because different portions of the name space has been delegated to them. For example, someone may be delegated the ..US name space, and someone else from a state government agency may have the .STATE..US, portion. For example, Fred may run the name servers for Sacramento.CA.US and Joe may run the name servers for STATE.CA.US in Sacramento. If a company would like to have wildcard records added, or run their own name servers in a city that we have delegated name space to, this is acceptable. Delegation of the whole State name space is not yet implemented. The delegated part of the name space is in the form of: ...US. .CI...US. .CO...US. .STATE..US. .K12..US. PVT.K12..US. .CC..US. .TEC..US. .LIB..US. .GEN..US. .DNI.US. .FED.US. 3.3.1. Delegation Requirements When a subdomain is delegated, the following requirements must be met: 1) There must be a knowledgeable and competent technical contact, familiar with the Internet DNS. This requirement is easily satisified if the technical contact already runs some other name servers. Cooper & Postel [Page 26] RFC 1480 The US Domain June 1993 2) Organizations requesting delegations must provide at least two independent (robust and reliable) DNS name servers in physically separate locations on the Internet. 3) The subdomain must accept all applicants on an equal basis. 4) The subdomain must provide timely processing of requests. To do this, it is helpful to have several individuals knowledgeable about the procedures so that the operations are not delayed due to one persons unavailability (for example, by being on vacation). 5) The subdomain manager must tell the US Domain Administrator when there are changes in the name servers that should be reflected in the US Domain zone files, or changes in the contact information. K12 Administrators In the long term, registering schools will be a big job. So you need to have in mind delegating parts of the work to various school districts. If you can delegate every school district in the state then you are finished, except for checking that they are all operating correctly. However, initially you will have quite a bit to do with educating people, helping them choose names and getting name servers arranged. You are responsible for seeing that the naming of schools follow the guidelines suggested in this memo. All K12 Administrators will initially be responsible for managing the "pseudo district" PVT for private schools. Private schools have the option of registering as .PVT.K12..US or as a business under the city based names. Locality Administrators If you have been delegated a locality subdomain, you will be responsible for registering not only businesses directly under the locality, but city and county agencies under the "CI" and "CO" branches. When appropriate these branches should be delegated. If you want, you may spell out "CITY" instead of "CI" or "COUNTY" instead of "CO", but you must be consistent and use only one or the other in a given locality. The whole city government should be under one branch. Cooper & Postel [Page 27] RFC 1480 The US Domain June 1993 WHOIS Database Only the second and third level delegated name spaces will be entered in the WHOIS database. For example, K12.CA.US would have an entry in WHOIS. Anything under K12.CA.US will not be listed. The US Domain Administrator will send the information that you supplied on your US Domain template to the InterNIC. It is the hope that in the future, each delegated subdomain will provide their own WHOIS directory database for their branch. 3.3.2 Delegation Procedures The procedure that is followed when a subdomain is delegated includes the following steps: 1) Evaluate the technical contact's experience with DNS. Make sure there is a need for the proposed delegation. Make sure the technical contact has the information about the US Domain and the suggested naming structure. Two contacts with email addresses are necessary in case something goes wrong. 2) Add the new technical contact to the "us-dom-adm" mailing list for distributing updates concerning the US Domain policies and procedures. 3) Delete any hosts from our zone file that belongs in the newly delegated subdomain and make sure they now have the hosts in their zone file. 4) Send them a copy of the zone file so their initial zone file is identical to ours. For example: mil.wi.us. 69582 SOA spool.mu.edu. manager.spool.mu.edu. ( 930119 ;serial 28800 ;refresh 14400 ;retry 3600000 ;expire 86400 ) ;minim mil.wi.us. 69582 NS spool.mu.edu. spool.mu.edu. 85483 A 134.48.1.31 mil.wi.us. 69582 NS sophie.mscs.mu.edu. sophie.mscs.mu.edu. 85483 A 134.48.4.6 solaria.mil.wi.us. 69582 HINFO Sun 3/60 SunOs solaria.mil.wi.us. 69582 MX 10 spool.mu.edu. nthomas.mil.wi.us. 69582 HINFO 386 Clone DOS nthomas.mil.wi.us. 69582 MX 10 spool.mu.edu. Cooper & Postel [Page 28] RFC 1480 The US Domain June 1993 rwmke.mil.wi.us. 69582 HINFO UNIX PC UNIX rwmke.mil.wi.us. 69582 MX 10 spool.mu.edu. milestn.mil.wi.us. 69582 MX 10 spool.mu.edu. nrunner.mil.wi.us. 69582 HINFO MacIntosh System 7 nrunner.mil.wi.us. 69582 MX 10 spool.mu.edu. dawley.mil.wi.us. 69582 HINFO 386 Clone DOS dawley.mil.wi.us. 69582 MX 10 spool.mu.edu. ... 5) The US Domain zone file must have the following records, showing the name, address, email, and phone number of the technical contact for the delegated subdomain and the name of the delegated name space and the names of the name servers. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ;Contact: Joseph Klein (tjk@spool.mu.edu) ; Marquette University ; (414) 288-6734 ; ;Delegate mil.wi.us zone mil.wi.us. 604800 NS SPOOL.MU.EDU. 604800 NS SOPHIE.MSCS.MU.EDU. ; A glue record is not needed this time. Glue records are ; needed when the name of the server is a subdomain of the ; delegated domain. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 6) Check to see that delegated subdomain name servers are up and running, and make sure the delegated hosts are installed in their zone file. Now delete any hosts from the US Domain zone file that belongs in the newly delegated subdomain. 7) Inform the technical contact of the newly delegated subdomain that wildcard records are allowed in the zone file under the organizational subdomain but no wildcard records are allowed under the "city" or "state" domain. 8) Make sure each administrator has a copy of this RFC and follows the guidelines set forth. 3.3.3 Subdomain Contacts The number of hosts registered under each subdomain is unknown. See Section 3.1 for information on the delegated domains and the contacts. Cooper & Postel [Page 29] RFC 1480 The US Domain June 1993 4. DATABASE INFORMATION 4.1. Name Servers Name servers are the repositories of information that make up the domain database. The database is divided up into sections called zones, which are distributed among the name servers. While name servers can have several optional functions and sources of data, the essential task of a name server is to answer queries using data in its zones. The response to a query can always be generated using only local data, and either contains the answer to the question or a referral to other name servers "closer" to the desired information. A given zone will be available from several name servers to insure its availability in spite of host or communication link failure. Every zone is required to be available on at least two servers, and many zones have more redundancy than that. The US Domain is currently supported by seven name servers: venera.isi.edu ns.isi.edu rs.internic.net ns.csl.sri.com ns.uu.net adm.brl.mil excalibur.usc.edu 4.2 Zone Files A "zone" is a registry of domains kept by a particular organization. A zone registry is "authoritative", that is, the master copy of the registry is kept by the zone organization, and this copy is, by definition, always up-to-date. Copies of this registry may be distributed to other places and kept in caches, but these caches are not authoritative, and may be out-of-date. Every zone has at least one node, and hence domain name, for which it is authoritative, and all of the nodes in a particular zone are connected. Given the tree structure, every zone has a highest node which is closer to the root than any other node in the zone. The name of this node is often used to identify the zone. The data that describes a zone has four major parts: 1) Authoritative data for all nodes within the zone. 2) Data that defines the top node of the zone (can be thought of as part of the authoritative data). Cooper & Postel [Page 30] RFC 1480 The US Domain June 1993 3) Data that describes delegated subzones, i.e., cuts around the bottom of the zone, 4) Data that allows access to name servers for subzones (sometimes called "glue" data). The zone administrator has to maintain the zones at all the name servers which are authoritative for the zone. When the changes are made, they must be distributed to all of the name servers. Copies of the zone files are not available unless you are on the Internet. To look at the zone files use the "dig" program of the DNS domain name system. dig @nshost host-your-checking axfr 4.3 Resource Records Records in the zone data files are called resource records (RRs). The standard Resource records (RR) are specified in STD 13, RFC 1034 and STD 13, RFC 1035 (3,4). An RR has a standard format as shown. [] [] The first field is always the name of the domain record. The second field is an optional time to live field. This specifies how long this data will be stored in the data base. The third field is the address class; the class field specifies the protocol group most often this is the Internet class "IN". The fourth field states the type of the resource record. The fields after that are dependent on the Type of RR. The fifth field is the data field which is defined differently for each type and class of data. Here is a list of the current commonly used types: SOA Start of Authority NS Name Server A Internet Address CNAME Canonical Name (nickname pointer) HINFO Host Information WKS Well Known Services MX Mail Exchanger PTR Pointer Cooper & Postel [Page 31] RFC 1480 The US Domain June 1993 What do the fields mean? foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU. (1) (2) (3) (4) (5) 1) domain name 2) time to live information 3) mail exchanger record 4) preference value to determine (if more than one forwarder) which mailer to use first, lower number higher preference 5) the Internet forwarding host. 4.3.1 "A" Records Internet (IP) Address. The data for an "A" record is an Internet address in a dotted decimal form. A sample "A" record might look like: venera.isi.edu. A 128.9.0.32 (name) (A) (address) The name field is the machine name, and the address is the network address. There should be only one "A" record for each address of a host. 4.3.2 CNAME Records Canonical Name resource record, CNAME, specifies an alias for a canonical name. This is essentially a pointer to the official name for the requested name. All other RRs appear under this official name. A machine named FERNWOOD.MPK.CA.US may want to have the nickname ANTERIOR.MPK.CA.US. In that case, the following RR would be used: anterior.mpk.ca.us. CNAME fernwood.mpk.ca.us. (alias nickname) (canonical name) Nicknames (the name associated with the RR is the nickname) may be added for awhile when a host changes its name, usually because it moves to another state. It helps to have this CNAME pointer so if any mail comes to the old address it will get forwarded to the new one. There cannot be any other RRs associated with a nickname of the same class. Cooper & Postel [Page 32] RFC 1480 The US Domain June 1993 4.3.3 MX Records Mail Exchanger records, MX, are used to specify a machine that knows how to deliver mail to a machine that is not directly connected to the Internet. For example, venera.isi.edu is the mail gateway that knows how to deliver mail to foo.la.ca.us, but other machines on the network cannot deliver mail directly to foo.la.ca.us. These two machines may have a private connection or use a different transport medium (such as uucp). The preference value (10) is the order that a mailer should follow when there is more than one way to deliver mail to a single machine. The lower the number the higher the preference. foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU. foo.LA.CA.US. 604800 MX 20 relay1.uu.net. 4.3.4 HINFO Records Host information resource records, HINFO is for host specific data. This lists the hardware and operating system that are running at the listed host. It should be noted that a space separates the hardware information and the operating system information. If you want to include a space in the machine name you must quote the name. Host information is not specific to any class, so ANY may be used for the address class. There should be one HINFO record for each host. acb.la.ca.us. HINFO VAX-11/780 UNIX (Hardware) (Operating System) The official HINFO types can be found in the latest Assigned Numbers RFC, the most recent edition being STD 2, RFC 1340 [9]. The hardware type is called the Machine Name, and the software type is called the System Name. The information users supply about this is often inconsistent or incomplete. Please follow the terms in the current "Assigned Numbers". 4.3.5 PTR Records A Domain Name Pointer record, PTR, allows special names to point to some other location in the domain data base. These are typically used in setting up reverse pointers for the special IN-ADDR.ARPA domain. PTR names should be unique to the zone. 0.0.9.128.in-addr.arpa PTR isi-net.isi.edu. (special name) (real name) Cooper & Postel [Page 33] RFC 1480 The US Domain June 1993 A PTR record is to be added to the IN-ADDR.ARPA domain for every "A" record registered in the US Domain. These PTR records need to be added by the administrator of the network where the host is connected. The US Domain Administration does not administer the network and cannot make these entries in the DNS database. 4.4 Wildcards The wildcard records are of the form "*.", where is any domain name. The wildcards potentially apply to descendents of , but not to itself. For example, suppose a large company located in California with a large, non-IP/TCP, network wanted to create a mail gateway. If the company was called DWP.LA.CA.US, and the IP/TCP capable gateway machine (Internet forwarder) was called ELROY.JPL.NASA.GOV, the following RRs might be entered into the .US zone. dwp.la.ca.us MX 10 ELROY.JPL.NASA.GOV *.dwp.la.ca.us MX 10 ELROY.JPL.NASA.GOV The wildcard record *.DWP.LA.CA.US would cause an MX query for any domain name ending in DWP.LA.CA.US to return an MX RR pointing at ELROY.JPL.NASA.GOV. The entry without the "*" is needed so the host dwp can be found. In the US Domain, wildcard records are allowed in our zone files under the organizational subdomain (and where noted otherwise) but no wildcard records are allowed under the "City" or "State" domain. The authors strongly believe that it is in everyone's interest and good for the Internet to have each host explicitly registered (that is, we believe that wildcards should not be used), we also realize that not everyone agrees with this belief. Thus, we will allow wildcard records in the US Domain under groups or organizations. For example, *.DWP.LA.CA.US. The reason we feel single entries are the best is by the mere fact that if anyone wanted to find one of the hosts in the domain name system it would be there, and problems can be detected more easily. When using wildcards records all the hosts under a subdomain are hidden. Cooper & Postel [Page 34] RFC 1480 The US Domain June 1993 5. REFERENCES [1] Stahl, M., "Domain Administrators Guide", RFC 1032, SRI International, November 1987. [2] Lottor, M., "Domain Administrators Operations Guide" RFC 1033, SRI International, November 1987. [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, ISI, November 1987. [4] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, ISI, November 1987. [5] Dunlap, K., "Name Server Operations Guide for Bind, Release 4.3", UC Berkeley, SMM:11-3. [6] Partridge, C., "Mail Routing and the Domain Name System", STD 14, RFC 974, BBN, January 1986. [7] Albitz, P., C. Liu, "DNS and Bind" Help for UNIX System Administrators, O'Reilly and Associates, Inc., October 1992. [8] ACM SIGUCCS Networking Taskforce, "Connecting to the Internet - What Connecting Institutions Should Anticipate", FYI 16, RFC 1359, August 1992. [9] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, ISI, July 1992. 6. Security Considerations Security issues are not discussed in this memo. Cooper & Postel [Page 35] RFC 1480 The US Domain June 1993 7. Authors' Addresses Ann Cooper USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: 1-310-822-1511 Email: cooper@isi.edu Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: 1-310-822-1511 Email: postel@isi.edu Cooper & Postel [Page 36] RFC 1480 The US Domain June 1993 APPENDIX-I: US DOMAIN NAMES BNF ================================ ::= ::= | ::= ::= | | ::= ::= ::= | |