When the centralized negotiation architecture is used, the
local charging state information for a domain is maintained by the NRN.
The price formulation strategy is a much more open-ended problem.
Various alternatives may be considered, and different domains may
apply different local policies.
The NRN may compute a price based on the service specifications alone.
The price could be fixed, or modified
based on the time of day, etc. In general, if the price charged to a flow
needs to depend on the network state and the flow path,
we consider the following three approaches:
The NRN maintains a domain routing table which finds any flow route that either ends in its own domain, or uses its domain as a transmit domain. The domain routing table will be updated whenever the link state database is changed. A NRN also maintains a resource table, which allows it to keep track of the availability and dynamic usage of the resources (bandwidth, buffer space). In general, the resource table stores resource information for each service provided at a router. The resource table allows the NRN to compute a local price at each router. For a particular service request, the NRN first looks up the path on which resources are requested using the domain routing table, and then uses the per-router prices to compute the accumulated price along this path. The resource table also facilitates monitoring and provisioning of resources at the routers. To enable the NRN to collect resource information, routers in the domain periodically report local state information (for instance, average buffer occupancy and bandwidth utilization) to the NRN. A protocol such as COPS [#!COPS!#] can be used for this purpose.
To compute the charge for a flow, ingress routers maintain per-flow (or aggregated flow from neighboring domain) state information about the data volume transmitted during a negotiation period. This information is periodically transmitted to the NRN, allowing the NRN to compute the charge for the period. The NRN uses the computed price and charge to maintain charging state information for each RNAP session.
Prices are computed at the network boundary, and communicated to the NRN. For price calculation, there are two alternatives.
One alternative is that the ingress router periodically computes a price for each service class and ingress-egress pair. The calculation is based on service specifications and local per-service demand at the ingress router; internal router states along the flow path are not taken into account.
The other alternative allows internal router load to be taken into account. Probe messages are sent periodically from an egress router to all ingress routers. A probe message carries per-service Price structures which accumulate prices hop-by-hop at each router. In both of the above cases, the ingress router maintains per-flow state information that includes the per-flow price (the price charged to the service class the flow belongs to), as well as the per-flow data volume entering the domain. This information is transmitted every negotiation period to the NRN, which computes the charge and is responsible for the messaging.
In the above schemes, we assume that a domain has one NRN. A domain could also have multiple NRNs, each NRN residing at an ingress router. In this case, the ingress router does not need to send periodic per-session reports to a centralized NRN, and pricing, charging, and RNAP messaging are done directly from the ingress router. Reliability concerns make a more distributed architecture (multiple NRNs, or RNAP-D) preferable. But some management goals (for instance, all NRNs in one domain need to have coherent view of the resource at internal routers to allow them to make correct admission decisions) may make a centralized policy more attractive.