Side_1_360

(Dana P.) #1
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


  1. 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
Free download pdf