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
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
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.
- 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.
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
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.
- 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
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,
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
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.
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.
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.
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.
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
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.
- 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.
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.
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.
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
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 |
+---------------+-----------------------------------------------+
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.
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.
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", RFC1102, May
1989.
[2] Estrin, D., "Requirements for Policy Based Routing in the
Research Internet", RFC1125, November 1989.
[3] Little, M., "Goals and Functional Requirements for Inter-
Autonomous System Routing", RFC1126, 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", RFC1478, 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", RFC1131, 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