Side_1_360

used to convey the information to the router on

which DSCP to apply for each flow. This would

particularly be useful in case IPSec is applied if

the IP addresses and port numbers are not stati-

cally assigned to DiffServ classes.

The reference configuration is depicted in Figure

3. The non-DiffServ regions may consist of
   IntServ capable routers or other types of network
   elements. If these regions do not handle IntServ,
   it is assumed that they are able to pass RSVP
   messages unhindered. The hosts/terminals (Tx
   and Rx) are able to generate and interpret RSVP-
   messages as they are exchanging these messages
   end-to-end. ER1 and ER2 are edge routers adja-
   cent to the DiffServ region, while BR1 and BR2
   are the routers connected to these within the
   DiffServ region.

In case the DiffServ network region is so-called

RSVP-unaware, the edge routers (ERs) act as

admission control agents to the DiffServ net-

work. That is, they do admission control based

on resource availability within the DiffServ net-

work and on a defined policy (for instance

related to Tx or Rx). For this case, routers within

the DiffServ act as “pure” DiffServ routers, i.e.

forward packets according to DSCP (and option-

ally customer policy).

If the DiffServ region is RSVP-aware, the border

routers (BRs) apply admission control based on

local resource availability and on customer (Tx,

Rx) defined policy. In principle, more routers in

the DiffServ region may also be RSVP aware,

which means that these can also take part in the

resource reservation. Still, on what granularity

level, e.g. on an aggregate level, the reservation

in the DiffServ region should take place, is to be

decided.

At the border of the DiffServ region appropriate

mapping to a PHB has to be done per flow. In

addition, policing (optionally including shaping

and remarking) would be needed. Admission

control, taking into account the resource situa-

tion in the DiffServ region, is also necessary.

The mapping could be static (from IntServ ser-

vice type to DSCP) or given by information in

the RSVP messages.

In order to allow for successful interconnection

with a DiffServ region, that region has to meet

the following requirements, ref. [RFC2998]:

• Able to provide support for the standard
  IntServ services between its border routers.
  This is to be done by invoking the PHB within
  the DiffServ region and appropriate behaviour
  at the edges of the DiffServ region. Mapping
  between flow characteristics in the regions
  must also be defined.


• Provide admission control information to the
  non-DiffServ network regions. This can be
  done by a protocol or by terms in Service
  Level Agreements, SLAs.


• Able to pass RSVP messages, such that it can
  be recovered at the egress of the DiffServ
  region. The DiffServ region may process these
  messages.

In addition, other traffic flows may be carried by

the DiffServ region, e.g. not being originated in

an IntServ region.

3.2 Routing Issues

Looking at most results on TE, and particularly

constraint-based routing, the fact that traffic

flows can traverse a number of domains is not

considered. [ID_bgpte] drafts some suggestions

for utilising BGP to propagate TE information

between border routers. The BGP Multi-Exit

Discriminator provides some level of inter-

domain metric, but does not seem to include

information beyond the adjacent domain. The

suggestion described in [ID_bgpte] is that each

domain propagates summary weights (for TE

criteria).

When IGPs like OSPF and ISIS are used, the

link state announcements (LSAs) can be used for

carrying information from a border router to

another border router informing about the met-

rics relevant for reaching destinations using that

domain.

The TE metrics (weights) described in [IDbgpte]

are:

• available bandwidth;


• unreserved bandwidth;


• colours (or class types);


• transit delay;


• IGP metrics/hops.

When a route optimisation algorithm is exe-

cuted, these metrics must somehow be com-

bined. Therefore a weight priority may also be

introduced, telling which metrics are the most

significant ones.

Figure 3 Reference
configuration

non-Diffserv

e.g. Intserv

Diffserv non-Diffserv

e.g. Intserv

Tx ER1 BR1 BR2 ER2 Rx